Re: Just got AUTH48 notice for USEPRO
Julien ÉLIE <[email protected]> Sat, 18 Apr 2009 13:19:03 +0200
| Newsgroups | gmane.ietf.usenet.format |
|---|---|
| Organization | TrigoFACILE -- http://www.trigofacile.com/ |
| Message-ID | <7CFAF1AD2506465CA5BF2B008A857C9D@Iulius> |
Hi Charles,
> When the update to RFC 2822 was being discussed, some of us lobbied for
> changes to the <msg-id> syntax that would avoid those technical problems
> with Netnews and, much to our surprise, we managed to get 95% of what we
> wanted. In fact, they went further than we asked, by entirely removing
> NO-WS-CTL, <quoted-string>s and <quoted-pair> from <msgid>
That's a nice improvement. It then also simplifies what RFC 3977 states
about such quoted strings:
This specification states that message-ids are the same if and only
if they consist of the same sequence of octets. Other specifications
may define two different sequences as being equal because they are
putting an interpretation on particular characters. RFC 2822
[RFC2822] has a concept of "quoted" and "escaped" characters. It
therefore considers the three message-ids:
<[email protected]>
<"ab.cd"@example.com>
<"ab.\cd"@example.com>
as being identical. Therefore, an NNTP implementation handing email
articles must ensure that only one of these three appears in the
protocol and that the other two are converted to it as and when
necessary, such as when a client checks the results of a NEWNEWS
command against an internal database of message-ids. Note that
RFC 1036 [RFC1036] never treats two different strings as being
identical. Its successor (as of the time of writing) restricts the
syntax of message-ids so that, whenever RFC 2822 would treat two
strings as equivalent, only one of them is valid (in the above
example, only the first string is valid).
It is now clearer with RFC 5322 and... 5536!
> A. RFC 5322 no longer defines <utext>. Instead, it uses VCHAR from RFC
> 5234, which comprises the old <utext> with all the control characters
> (NO-WS-CTL) omitted (and we don't really want those control characters
> either). So, in our section 2.2 you would now write:
>
> unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
>
> (which still differs from <unstructured> in RFC 5322 by requiring at least
> one visible character). You also need to remove <utext> from 1.4 and add
> VCHAR in its place.
It still a subset of RFC 5322 even though our <unstructured> is not contained
in theirs (we do not allow "Distribution:\r\n" whereas RFC 5322 does
for instance).
I think your new definition is good.
> B. I see that <date-time> in RFC 5322 has added an extra FWS that was not
> there before, but that is compensated by removal of an FWS in <year>, so I
> do not think it affects us. Likewise various other shuntings around of FWS
> within <date-time>.
But we still keep obsolete GMT-like constructions.
> Comparison of all that with the present text will show that it is
> considerably shorter, and much easier to understand.
Absolutely. I believe your suggested changes should be applied during AUTH48.
--
Julien ÉLIE
« Rubor, tumor, dolor, calor et functio laesa. »