headers
Charles Lindsey | 3 May 2004 12:07
Picon
Picon

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
Permalink | Reply | 3 comments |
headers
Graham Klyne | 7 May 2004 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)

Permalink | Reply | 2 comments |
headers
Graham Klyne | 7 May 2004 14:39

Re: More on mail message header fields


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:
>>[[
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 12 May 2004 15:19
Picon
Picon

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)

Permalink | Reply | 1 comment |
headers
Keith Moore | 12 May 2004 23:37
Picon

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.
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 14 May 2004 22:35
Picon
Picon

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:

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graham Klyne | 17 May 2004 11:37

Re: More on mail message header fields


[[[
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 21 May 2004 11:12
Picon
Picon

Re: More on mail message header fields


In <5.1.0.14.2.20040517101456.02fd64a8 <at> 127.0.0.1> Graham Klyne <GK-lists <at> ninebynine.org> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 25 May 2004 10:12

Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard


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).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Crocker | 26 May 2004 06:58

Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard


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:dcrocker <at> brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
Permalink | Reply | 1 comment |

Gmane