Subject: Re: More on mail message header fields
From: Bruce Lilly <[email-masked]>
To: [email-masked]
Date: Sat, 29 May 2004 20:54:54 -0400
List-Id: <ietf-822.imc.org>

> 2.1.4  Header field: Reply-To
>  
>    Description:
>       Mailbox for replies to message

That's not quite correct. Reply-To specifies a *list* of *addresses* for replies,
as opposed to a *single* *mailbox*.  Addresses include named groups as well as
mailboxes.

According to my notes, here is what the various address fields specify:
RFC 2822:
  from            =       "From:" mailbox-list CRLF
  sender          =       "Sender:" mailbox CRLF
  reply-to        =       "Reply-To:" address-list CRLF
  to              =       "To:" address-list CRLF
  cc              =       "Cc:" address-list CRLF
  bcc             =       "Bcc:" (address-list / [CFWS]) CRLF
RFCs 724, 733 permitted address-lists in From

Note that Reply-To is consistent with To, Cc, and Bcc. All of which
permit anything that might appear in From (but not vice-versa since
RFC 822 obsoleted RFC 733).  Sender permits only a single mailbox.

Date: Fri, 28 May 2004 08:15:42 -0700 (PDT)
From: [email-masked]
Subject: Re: content-type: text/plain; magic=on; magic=off
To: Keith Moore <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Virus-test: FALSE
Sender: [email-masked]

> > if a message has the content-type field mentioned in the subject,
> > which seems valid as far as I can tell, then which setting wins?
> > Should a compliant mail reader enable or disable magic while reading
> > such a message?

It's arbitrary given that parameter order is insignificant.

> two gut reactions:

> 1. if a content-type wants to define some behavior in which it makes
> sense to use the same parameter more than once, I don't recall anything
> in the MIME spec that prohibits that, and I can think of a few cases
> where it would be useful.  e.g.

> content-type: message/external-body; access-type=url;
> url="http://some.site/"; url="http://other.site/"

> could specify multiple locations at which the desired content could be
> found.

It may not be explicitly stated that duplicate parameters aren't allowed, but
given that parameter order is required not to be significant (RFC 2046 section
1) is is hard to come up with any other result that makes sense.

This issue came up when the parameter encoding extensions were being developed
and I added some text specifying that parameters are to appear only once to my
working copy of the MIME specification at that time. Unfortunately the
specification hasn't been published since.

> however, I suspect that this would break assumptions made by some
> implementations, and for that reason I'd probably object to a proposal
> for a content-type that tried to use the same parameter more than once.

Agreed.

> 2. there are so many ways to do meaningless or stupid things in email
> that I doubt it's productive to try to specify the "right" behavior in
> every case.  only the most common errors seem worth the trouble.

Absolutely. The right thing to do here is to make it clear parameters
can only appear once when MIME is next revised. Hopefully I can get that
particular ball rolling sometime soon...

				Ned

Cc: Keith Moore <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: content-type: text/plain; magic=on; magic=off
Date: Fri, 28 May 2004 09:50:16 -0400
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> if a message has the content-type field mentioned in the subject, 
> which seems valid as far as I can tell, then which setting wins? 
> Should a compliant mail reader enable or disable magic while reading 
> such a message?

two gut reactions:

1. if a content-type wants to define some behavior in which it makes 
sense to use the same parameter more than once, I don't recall anything 
in the MIME spec that prohibits that, and I can think of a few cases 
where it would be useful.  e.g.

content-type: message/external-body; access-type=url; 
url="http://some.site/"; url="http://other.site/"

could specify multiple locations at which the desired content could be 
found.

however, I suspect that this would break assumptions made by some 
implementations, and for that reason I'd probably object to a proposal 
for a content-type that tried to use the same parameter more than once.

2. there are so many ways to do meaningless or stupid things in email 
that I doubt it's productive to try to specify the "right" behavior in 
every case.  only the most common errors seem worth the trouble.

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: content-type: text/plain; magic=on; magic=off
Date: Fri, 28 May 2004 12:45:04 +0200
Sender: [email-masked]

Hi,

if a message has the content-type field mentioned in the subject, which 
seems valid as far as I can tell, then which setting wins? Should a 
compliant mail reader enable or disable magic while reading such a 
message?

Arnt

Date: Thu, 27 May 2004 10:54:17 -0700 (PDT)
From: [email-masked]
Subject: Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF'  to Draft  Standard
To: Dave Crocker <[email-masked]>
Cc: Graham Klyne <[email-masked]>, [email-masked], [email-masked]
Virus-test: FALSE
Spam-test: False ; 1.2 / 4.5 ; FROM_ENDS_IN_NUMS,NO_REAL_NAME
Sender: [email-masked]

> Graham,

> GK> I don't claim it's helpful to revise ABNF at this juncture of the process,
> GK> but maybe it's time to start thinking how to more easily specify case
> GK> sensitive text.

> There were a number of enhancements considered when the ABNF spec was
> split off from the email spec.  All of them seemed pretty reasonable,
> but the feeling was the innovation was not in the charter of the working
> group, even for the rather off-center ABNF effort.

> Certainly might be worth reconsidering the set, if only informally.

It may be worth considering, but not at the expense of moving the current
specification to draft. Divide and conquer.

				Ned

Date: Tue, 25 May 2004 23:56:46 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Graham Klyne <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF'  to Draft  Standard
Sender: [email-masked]

(re-post with correct From.)

Graham,

GK> I don't claim it's helpful to revise ABNF at this juncture of the process, 
GK> but maybe it's time to start thinking how to more easily specify case 
GK> sensitive text.

There were a number of enhancements considered when the ABNF spec was
split off from the email spec.  All of them seemed pretty reasonable,
but the feeling was the innovation was not in the charter of the working
group, even for the rather off-center ABNF effort.

Certainly might be worth reconsidering the set, if only informally.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Tue, 25 May 2004 21:58:49 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Graham Klyne <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF'  to Draft  Standard
Sender: [email-masked]

Graham,

GK> I don't claim it's helpful to revise ABNF at this juncture of the process, 
GK> but maybe it's time to start thinking how to more easily specify case 
GK> sensitive text.

There were a number of enhancements considered when the ABNF spec was
split off from the email spec.  All of them seemed pretty reasonable,
but the feeling was the innovation was not in the charter of the working
group, even for the rather off-center ABNF effort.

Certainly might be worth reconsidering the set, if only informally.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Tue, 25 May 2004 09:12:48 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF' to Draft  Standard 
Cc: [email-masked]
Sender: [email-masked]

I assume this last-call is a request to advance the ABNF spec without changes.

Without wishing to oppose such a move, maybe this is a reasonable time to 
raise a question about the way ABNF is specified with respect to case 
(in)sensitivity.

Currently, productions that contain literal (US-ASCII) letters are defined 
by RFC234 as indicating any combination of upper and/or lowercase for those 
letters.  This seems to be at odds with modern approaches to protocol and 
data design, which (driven to some extent by I18N issues) tend to prefer 
that data elements are case sensitive.  An obvious example of this is XML.

I had a real experience not so long ago of using ABNF and needing to 
specify case sensitive keywords in an IETF WG specification -- the 
"official" solution of using character codepoint values was, in my view, 
most unhelpful with respect to readability.

I don't claim it's helpful to revise ABNF at this juncture of the process, 
but maybe it's time to start thinking how to more easily specify case 
sensitive text.  Some thoughts that occur to me are (without judgement as 
to whether they are good or bad):

(a) require a using specification to indicate case sensitivity (which I 
regard as an option today, but there is a concern about possible confusion 
if not done sufficiently clearly).

(b) add some kind of case-sensitivity "declaration" to ABNF (probably not 
very helpful when ABNF is presented as fragments throuout a document).

(c) add some kind of alternative literal string syntax to indicate case 
sensitivity (e.g. like the Python convention for different string 
conventions, which uses a prefix letter before the literal;  u"xyz" 
indicates a Unicode string, or r"abzcd" one in which the '\' is not 
interpreted).

#g
--

At 10:41 24/05/04 -0400, The IESG wrote:
>The IESG has received a request to consider the following document:
>
>- 'Augmented BNF for Syntax Specifications: ABNF '
>   RFC 2234 as a Draft Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2004-06-07.
>
>The file can be obtained via
>http://www.ietf.org/rfc/rfc2234.txt
>
>Implementation Report can be accessed at
>http://www.ietf.org/IESG/implementation.html
>
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf-announce

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

To: [email-masked]
Xref: clerew local.mime:3150
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: More on mail message header fields
Date: Fri, 21 May 2004 09:12:53 GMT
Lines: 81
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> writes:

>[[[
>With reference to:
>   http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt
>which contains the changes I have proposed.
>]]]

