To: "D. J. Bernstein" <djb@cr.yp.to>
Cc: drums@cs.utk.edu
Subject: Re: folding inside quoted local parts 
In-Reply-To: "D. J. Bernstein"'s message of "16 Apr 1998 19:20:16 +0000."
References: <19980416192016.22116.qmail@cr.yp.to> 
Date: Fri, 17 Apr 1998 16:00:51 +1000
Message-Id: <23191.892792851@munnari.OZ.AU>
From: Robert Elz <kre@munnari.OZ.AU>

    Date:        16 Apr 1998 19:20:16 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <19980416192016.22116.qmail@cr.yp.to>

  | I'm inclined to say yes, and to say the first one;

That's what the next draft of 822bis is supposed to be going to make
quiet clear.    We agreed with that interpretation.

  | That's how RFC 822 specified the unfolding process:

Yes, the unfolding process, there and in the replacement, have been fairly
clear, what has been unclear was the folding process, which seemed to
imply that any number of spaces could be added, or deleted, or something.
That will be fixed, no spaces will be able to be added, just a CRLF before
white space.

  | Note that, contrary to the recent discussion here, this rule applies to
  | _all_ fields, whether or not they are structured.

What contrary discussion?   I think it has always been clear that all
fields can be folded.   The only difference is that in structured fields,
(outside of quoted strings, comments and dtext, which are each more or
less equivalent to unstructured test inside themselves) folding happens where
WSP can occur, and wherever that is possible, any amount of space can be
present, and all means the same, so it is immaterial how many spaces are
removed or added.

  | More importantly, it would simplify implementations if this rule were
  | followed at an early stage of parsing.

That would seem to be up to the implementation - as long as the effect is
the same, when the implementation chooses to have it happen is beyond the
scope of the spec.

In structured headings I suspect we may have some places where CRLF
can't be inserted - and certainly, it is explicit that if there happen to
be two spaces in a row, you can't stick a CRLF before each of them - we
have explicitly prohibited lines containing only whitespace as causing too
many problems.

  | One consequence of this is that 822 cannot express an address with an
  | internal line ending, even if the next character is a space. Oh well.

Yes, sigh...     I think it turns out that no 822 elements can contain
line endings (not just addresses).

kre