Re: Just got AUTH48 notice for USEPRO

I think I like this, but would definitely want other people to take a 
look too.

              Harald

Charles Lindsey wrote:
> In <[email protected]> "Charles Lindsey" <[email protected]> writes:
>
>   
>> I have looked as USEFOR so far, and the RFC-Editor has changed a host of
>> nits to meet his "house style" and they mostly seem fine.
>>     
>
>   
>> But there is one big issue, and that is he wants to replace RFC 2822 with
>> RFC 5322 throughout. That is fine by me, but if we do it for one we need
>> to do it for both, and in the case of USEFOR it would require a
>> considerable pruning of the syntax of <msg-id>.
>>     
>
>   
>> Essentially, the USEFOR syntax is a strict subset of the RFC 2822 syntax,
>> but NOT of the RFC 5322 syntax. And since the changes of syntax between
>> 2822 and 5322 were made at the express request of us Usenet folk, it would
>> seem churlish not to adopt them (especially since doing so would remove a
>> singularly long and ugly set of now unnecessary syntax rules).
>>     
>
>   
>> Therefore, I propose that we should do that. I will try to produce the
>> necessary textual changes in the next few days.
>>     
>
> OK, I think the issue of whether to rebase the documents on RFC5322 rather
> than RFC2822 requires some input from the WG. The Rfc-Editor seems to
> think it should be done, and she has provisionally edited both documents
> that way. And it it will indeed get us out of various awkward corners
> regarding the IANA registrations of the various header fields and other
> such editorial confusions, so I personally would support it.
>
> In USEPRO (now RFC5537) it is easily done, but in USEFOR (now RFC5536)
> there are some consequential changes that would be needed. Here is what I
> have reported to the other editors for their consideration. Some comment
> on my proposals from the WG is desirable.
>
> -----------------------------------------------------------------------------
>
> At the time the USEFOR draft was submitted for Last Call, RFC 2822 was
> still current. For severe technical reasons, the syntax of <msg-id> was
> totally unsuited to Netnews, hence the cumbersome and ugly syntax you see
> in 3.1.3 which contained the minimal change that would work and yet still
> allow us to say, in 2.2 (and also in Appendix C):
>
>    ....  The syntax allowed for Netnews
>    article headers is a strict subset of the "Internet Message Format"
>    headers, making all headers compliant with this specification
>    inherently compliant with [RFC2822].  ...
>
> 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>, which was
> fine, except that now Netnews has become, in some parts, a superset of the
> new RFC 5322, so the sentence quoted above is no longer true.
>
> Personally, I would be happy to move the whole thing to be based on RFC
> 5322, but it would require some consequential changes to restore that
> 'subset' situation. But I think we would need to check back with the WG
> before going ahead. Here is what would be needed:
>
> 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.
>
> 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>.
>
> C. Section 3.1.3 would need to be written as follows:
>
> 3.1.3.  Message-ID
>
>    The Message-ID header field contains a unique message identifier.
>    Netnews is more dependent on message identifier uniqueness and fast
>    comparison than Email is, and some news software and standards
>    [RFC3977] might have trouble with the full range of possible
>    <msg-id>s permitted by [RFC5322].  This section therefore restricts
>    the syntax of <msg-id> as compared to Section 3.6.4 of [RFC5322].
>    The global uniqueness requirement for <msg-id> in [RFC5322] is to be
>    understood as applying across all protocols using such message
>    identifiers, and across both Email and Netnews in particular.
>
>    message-id      =  "Message-ID:" SP *WSP msg-id *WSP CRLF
>
>    msg-id          =  "<" msg-id-core ">"
>                       ; maximum length is 250 octets
>
>    msg-id-core     =  id-left "@" id-right
>
> {{EDITORIAL NOTE: Those still remove the possibility of <comment>s; it
> also introduces <msg-id-core> which is a useful concept (though I don't
> think either document uses it any more).}}
>
>    id-left         =  dot-atom-text
>
>    id-right        =  dot-atom-text / no-fold-literal
>
> {{EDITORIAL NOTE: Those are actually identical to RFC 5322 if you apply
> the blanket removal of obs-syntax in 2.1; but it might be kinder to leave
> them in.}}
>
>    no-fold-literal =  "[" *mdtext "]"
>
>    mdtext          =  %d33-61 /        ; The rest of the US-ASCII
>                       %d63-90 /        ; characters not including
>                       %d94-126         ; ">", "[", "]", or "\"
>
> {{EDITORIAL NOTE: <mdtext> replaces <dtext> from RFC 5322 (or you could
> simply redefine <dtext>); the effect is to remove ">".}}
>
>    The msg-id MUST NOT be more than 250 octets in length.
>
>       NOTE: The length restriction ensures that systems that accept
>       message identifiers as a parameter when referencing an article
>       (e.g.  [RFC3977]) can rely on a bounded length.
>
>    Observe that msg-id includes the < and >.
>
>    Observe also that in contrast to the corresponding header field in
>    [RFC5322]:
>
>    o  The syntax does not allow comments within the Message-ID header
>       field,
>
>    o  There is no possibility for ">" to occur inside a <msg-id>.
>
> {{EDITORIAL NOTE: I have removed the bullet about <id-rights>s now being
> case-sensitive because I cannot see that they ever were so even in RFC
> 2822, and if they were then we have done nothing to change that.}}
>
>    This is to simplify processing by news servers and to ensure
>    interoperability with existing implementations and compliance with
>    [RFC3977]. Moreover, a simple comparison of octets will always suffice
>    to determine the identity of two <msg-id>s.
>
> {{EDITORIAL NOTE: I think that last sentence is now also true of RFC 5322,
> but it is still useful to emphasise it.}}
>
>    Also note that this updated ABNF applies wherever <msg-id> is used,
>    including the References header field discussed in Section 3.2.10 and
>    the Supersedes header field discussed in Section 3.2.12.
>
>    Some current software may try to match the <id-right> of a <msg-id> in
>    a case-insensitive fashion; some may match it in a case-sensitive
>    fashion.  Implementations MUST NOT generate a Message-ID where the only
>    difference from another Message-ID is the case of characters in the
>    <id-right> part.
>
>    When generating a <msg-id>, implementations SHOULD use a domain name
>    as the <id-right>.
>
>       NOTE: Section 3.6.4 of [RFC5322] recommends that the <id-right>
>       should be a domain name or a domain literal.  Domain literals are
>       troublesome since many IP addresses are not globally unique;
>       domain names are more likely to generate unique Message-IDs.
>
>
> Comparison of all that with the present text will show that it is
> considerably shorter, and much easier to understand.
>
> -----------------------------------------------------------------------------
>
>