Discussion of RFC 2822 ()

Re: More on mail message header fields

In <5.1.0.14.2.20040430145623.025c0938 <at> 127.0.0.1> Graham Klyne <gk <at> ninebynine.org> writes:

>In response to an off-list comment, I'm making a small revision of the mail 
>message header registry draft [1] to mark header fields defined in RFC822 
>(as well as RFC2822) as standard rather than just "standards-track".  This 
>raised two questions:

But this does raise the question of a header that was defined in some
standard (say RFC 822) and subsequently changed in some significant manner
by a later standards-track RFC that only achieved Proposed Standard (e.g.
RFC 2822). The difference might be such as to warrant a change in the
registry (e.g. the later document might explicitly obsolete or deprecate
it). You would then have to be careful to include references to both
documents, and maybe remove the "Standard" label.

I don't think any problems of this kind arise in the case of the 822/2822
pair, apart from the "Encrypted" case that you mentioned.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

headers

Graham Klyne | 7 May 14:44

Re: More on mail message header fields

At 10:07 03/05/04 +0000, Charles Lindsey wrote:

>In <5.1.0.14.2.20040430145623.025c0938 <at> 127.0.0.1> Graham Klyne 
><gk <at> ninebynine.org> writes:
>
> >In response to an off-list comment, I'm making a small revision of the mail
> >message header registry draft [1] to mark header fields defined in RFC822
> >(as well as RFC2822) as standard rather than just "standards-track".  This
> >raised two questions:
>
>But this does raise the question of a header that was defined in some
>standard (say RFC 822) and subsequently changed in some significant manner
>by a later standards-track RFC that only achieved Proposed Standard (e.g.
>RFC 2822). The difference might be such as to warrant a change in the
>registry (e.g. the later document might explicitly obsolete or deprecate
>it). You would then have to be careful to include references to both
>documents, and maybe remove the "Standard" label.

I'll defer to any IETF process experts, but it seems fairly clear to me 
that a standard stands until it is replaced.  A Proposed or Draft standard 
that updates a standard is a pretty clear statement of intent (and as such 
is useful guidance to implementers), but does not replace an existing 
standard until it becomes one itself.

In this case, I think what matters is what the community agrees should go 
into the registry.

#g

(Continue reading)

headers

Charles Lindsey | 12 May 15:19

Re: More on mail message header fields

In <5.1.0.14.2.20040507134011.026e3180 <at> 127.0.0.1> Graham Klyne <GK-lists <at> ninebynine.org> writes:

>I'll defer to any IETF process experts, but it seems fairly clear to me 
>that a standard stands until it is replaced.  A Proposed or Draft standard 
>that updates a standard is a pretty clear statement of intent (and as such 
>is useful guidance to implementers), but does not replace an existing 
>standard until it becomes one itself.

It is generally more useful to refer to the new Proposed/Draft version.
For example, I see that in draft-klyne-hdrreg-mail-04.txt you routinely
refer to RFC 2822 rather than to RFC 822, and rightly so in my opinion,
so I hope you aren't going to change it. So are you suggesting that _both_
should be referred to in the registry?

>In this case, I think what matters is what the community agrees should go 
>into the registry.

I think the community has accepted that RFC 2822 has superseded RFC 822
for all practical purposes. If any niggles remain, they will be resolved
by some update to RFC 2822 (as Pete has proposed) rather than by going
back to RFC 822.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

(Continue reading)

headers

Keith Moore | 12 May 23:37

Re: More on mail message header fields


> I think the community has accepted that RFC 2822 has superseded RFC
> 822 for all practical purposes. 

IMHO - if you're implementing a mail _reader_ you do well to rely
heavily on RFC 822.  It's a much simpler, easier-to-understand, and
easier-to-implement-correctly grammar than the one in 2822, and with
very few exceptions you need to be able to understand messages written
according to the RFC 822 grammar anyway.

OTOH, if you're implementing a mail _composer_ you need to rely on 2822.

So I tend to view 2822 as augmenting 822, rather than replacing it.

The opt- productions were a nice idea, but IMHO they didn't work as well
as we hoped.

--
Regime change 2004 - better late than never.