John C Klensin wrote:
There are normative dependencies between 2821 and 2822, and
there will be similar dependencies between 2821bis and
2822bis. There are also some syntax productions and other
things that should either match or provide explanations if
they do not.
That's understood, and IMHO no problem: It's perfectly okay
if 2822bis has references to 2821bis. Normative references.
But it's not strictly necessary that 2821bis also references
2822bis, for a few exceptions like <date-time>, <FWS>, and
<CFWS> 2822 is good enough. In a new "collected ABNF" you
could say something like:
FWS = <as defined in 2822 or its successor>
CFWS = <as defined in 2822 or its successor>
; ... (more imported definitions)
That's something you couldn't do in 2821, because 822 didn't
offer some required terms like FWS and CFWS. But now this
works, and that's a major step forward:
2821bis can talk about "mail objects" (message/rfc822) without
mentioning any details except from "has lines of text and a
header".
Dito 2822bis: "for one way to transport message/rfc822 see
2821bis, for other ways to do something with message/rfc822
see MIME, USEFOR, UUCP, avian carrier, HTTP, ..."
A very desirable effect, unless somebody plans to replace
FWS or CFWS by new concepts in 2822bis. That won't happen.
an example: if 2821bis is changed, then either identical
changes need to be made in 2822bis, or the differences
need to be explained
Yes, that's okay, 2822bis should use what 2821bis defines
(assuming that 2822bis is published after 2821bis), "build
on the work of others".
So it would be a really bad idea to try to progress 2821bis
significantly without 2822bis on the (same) table.
Strange, I think it's an excellent idea. Folks often talk
about "From" or "To" or "Sender" mixing (2)821 and (2)822
concepts in strange or impossible ways.
Historically these concepts are of course "related", the
(2)822-Sender was something like the (2)821 MAIL FROM, but
it starts to get interesting where that's not the case.
Huge efforts trying to explain this (like mail-arch), and
dubious efforts trying to "fix" this somehow (like PRA).
If we'd reduce the interface to "trace header fields" it
could be cleaner.
Again, YMMD
Yes, 2822 as-is doesn't reflect NetNews as-is, the latter
format is a proper subset. 2822 as-is also doesn't reflect
common practice for especially the Message-ID. Message-IDs
are essential for NetNews (plus "modern" applications like
the news-URI scheme).
Apparently you're also no big fan of some (2)822 concepts:
| Quoted strings and characters in local parts have, in
| general, been nothing but trouble and there appears to
| be no reason to carry that trouble forward into an
| internationalized world
It's serious trouble for Message-IDs (incl. news-URIs),
and with NO-WS-CTL it's untolerable. We have a similar
CTL-problem here in e.g. <General-Address-Literal> and
<ehlo-greet> - I hope to get rid of this in 2821bis.
Bye, Frank