- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Sun, 24 Feb 2008 03:27:05 +0100
- To: uri@w3.org
Clive D.W. Feather wrote on the NNTP list 2007-11-28: >>> RFC 3977 is much more generous in what it allows: >>> message-id = "<" 1*248A-NOTGT ">" >>> A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" >> OK, we have essentially two possibilities: >> 1. restrict it to the USEFORE msgid syntax >> 2. allow the wider RFC 3977 syntax >> The point I was making was that if we went for #1, >> as Franks draft proposes, then we should use the >> syntax given in USEFOR normatively, rather than >> inventing yet-another-version-of-it. > Agreed. But I don't accept #1. It is required for backwards compatibility among other reasons. Almost all RFCs specifying something in the direction of a Message-ID use the pattern <unique@domain> with a syntax based on the <local@domain> pattern in email addresses. Notably that is also what RFC 822, RFC 1036, RFC 1738, s-o-1036, RFC 2822, RFC.usefor-usefor, and 2822upd do, known problems in 822 and 2822 not withstanding. RFC 977 is based on RFC 850 (obsoleted by 1036), and RFC 850 is based on RFC 822, so that is arguably also about a Message-ID with "@". RFC 733, the predecessor of RFC 822, still used the clause "at" instead of "@", separated by LWSP from the LHS (local / unique) and the RHS (domain). This is now ancient history, and a proposal to add syntax in 2822upd for occasionally parsing 733 messages did not fly on the rfc822 list. Obviously RFC 2822 ignored what works for NNTP, and RFC 3977 ignored what works for s-o-1036 and RFC 1738. The IETF USEFOR WG missed that there is a problem with the most fundamental aspect of Netnews, the Message-ID, for some years. There were two separate drafts about the Message-ID in 1998, both of course using "@". IIRC in 2004 the USEFOR WG figured out that NO-WS-CTL, permitted in (2)822, won't fly with NNTP, and fixed it in the new "usefor-usefor" series of drafts leading to what is now RFC.usefor-usefor. It defines the maximal proper subset of RFC 2822 still working with NNTP. The Gilman drafts about the news and nntp URI schemes in 1998 tried to unify both schemes, allowing to point to specific servers and groups also in news URLs. For this purpose it's essential to distinguish Message-IDs, NNTP article numbers, and newsgroup names syntactically. To some degree it worked, the augmented news syntax was widely adopted, today the nntp syntax is rarely used. It is still needed if folks really want an NNTP article number, and purists might still prefer the RFC 1738 nntp syntax for talking about a group on a specific server - the RFC 1738 news syntax did not offer this, this is a "new" (1998) feature of the Gilman drafts. With article numbers out of the way (by restricting them to nntp URLs as in RFC 1738) the news scheme still needs a clear syntactical distinction between a Message-ID and a newsgroup name. This clear distinction is the "@", as found in RFC 1738, the Gilman drafts, and in STD 66 <gen-delims>. In other words RFC 3986 has precisely what's needed as a general delimiter. That RFC 3977 doesn't need the "@" for its own purposes is understood. But RFC 850 was published in 1983, for about 25 years Message-IDs have an "@", and RFC 1738 was published 1994, for about 14 years news URLs have an "@" when talking about a Message-ID. The news-nntp-URI draft tries to document common practice based on RFC 1738 (as amended by the Gilman drafts) with the minimal updates needed for STD 66 for these schemes. It expressly does not try to introduce some new features theoretically permitted in RFC 3977, when that could harm interoperability or backwards compatibility. When users see a news URL they should be confident that it works for them no matter which UA or server they use. Likewise users creating some news URL should be confident that this works for any UA and server, provided that the article or newsgroup (still) exists on this server. It makes no sense to allow hypothetical Message-IDs without "@" in news URLs when that is not allowed in any 2822upd or RFC.usefor-usefor message. Frank
Received on Sunday, 24 February 2008 02:25:52 UTC