Re: FWS problem

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <41D373A4.5E28@xxxxxxxxxxxxxxxxx> Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> writes:

>Charles Lindsey wrote:

> [NO-WS-CTL in utext]
>> Indeed, but politically impossible to change it unilaterally.

>Sooner or later you get me to believe in this IETF-2822-cabal,
>and then I'll start unilaterally a war against it.

Yes, please do. When they start to develop RFC 2922bis, please join in and
get them to remove some of their stupidities. But not now, for USEFOR.


>> you have forbidden, for example:
>> Supersedes:  (a comment)
>>     <abcd@xxxxxxxxxxx>
>>     (another comment)

>Yes, "Supersedes:" is an odd case, it's no 2822 header, and you
>have already restricted it to one msg-id, s-o-1036 had a list.
>Here are some alternatives:

No, "Supersedes:" is just the example I chose to give. In fact, the
problem arises eberywhere you propose to use *WSP, even in the References
header (even though comments are "SHOULD NOT generate yet" there).


>They do have FWS in their syntax where they needed it, e.g. a
>Date: header has no CFWS before or within the date, only at the
>end.

Yes, that was an explcit exception put into RFC 2822 after discussion.

But everywhere else it was understood that comments would be allowed
wherever WSP was allowed. You can't have them in some headers but not in
others, because no-one can be expected to remember which cases are which.
There is no reason for us to break with that principle (indeed, taking it
on board was one of the first things this WG did). It was only because of
loud protests by the server implementors that we agreed to make exceptions
for the Newsgroups and Path headers, etc, but only on account of the
performance hits. It was _never_ the intention to exclude them for other
News headers, even for ones that we invented.


>Sure, I wanted our syntax to _reflect_ our MUST where possible,
>not to _replace_ it.  And it's not worth the effort for [CFWS],
>if that means that we need a CWSP and a WSPC.  But for [FWS]
>it's possible.

If there is something you want to forbid in a standard (such as empty
header lines, etc), then it is an exceedingly Bad Idea to have two
mechanisms for forbidding it, one for some cases and another for others.
It is a recipe for confusion and for the introduction of unintended
errors (of which your failure to allow header lines containing just a
comment was a typical example).

-- 
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: chl@xxxxxxxxxxxxxxxx      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