Re: Malformed header - what would you do?

In <[email protected]> Bruce Lilly <[email protected]> writes:

>On Thu July 21 2005 18:20, Frank Ellermann wrote:
>> 
>> Bruce Lilly wrote:

[Snipped lots of irrelevant arguments where Bruce is destroying Frank's
Red Herrings, or vice versa.]

And proceeding to the _only_ point that has merit, and needs to be taken
seriously.

>> > A conforming generator is still bound by the normative
>> > provisions of section 3, including 3.2.3.
>> 
>> That talks only about "CFWS"..."MUST NOT", but the problem is
>> the FWS in <unstructured>.  If you'd want to fix it in prose:
>> s/where CFWS occurs/where CFWS or FWS occurs/ in 3.2.3

>Not really, because every instance of FWS is necessarily CFWS
>(but not the converse):

No, you cannot wriggle out of it like that. Since the point is important,
we need to consider it very carefully.

Proposition to Consider:

That the following example (in which SP is represented by "_", so it is
clear exactly where SP is present)

    Subject:_Foo_CRLF
    _CRLF
    _Bar_CRLF

is lawful to generate in RFC 2822.

Frank maintains the proposition is True. I think he is right. Bruce claims
it is False.

Evidently, the Proposition reduces to showing that

    _Foo_CRLF
    _CRLF
    _Bar_CRLF

is a legally generateable <unstructured>, where

    unstructured    =       *([FWS] utext) [FWS]

It is evidently legal to generate according to that ABNF, so we need to
examine whether or not it is forbidden by 3.2.3.

The relevant sentence of 3.2.3 is:

   However, where CFWS occurs in this standard, it MUST NOT be inserted
   in such a way that any line of a folded header field is made up
   entirely of WSP characters and nothing else.

Observe very carefully what that does NOT say. It does NOT say "where CFWS
occurs in some header field" (which might well be taken to include the
particular case "where FWS occurs in some header field", because
productions of FWS are evidently a subset of productions of CFWS.

What it DOES say is "where CFWS occurs IN THIS STANDARD" (emphasis added).
"This standard" is evidently the document RFC 2822. So we must ask "Does
CFWS occur in the ABNF of <unstructured>", to which the answer is
evidently "No" (if you take 'CFWS' to mean the four characters C F W S in
that order).

Even if you take 'CFWS' to mean "the productions of the ABNF rule 'CFWS'",
the answer is still "No", because the ABNF of <unstuctured> includes only
some of the productions of 'CFWS' - the subsetting is the wrong way round
for the other interpretation in this case.

Hence the ABNF rule for <unstructured> is NOT one of the places where
"CFWS occurs in this standard", and hence the 3.2.3. exception does not
apply to it.

Q.E.D.


Now of course we all know perfectly well that was not the intention, as
Appendix B makes clear. It is a BUG. Nevertheless, that is what RFC 2822
says, and we have to live with it. Clearly, an Erratum sent to the Drafts
Editor would be in order.

Fortunately, the corresponding text in USEFOR does not contain the Bug
(the text in USEFOR is different from that in RFC 2822 because it is
trying to make a somewhat wider prohibition).

[snipped discussion of the remainder of Frank's Red Herrings.]

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