Re: draft-resnick-2822upd-02 and Netnews

In <[email protected]> "Frank Ellermann" <[email protected]> writes:

>Charles Lindsey wrote:

>>| Although in all header fields the CFWS following the colon is
>>| optional, it is customary to place at least one SP there; moreover
>>| such a SP is mandatory in some related protocols (notably [NETNEWS]).
>>| In order to facilitate interoperability with such related protocols,
>>| that SP SHOULD normally be present.

>I'd put it slightly different, AFAIK Netnews is the only case where
>that's necessary, and structured header fields defined outside of
>2822upd tend to use [FWS] instead of [CFWS] after the colon.  And
>unstructured header fields like Subject: also use [FWS].  What I get is:

>| Although all message header fields allow either [FWS] or [CFWS]
>| after the colon, it is customary to place at least one white space
>| character after the colon.  In NetNews articles [RFC xxxx] it's
>| mandatory to use a space character after the colon, and in order
>| to faciliate interoperability implementors might wish to separate
>| the header field name plus colon from the header field body by a
>| space in all Internet messages.

I don't think there is any serious difference between our two wordings
(except that I would still prefer "SHOULD" to "might"). As to other
protocols than Netnews that might be affected, I don't know of any, but
thought it might be useful to allow for the possibility.

>No SHOULD, and carefully avoiding the (in e-mail) sound cases "empty
>header field body" or "colon immediately followed by a folding".  It
>would even cover "HT doesn't help" without explicitly mentioning it.

I never intended that the awkward cases around empty field bodies should
have any explicit mention. I was rather just pointing out why they should
be left out - is spite of a small residual risk of further
non-interoperability.

>> {[NETNEWS] would then be an informative reference to the current
>> USEFOR draft, which has already passed IESG review.}

>BTW, what happens if 2822upd is ready before USEPRO, could you (= the
>USEFOR RFC editors) then still adopt a simplified 2822upd Message-ID
>syntax in AUTH48 ?

For informative references, I think the rules for mentioning drafts have
now been relaxed. But 2822-bis already has normative references to other
drafts which may delay its final adoption. If this ever becomes a serious
problem, an informative reference to RFC 1036 would suffice at a pinch
(but that would be better left to final negotiations with the RFC-Editor).


>>> Wrt the Message-ID I'd be happy if we arrive at a syntax for the RHS
>>> without quoted-pairs and without NO-WS-CTL.  The approved USEFOR I-D
>>> still allows \[, \\, and \].  Let's please get rid of this cruft, it
>>> would be horrible in news-URLs (%5C%5B, %5C%5C, %5C%5D).  Plausible
>>> Message-IDs don't need quoted-pairs in the RHS.  Please correct me
>>> if you know a case (MIXER or similar) where that's not true.
> 
>> Agreed. I would like to get rid of quoted-pair in no-fold-literal even
>> if it is retained in domain-literal. I have no problem in allowing '\'
>> as an allowed character in no-fold-literal - just so long as it has no
>> semantic significance different from any other allowed character.

>Let's better stay away from "\" outside of quoted-pairs,...

My only reason for offering a naked '\' as an "other character" was to
allow any presently allowed no-fold-literal still to be syntactially
allowed, even though now semantically different. It is not a big deal.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email protected]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5