Subject: Re: draft-resnick-2822upd-02 and Netnews
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Sep 2007 14:13:56 GMT
List-Id: <ietf-822.imc.org>

In <[email-masked]> "Frank Ellermann" <[email-masked]> 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-masked]      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

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: draft-resnick-2822upd-02 and Netnews
Date:  Fri, 21 Sep 2007 19:23:58 +0200
Organization:  http://purl.net/xyzzy
Lines: 63
Sender: [email-masked]

Charles Lindsey wrote:

 [magic SP]=20
> I think the best way around this problem would be to write in some
> text such as:
=20
>| 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.

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.

> {[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 (=3D the
USEFOR RFC editors) then still adopt a simplified 2822upd Message-ID
syntax in AUTH48 ?

At the moment we have something like this (proper subset relations):

For the local part (LHS) :  1036 < 2822upd-03 < USEFOR < 2822 < 822.
For the domain part (RHS):  1036 < USEFOR < 2822upd-03 =3D 2822 < 822.

For a 1738 news URL the RHS is still a host, not a domain literal,
let alone anything with "[", "\", "]", or NO-WS-CTL in a quoted pair.

>> 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.
=20
> 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, no special
exception for Message-ID, References, and In-Reply-To.  IMO it's good
enough to find something that makes sense everywhere (2821bis, 2822upd,
NetNews, news URIs, similar Content-IDs, Archived-At applications, the
In-Reply-To parameter for threading in mailto-bis URIs, and what else).

 Frank

To: [email-masked]
Xref: clerew local.mime:5087
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-resnick-2822upd-02 and Netnews
Date: Thu, 20 Sep 2007 13:33:08 GMT
Lines: 64
Sender: [email-masked]

In <[email-masked]> "Frank Ellermann" <[email-masked]> writes:

>Pete Resnick wrote:

>>> There undoubtedly exists software within Netnews that will break if 
>>> this SP is absent...
>>> ... since it is the invariable practice within email MUAs to include 
>>> this SP, putting such a MUST in email would incur no problems...
>[...]
> 
>> Undoubtedly? Invariable? Use of these words *increase* rather than 
>> decrease my suspicion, and therefore my desire to leave things 
>> exactly as they are now.

>The "magic SP" (mandatory SP after colon) in Netnews is a rather ugly
>Netnews idiosyncrasy.  It's not possible to change it decades after
>RFC 1036.  And it's IMO also not desirable to copy the "magic SP" as
>is to 2822upd-03, example:

>IIRC at the moment (RFC 2822) almost all structured fields use the
>syntax "name:" [CFWS] more-stuff CRLF for some value of more-stuff
>not starting with WSP or comments.

I think the best way around this problem would be to write in some text
such as:

   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.

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

That would still leave possible problems with an email header that was
folded immediately after that SP (as allowed by Email but forbidden by
Netnews), but I think we could live with that (it happens rarely, and
would only cause actual breakage in News systems if some intermediate
agent had discarded that trailing SP).

>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.

-- 
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-masked]      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

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: draft-resnick-2822upd-02 and Netnews
Date:  Sun, 16 Sep 2007 00:13:34 +0200
Organization:  http://purl.net/xyzzy
Lines: 44
Sender: [email-masked]

Pete Resnick wrote:

>> There undoubtedly exists software within Netnews that will break if=20
>> this SP is absent...
>> ... since it is the invariable practice within email MUAs to include=20
>> this SP, putting such a MUST in email would incur no problems...
[...]
=20
> Undoubtedly? Invariable? Use of these words *increase* rather than=20
> decrease my suspicion, and therefore my desire to leave things=20
> exactly as they are now.

The "magic SP" (mandatory SP after colon) in Netnews is a rather ugly
Netnews idiosyncrasy.  It's not possible to change it decades after
RFC 1036.  And it's IMO also not desirable to copy the "magic SP" as
is to 2822upd-03, example:

IIRC at the moment (RFC 2822) almost all structured fields use the
syntax "name:" [CFWS] more-stuff CRLF for some value of more-stuff
not starting with WSP or comments.

You can't simply insert SP between "name:" and [CFWS] because that
would invalidate any "name:" CRLF WSP folding immediately after the
colon.  It would also invalidate "name:" HT with a HTab immediately
after the colon.

What you arguably could do is "name:" CFWS more-stuff with a mandatory
CFWS between colon and more-stuff.  For unstructured fields using the
syntax "name:" [FWS] text you could likewise make the FWS mandatory.

IMO it's far more important to agree on a common Message-ID syntax
for mail and news than to fiddle with the "magic SP".  Maybe you=20
could just mention the "magic SP" issue in a note for implementors
of mail2news gateways and for implementors of combined mail and news
UAs.

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.

Frank