Dan Kohn wrote:
> I'm working on a new version of Kohn draft that captures more of the > semantics from the Lindsey draft about news-specific restrictions. I > believe laying them out against the context of RFC 2822 (rather than > expecting the implementer to compare the documents) will produce the > best interoperability.
If our rechartered goal is still to produce a Standards Track RFC, there may be an issue regarding use of RFC 2822 (which I am informed is incorrectly indicated as Standards Track and that it does not in fact obsolete RFC 822 as stated in the rfc-index).
RFC 2822 does not and cannot obsolete RFC 822 at present, for the simple reason that RFC 822 is a full standard whereas RFC 2822 is only a proposed standard. The intent, however, is for RFC 2822, or more likely a revised version of RFC 2822, to obsolete RFC 822 once it reaches standard status.
This is a reasonably straightforward situation, but a bit more than an entry in the RFC index is capable of expressing.
If so, I believe the approach used in RFC 3282 (which says it's Standards Track), viz. supplying both RFC 822 EBNF and RFC 2822 ABNF may be a solution (the understanding being that they intend to specify the same restrictions).
Any I-D that is intended to become a proposed standard need only refer to RFC 2822; referring to RFC 822 in a normative way is a bad idea at this point. (The situation for an I-D intended for draft is different -- it should be obvious why -- but that's not an issue USEFOR has to deal with.)
As for ambiguities in the MIME documents, while Charles' intent in clarifying those is laudable, it goes too far in the direction of repeating a lot of nitty-gritty detail. How far we go in clarifying those issues is something where our area director may be able to provide some guidance, as he is in a position to know how soon there might be a rewrite of the MIME documents themselves which would remove the ambiguities.
Well, not to put too fine a point on it, but these endless squabbles are at least part of the reason why a MIME update of anything besides part 4 is unlikely to get done by the MIME editor in the near future ;-)
Regardless, if there are outright errors in MIME they should be corrected by RFC Errata. Reiterating material from one standard in another is a bad idea IMO; and you may rest assured I will push back on this practice should a document containing such material ever make it to me for review.
On a related note, IMO there should be a reference in the Status of This Memo section pointing to the errata page at http://www.rfc-editor.org/errat.html That of course isn't applicable to a draft, but when the draft moves to a published RFC, it is invaluable to implementors (the relative obscurity of that page is probably one of the reasons that some implementors have made errors).
The fact that the page hasn't existed for very long is a more likely explanation.
In reference to the use of MIME, it might be prudent to repeat the pointer to the errata page, as there are a number of errata for RFCs 2046, 2047, 2231, and for that matter 1036 (though I sincerely hope the "Re: " hack will be discarded).
> In general, I'm thinking about suggesting a different tact from RFC > 2822, which said that Section 3 current syntax is MUST generate and > Section 4 obsolete syntax is MUST accept.
To be a little more precise, the obs- syntax is MUST accept, MUST NOT generate. The non-obs- syntax still provides a great deal of leeway. Perhaps unnecessarily so; the current msg-id discussions are timely (I believe Pete Resnick stated on ietf-822 a few months ago that he is collecting comments etc. re 2822 in preparation for the next step in its progress) and appropriate.
Agreed. I would not be at all adverse to placing a limit on the size of message ids.
Ned
