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