On 5/21/99 at 10:43 AM +0000, Charles Lindsey wrote:
Fine, but that still does not establish _exactly_ where folding may occur.
You're having a syntax vs. semantics problem.
Folding may *occur* anywhere in a structured field body between any
two tokens in 822 (and by extension 2045). That is to say, you must
accept folding at these places. However, if you have a string of
"unfolded" field contents that you "wish to fold", the only way to do
that is to insert CRLF before a space or a tab. So, similar to your
above example, you can "perform the act of folding" after the "=" in
Content-type: image/tiff; boundary= "blahblahblah"
but you can't "perform the act of folding" after the "=" in this one:
Content-type: image/tiff; boundary="blahblahblah"
However (and this is the important semantic point", the above to
Content-Type fields are semantically identical; the optional CFWS
around the "=" isn't semantically important.
On the other hand, let's look at the two examples that you gave.
First, you had:
Content-type: image/tiff; boundary=
Then you had:
Now, the latter is also a legal RFC 2045 Content-Type line, but it is
not semantically identical to the first. In the former, the boundary
In the latter, the boundary is:
longboundarystr ingwrappedtonextli netolimitlinelength
The act of unfolding only removes the CRLFs.
Once you have a structured field body, you can always "perform the
act of folding" by inserting a CRLF before any white space without
changing the semantics of the field, but you have to understand the
structure of the field to insert more white space without changing
the semantics. In the case of the Content-Type field, only white
space around the "type", "subtype", "attribute" and "value" tokens is
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102