Re: I-D ACTION:draft-resnick-2822upd-01.txt
Frank Ellermann <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | <URL:http://purl.net/xyzzy> |
| Message-ID | <[email protected]> |
[email protected] wrote: > http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt Hi, where's that discussed, is here okay ? For the <msg-id> I'd like to see a syntax also working in NetNews, in news URIs, and in Archived-At links when they use a Message-ID. A "canonical" version of a Message-ID is specified in RFC.ietf-usefor-usefor-12 It has the following features: - once created a Message-ID is "opaque", nobody's supposed to modify its id-right, even if that's a FQDN as it should be, where modifying say mixed case to lower case is tempting. - Message-ID generators shouldn't use <quoted-pair>s unless they must. - There is no NO-WS-CTL in a Message-ID. Based on these concepts a "canonical" Message-ID is something like this: msg-id = "<" msg-id-core ">" ; maximum length is 250 octets The maximum length is for NetNews and NNTP, and maybe this limit is irrelevant for mail. OTOH mail2news would be forced to reject or discard any longer Message-ID if they can't guarantee that all gateways have precisely the same idea how to truncate it. msg-id-core = id-left "@" id-right That's handy for other header fields like References in a NetNews RFC, or in a draft about news URLs, maybe it's unnecesary for mail. id-left = dot-atom-text / no-fold-quote The 2822upd draft adds <obs-id-left> as in 2822, for NetNews the obs-* terms (with two exceptions) aren't used. id-right = dot-atom-text / no-fold-literal Same idea, 2822upd needs also <obs-id-right> for its purposes. no-fold-quote = DQUOTE ( "." *mqtext / *mqtext "." / *mqtext mqspecial *mqtext ) DQUOTE Major difference, 2822upd allows in essence any qtext or quoted-pair. RFC.ietf-usefor-usefor-12 limits <no-fold-quote> to the three cases where it's required: 1: "." *mqtext \/ Something starting or ending with a dot is never 2: *mqtext "." /\ a <dot-atom-text>, therefore it must be quoted 3: *mqtext mqspecial *mqtext All <mqspecial> constructs aren't allowed in <dot-atom-text>, same idea as for the leading or trailing dot issues (1) + (2). mqtext = atext / "." / mqspecial One reason forcing a <no-fold-quote> is enough. Anything else can either as is <dot-atom-text>, i.e. <atext> or ".", or as in the <mqspecial> constructs: mqspecial = "(" / ")" / ; same as specials except "<" / ; "\" and DQUOTE quoted "[" / "]" / ; "." doubled and ">" omitted ":" / ";" / "@" / "," / ".." / "\\" / "\" DQUOTE <mqspecial> is a collection of characters not covered by <atext>, plus '\\' and '\"' as the two <quoted-pair>s needed in the left hand side <id-left> for a <no-fold-quote>. Last but not least it also covers adjacent dots, that's not allowed in a <dot-atom-text>. no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" Major difference, 2822upd allows in essence any dtext or quoted-pair. RFC.ietf-usefor-usefor-12 limits <no-fold-literal> to the one case where it's required: mdtext = %d33-61 / ; The rest of the US-ASCII %d63-90 / ; characters not including %d94-126 ; ">", "[", "]", or "\" That's not the same as <dtext>, it has obviously no NO-WS-CTL. The business about the three '\[', '\]', and '\\' <quoted-pair>s is the same as in 2822 or 2822upd. No other <quoted-pair>s are required in the <no-fold-literal> form of the <id-right>. For its own purposes RFC.ietf-usefor-usefor-12 decrees that a '>' must never occur within a <msg-id> or rather <msg-id-core> because that would break NNTP and other news servers and clients. It's fortunately no issue for news URIs, where '>' is anyway not allowed (and if somebody tries %3E or similar they get what they asked for). I'd like if the one thing that's essential NetNews, the Message-ID, has the same syntax everywhere. We're talking about rare corner cases like domain literals and quoted strings as local parts in a Message-ID, <no-fold-literal> and <no-fold-quote>. As far as these constructs are anywhere used at all they don't need ugly NO-WS-CTLs or unnecessary quoted pairs. I'd also doubt that such constructs survive a serious 2822 implementation and interoperability report. Frank