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). 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).
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.
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). 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.
> Instead, I'm thinking of
suggesting that agents SHOULD generate messages that honor current news
restrictions (e.g., no Received headers, tighter Message IDs, SP after
colon in all headers), while saying that agents compliant with the spec
MUST accept RFC 2822 syntax. That way, implmenters know what to do to
maximize the likelihood that their messages will be processed, but
there's also a push toward supporting a universal Internet Message
Format syntax across all messaging protocols.
Of course, once the uniquely news syntax is specified clearly (i.e.,
against the context of RFC 2822), the WG (assuming it's rechartered) can
hash out all the MAYs, SHOULDs, and MUSTs.
For backwards compatibility, conforming to the more restrictive 1036
syntax, along with the additional restrictions which 2822 imposed,
should be a MUST for generation of new articles (i.e. don't send
unexpected cruft to existing implementations, and don't send obsolete
cruft either). Some of the 2822 obs- syntax was never legal in news
articles, so mandating acceptance of the full complex obs- syntax
might be construed as an unnecessary burden. Note, however, as
mentioned before on Usefor, at least one of the obs- constructs
(unquoted dot in a phrase) is intended to be a furture relaxation of
the syntax, so the whole obs- syntax area will require careful
review. For clarity to implementors, we should make it quite clear
that to the extent possible, convergence of the article format and
general message format is a goal (e.g. the SP-after-colon requirement
may be removed in a future revision, implementors should not assume
the presense of a space after colon).
Received fields deserve a bit of discussion. Carrying them through
mail->news->mail via gateways would probably be a bad idea, as
some mail transport software counts Received fields as part of
loop detection. I believe they are elided by most, if not all,
mail->news gateways, and that seems reasonable.
That raises a related issue; we should define a set of "trace"
fields for news transport (that would of course include Path)
as 2822 has some handling requirements (sections 3.6, 3.6.6, 3.6.7)
regarding them.