Charles Lindsey wrote:
OK, both you and Ned have stated that bare CR, LF, and NUL have indeed
been seen in Real World messages in the past, and that is a sufficient
answer to my point.
As it happens I think it answers nothing. Of course "invalid" messages
exist, otherwise a one-liner message = *CHAR would suffice to permit
NUL crashed my good old Netscape 3 MUA, that would justify a bug report
(over a decade ago), it can exit with an error message, but it should
not crash. Do we really need to add a NUL in "obs" syntax everywhere
only to convince implementors that messages can be worse than they
The "obs" chapter boils down to "MUST accept". I don't see why anybody
would wish, let alone must, accept NUL in Internet messages. The same
goes for NO-WS-CTL uses in domain literals. I understand "MUST accept"
if it was used somewhere, but I think it's now cruft left over from
RFC 822, when new exotic networks (Maus, Z, etc.) were still created:
Nobody ever used NO-WS-CTL in domain literals, and that won't change.
we should be anticipating that some future standard (probably well
after 2010) may well decide that the time has come to ditch it.
IMO the job *now* is to get rid of as much cruft as possible, shifting
it to "obs" is not the same as "get rid of". They could reintroduce
it in the future if they miss it. AFAIK the 2822 "obs"-chapter has
to pass in an "implementation and interoperability report". If some
2822-obs-features are not only obsolete, but not implemented and maybe
causing havoc they have to be pulled *now*.
Or maybe I'm wrong, the "2821bis to DS" cabale was obviously annoyed
when I mentioned RFC 2026 and the "interop" rules. It's still beyond
me how a "good PS" could be not always better than a "less good DS".
And <msg-id>s are hardly of use in the email environment, except
for threading using References, whereas they are fundamental to
the operation of Netnews.
Now you're getting carried away, a <msg-id> is also useful in email,
for threading and mail2news as you said, also for some applications
of Archived-At (RFC 5064) or similar archiving purposes. And my old
MUA had other local uses related to forwarding by mailbox URL, IIRC.
Another "feature" of <msg-id> is that nobody needs to reinvent it.
Wrt to the "magic SP", it's a known USEFOR rathole, and as far as
I'm concerned not important enough to delay 2822upd, which could
end up in incompatibilities with 2821bis if the IESG approves it
before 2822upd is ready. After all they Last Called 2821bis, IMO
dangerously near to SNAFU for oddities like an "IPvFuture literal"
still allowing (in ABNF) 2822 NO-WS-CTL unless 2822upd fixes this,
and 2821bis fixes the normative reference (note a lot of IFs here).