ietf-822
[Top] [All Lists]

Re: Is Content-type an RFC822 "structured header"?

1999-05-21 10:23:28
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 this field:

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=
    "longboundarystringwrappedtonextlinetolimitlinelength"

Then you had:

Content-type: image/
   tiff
   ;
   boundary
   =
   "longboundarystr
   ingwrappedtonextli
   netolimitlinelength"

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

longboundarystringwrappedtonextlinetolimitlinelength

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 semantically ignored.

pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102