headers
Frank Ellermann | 16 Sep 00:13
Picon
Picon

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


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.

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Charles Lindsey | 20 Sep 15:33
Picon
Picon

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


In <fchleg$rj$1 <at> sea.gmane.org> "Frank Ellermann" <nobody <at> xyzzy.claranet.de> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ellermann | 21 Sep 19:23
Picon
Picon

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


Charles Lindsey wrote:

 [magic SP] 
> 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.

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 24 Sep 16:13
Picon
Picon

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


In <fd0unn$5t9$1 <at> sea.gmane.org> "Frank Ellermann" <nobody <at> xyzzy.claranet.de> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane