Tom Petch wrote:
Perhaps, in a year or two, when the surrounding landscape
is more stable, there will be scope for a revision
I did consider to "bet on 2822upd" as the "faster horse".
See a recent thread on the SMTP list about email-arch I18N,
EAI, 2822upd, and all the rest for the context of "bet".
And in an older thread on the rfc822 list I noted that IFF
RFC.usefor-usefor gets a last minute AUTH48 update for a
simplified 2822upd the same should happen for news: URIs.
But technically it is unnecessary, the RFC.usefor-usefor
syntax works, it permits some constructs working with NNTP
for better 2822-compatibility, and it eliminates anything
in 2822 that definitely won't work with NNTP.
Meanwhile (after the news URI PubReq) 2822upd might end up
with a simpler syntax for both sides of the Message-IDs,
that's good when it's ready. It will still have anything
that was allowed in 2822 as "obs-*" syntax, including what
RFC.usefor-usefor has, but also including what won't work
as far as RFC.usefor-usefor and NNTP are concerned.
What I considered (as "faster horse") was to replace the
normative RFC.usefor-usefor reference by 2822upd. But it
wont't fly, I need more RFC.usefor-usefor limitations:
No 2822(upd) obs-*, no ">", and arguably the length limit.
An attempt (before the Last Call) to discuss the chances
of last minute updates in RFC.usefor-usefor on the USEFOR
list got no replies, therefore "let's see what happens" is
IMO good enough, nothing is "wrong" with RFC.usefor-usefor
from my POV. Hopefully 2822upd will further simplify the
2822upd certainly won't remove the "@" between LHS and RHS,
for news URIs that is older than RFC 1738, I found it also
in RFC 1630.
I could add RFC 1630 to the references if that helps (?).
BTW, RFC 1630 mentions the mid: and cid: schemes, specified
later in another RFC, that other RFC might need an update
when 2822upd got its number, no lack of opportunities to do
While I'm at it, to grok the mailto-bis draft it IMO helps
to read the news-URI memo "as is". For a simplified syntax
that trick can't work.
I did not understand the second paragraph of s8.3 at first
and believe that this should be made clearer, in line with
the explanation that the author provided on the uri.w3.org
I posted a -09 after you wrote that, also including feedback
from you, but I didn't say more in -09 about the old glitch
in the MIME registries, let IANA fix it and be done with it.
IETF mailing list