>I think this is one of those small details that came out in the execution 
>(ala "running code") which wasn't fully mapped out when the registry 
>procedure document was drafted.  In preparing the mail header registration 
>document, it seemed to be more appropriate (and more honest regarding some 
>of the headers' actual status in the IETF process) to me to specify 
>not-yet-standard headers as "standards-track" rather than "standard".  The 
>wiggle room in the registry spec that allows me to justify this is "or some 
>other appropriate value according to the type and status of the primary 
>document".  I used the term "standards-track" rather than "Proposed-" or 
>"Draft-" because that's what appears on the standards-track RFCs; e.g.
>[[
>Network Working Group                                 P. Resnick, Editor
>Request for Comments: 2822                         QUALCOMM Incorporated
>Obsoletes: 822                                                April 2001
>Category: Standards Track
>]]
>I concede that consistency might suggest "Proposed-" or "Draft-", but I 
>don't see any added value in having such fine detail in the registry.

>I think my approach is entirely in the intended spirit of the registry, 
>which is to help prospective designers and users (a) find information about 
>the variety of headers in use, and (b) to record any additional information 
>about their suitability for use, rather than to attempt to provide detailed 
>information that is available elsewhere.

Hmmm! I am not convinced that distinguishing between the various
standard-track stages in the Registry is really the right thing (and
surely the spec would have required that it that had been the intention).

My problem is that it leads to entries like the following in your
hdrreg-mail-05.txt:

2.1.4  Header field: Reply-To
 
   Description:
      Mailbox for replies to message
 
   Applicable protocol: Mail [20]
 
   Status: standard
 
   Author/change controller:
      IETF  (mailto:[email-masked])
      Internet Engineering Task Force
 
   Specification document(s):
      RFC 2822 [20] (section 3.6.2)

   Related information:
      When the "Reply-To:" field is present, it indicates the
      mailbox(es) to which the author of the message suggests that
      replies be sent. Defined as standard by RFC 822.

Now it says there that the Status is "standard" (as opposed to
"standards-track" which is used with some other headers). But it refers to
RFC 2822 as the Specification Document, and RFC 2822 is not (yet) a
standard. This could be confusing (and yet referring to RFC 822 as the
Specification Document would be even more so).

Hence I think it would be better to use "standards-track" throughout (or
"standard" if it is understood to mean the same thing).

-- 
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: [email-masked]      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

Date: Mon, 17 May 2004 10:37:32 +0100
To: "Charles Lindsey" <[email-masked]>, [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: More on mail message header fields
Sender: [email-masked]

[[[
With reference to:
   http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt
which contains the changes I have proposed.
]]]

Charles,

I think this is one of those small details that came out in the execution 
(ala "running code") which wasn't fully mapped out when the registry 
procedure document was drafted.  In preparing the mail header registration 
document, it seemed to be more appropriate (and more honest regarding some 
of the headers' actual status in the IETF process) to me to specify 
not-yet-standard headers as "standards-track" rather than "standard".  The 
wiggle room in the registry spec that allows me to justify this is "or some 
other appropriate value according to the type and status of the primary 
document".  I used the term "standards-track" rather than "Proposed-" or 
"Draft-" because that's what appears on the standards-track RFCs; e.g.
[[
Network Working Group                                 P. Resnick, Editor
Request for Comments: 2822                         QUALCOMM Incorporated
Obsoletes: 822                                                April 2001
Category: Standards Track
]]
I concede that consistency might suggest "Proposed-" or "Draft-", but I 
don't see any added value in having such fine detail in the registry.

I think my approach is entirely in the intended spirit of the registry, 
which is to help prospective designers and users (a) find information about 
the variety of headers in use, and (b) to record any additional information 
about their suitability for use, rather than to attempt to provide detailed 
information that is available elsewhere.

Having said all the above, I think this is a small matter, probably not 
deserving of too many debating cycles.

(more comments below...)

At 20:35 14/05/04 +0000, Charles Lindsey wrote:
>In <[email-masked]> Graham Klyne 
><[email-masked]> 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:
>
>On looking into this further, I find myself confused :-( .
>
>In the IETF scheme of things, a standards-track document can be either
>"proposed astandard", "draft standard" or (full) "standard".
>
>However, in draft-klyne-msghdr-registry-07.txt (which I presume is the
>final approved draft) I find, under the registration template in 3.2.1:
>
>    Status:
>       Specify "standard", "experimental", "informational", "historic",
>       "obsoleted", or some other appropriate value according to the type
>       and status of the primary document in which it is defined. For
>       non-IETF specifications, those formally approved by other
>       standards bodies should be labelled as "standard"; others may be
>       "informational" or "deprecated" depending on the reason for
>       registration.
>
>This seems to suggest that all the varieties of standard-track document
>are to be lumped together and assigned the status "standard".
>
>Which would actually make things simpler and avoid possible confusions
>when the latest document is proposed/draft but is intended to supersede an
>earlier full standard.
>
>It also means that ALL your "standards-track" statuses in
>draft-klyne-hdrreg-mail-03.txt should be changed to "standard" (note that
>you have currently changed some of them to "standards", which is not
>quite the same thing :-( ).

Oops, good catch!   Was a typo.  I found Keywords and Resent-to having this 
error.  I think that's all.  Absent any major issues with this -05 
revision, I propose to request a last call and fix this later.

>Note that, in the IANA Considerations section of USEFOR, I have followed
>the registration template as written, and used "standard" throughout.
>
>Methinks it is high time that the IESG appointed a "designated expert" as
>required by the now-accepted-draft.

I assume, in the scheme of things, this would happen as the RFC editor, 
IANA and IESG interact during the RFC publication process.  I guess it's 
the IESG's call how to play this now you raise it.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

To: [email-masked]
Xref: clerew local.mime:3148
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: More on mail message header fields
Date: Fri, 14 May 2004 20:35:20 GMT
Lines: 52
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> 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:

On looking into this further, I find myself confused :-( .

In the IETF scheme of things, a standards-track document can be either
"proposed astandard", "draft standard" or (full) "standard".

However, in draft-klyne-msghdr-registry-07.txt (which I presume is the
final approved draft) I find, under the registration template in 3.2.1:

   Status:
      Specify "standard", "experimental", "informational", "historic",
      "obsoleted", or some other appropriate value according to the type
      and status of the primary document in which it is defined. For
      non-IETF specifications, those formally approved by other
      standards bodies should be labelled as "standard"; others may be
      "informational" or "deprecated" depending on the reason for
      registration.

This seems to suggest that all the varieties of standard-track document
are to be lumped together and assigned the status "standard".

Which would actually make things simpler and avoid possible confusions
when the latest document is proposed/draft but is intended to supersede an
earlier full standard.

It also means that ALL your "standards-track" statuses in
draft-klyne-hdrreg-mail-03.txt should be changed to "standard" (note that
you have currently changed some of them to "standards", which is not
quite the same thing :-( ).

Note that, in the IANA Considerations section of USEFOR, I have followed
the registration template as written, and used "standard" throughout.

Methinks it is high time that the IESG appointed a "designated expert" as
required by the now-accepted-draft.

-- 
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: [email-masked]      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

Date: Wed, 12 May 2004 17:37:31 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: More on mail message header fields
Sender: [email-masked]

> 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.

To: [email-masked]
Xref: clerew local.mime:3146
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: More on mail message header fields
Date: Wed, 12 May 2004 13:19:54 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> 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: [email-masked]      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

Date: Fri, 07 May 2004 13:39:27 +0100
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: More on mail message header fields
Cc: Keith Moore <[email-masked]>, [email-masked], Jacob Palme <[email-masked]>
Sender: [email-masked]

At 12:19 30/04/04 -0400, Keith Moore wrote:
>IMHO The Encrypted field never was adequately specified.  If 2026 criteria 
>had been in effect when rfc 822 was published, 822 would have had to been 
>revised to remove Encrypted in order to move it to Draft.
>
>so yes it's obsolete, but not because it was omitted from 2822.  do you 
>have a status "fatally flawed"?

(In case that wasn't entirely in jest:) No.  But I'll extend the annotation 
to make the point about inadequate specification.

#g
--

>On Apr 30, 2004, at 10:08 AM, Graham Klyne wrote:
>
>>
>>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:
>>
>>1.  Are there any other mail header fields that have achieved full 
>>standard status?
>>
>>2.  RFC2822 dropped the "Encrypted" header field which was defined in 
>>RFC822.  I take that to mean it is regarded as obsolete;  would this be 
>>correct?  My current proposed entry for this is:
>>[[
>><http://id.ninebynine.org/wip/2002/IETF/HeaderField#Encrypted>
>>     a hdr:HeaderField ;
>>     hdr:fieldName "Encrypted" ;
>>     hdr:label "Message encryption information" ;
>>     hdr:protocol hdr:Protocol_mail ;
>>     hdr:status "obsolete" ;
>>     hdr:author hdr:Author_IETF ;
>>     hdr:controller hdr:Author_IETF ;
>>     hdr:specification hdr:RFC822 ;
>>     hdr:comment
>>         """Defined by RFC 822, but removed in RFC 2822.
>>            Current practice is to use separate encryption, such
>>            as S/MIME or OpenPGP, possibly in conjunction with
>>            RFC 1847 MIME security multiparts.
>>         """ .
>>]]
>>
>>#g
>>--
>>
>>[1] http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-04.txt
>>
>>
>>------------
>>Graham Klyne
>>For email:
>>http://www.ninebynine.org/#Contact
>
>------------
>Graham Klyne
>For email:
>http://www.ninebynine.org/#Contact

Date: Fri, 07 May 2004 13:44:17 +0100
To: "Charles Lindsey" <[email-masked]>, [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: More on mail message header fields
Sender: [email-masked]

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

>In <[email-masked]> Graham Klyne 
><[email-masked]> 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

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

To: [email-masked]
Xref: clerew local.mime:3143
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: More on mail message header fields
Date: Mon, 3 May 2004 10:07:27 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> 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: [email-masked]      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