Dan Wing | 19 May 21:40 1999
Picon

multipart/blah

Does anyone know of a specific MUA that doesn't properly deal with
multipart/blah?

By 'properly deal with' I am referring to MUAs which don't recognize
"blah" and also don't treat the multipart as if it were multipart/mixed
(per RFC2046, section 5.1.7).

I have tested Netscape V4.5's mailer and Eudora, both of which seem to 
be happy.

Thanks,
-Dan Wing

Graham Klyne | 20 May 00:46 1999

Is Content-type an RFC822 "structured header"?

A brief review of RFC822 and RFC2045 leaves me slightly uncertain whether
or not a MIME content-type field follows the whitespace insertion rules for
an RFC822 structured header field.

A comment buried in section 5.1 of RFC 2045 (saying that comments may be
inserted in accordance with RFC822 rules for structured header fields)
suggests that this is the intent:

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

   are completely equivalent.

But I cannot find a cleat unequivocal statement either way.

The specific issue as stake here is whether the following is acceptable:

  Content-type: image/tiff; boundary=
    "longboundarystringwrappedtonextlinetolimitlinelength"

#g

(Continue reading)

Ned Freed | 20 May 06:38 1999

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

> A brief review of RFC822 and RFC2045 leaves me slightly uncertain whether
> or not a MIME content-type field follows the whitespace insertion rules for
> an RFC822 structured header field.

It does.

> A comment buried in section 5.1 of RFC 2045 (saying that comments may be
> inserted in accordance with RFC822 rules for structured header fields)
> suggests that this is the intent:

>    Note that the value of a quoted string parameter does not include the
>    quotes.  That is, the quotation marks in a quoted-string are not a
>    part of the value of the parameter, but are merely used to delimit
>    that parameter value.  In addition, comments are allowed in
>    accordance with RFC 822 rules for structured header fields.  Thus the
>    following two forms

>      Content-type: text/plain; charset=us-ascii (Plain text)

>      Content-type: text/plain; charset="us-ascii"

>    are completely equivalent.

In other words content-type is a structured header field.

> But I cannot find a cleat unequivocal statement either way.

Well, I'd call the section you quoted such a statement. But I'll make a note
to clarify this point even further the next time we update the specification.

(Continue reading)

Charles Lindsey | 21 May 12:43 1999
Picon
Picon

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

In <01JBEAGYFIR48WXW2O <at> INNOSOFT.COM> Ned Freed <Ned.Freed <at> innosoft.com> writes:

>> A brief review of RFC822 and RFC2045 leaves me slightly uncertain whether
>> or not a MIME content-type field follows the whitespace insertion rules for
>> an RFC822 structured header field.

>Well, I'd call the section you quoted such a statement. But I'll make a note
>to clarify this point even further the next time we update the specification.

>> The specific issue as stake here is whether the following is acceptable:

>>   Content-type: image/tiff; boundary=
>>     "longboundarystringwrappedtonextlinetolimitlinelength"

>It is completely legal.

Fine, but that still does not establish _exactly_ where folding may occur.
This is currently of concern to me because I am writing the syntax for the
new USEFOR draft (RFC1036bis) and we need to spell it all out in the
syntax in DRUMS style.

So far I have got:

      header-content  = USENET-header-content *( ";" header-parameter ) /
                other-header-content
      header-parameter        = USENET-header-parameter /
                attribute "=" value 
      attribute       = iana-token / x-token
      value   = token / quoted-string
      iana-token      = <A token defined in an experimental or
(Continue reading)

Pete Resnick | 21 May 19:23 1999

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

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"

(Continue reading)

Graham Klyne | 23 May 19:39 1999

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

At 10:43 21/05/99 GMT, Charles Lindsey wrote:

>>>   Content-type: image/tiff; boundary=
>>>     "longboundarystringwrappedtonextlinetolimitlinelength"
>
>>It is completely legal.
>
>Fine, but that still does not establish _exactly_ where folding may occur.

I beg to differ, in this case, because RFC822 (cited directly by the MIME
document) describes the lexical analysis of structured header fields:

     3.1.4.  STRUCTURED FIELD BODIES

        To aid in the creation and reading of structured  fields,  the
        free  insertion   of linear-white-space (which permits folding
        by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
        Rather  than  obscuring  the  syntax  specifications for these
        structured fields with explicit syntax for this  linear-white-
        space, the existence of another "lexical" analyzer is assumed.

and

        These symbols are:

                     -  individual special characters
                     -  quoted-strings
                     -  domain-literals
                     -  comments
                     -  atoms
(Continue reading)

Graham Klyne | 23 May 19:39 1999

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

Ned,

Thank you for your clarification.

>> The specific issue as stake here is whether the following is acceptable:
>
>>   Content-type: image/tiff; boundary=
>>     "longboundarystringwrappedtonextlinetolimitlinelength"
>
>It is completely legal.

This is what I believed.  But is it wise?

I ask this question because we have have found in early interoperability
testing that such headers can cause problems with other vendors' software.
Does your experience suggest that deployed MIME implementations generally
allow this form?

#g

------------
Graham Klyne
(GK <at> ACM.ORG)

Ned Freed | 23 May 19:47 1999

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

> Ned,

> Thank you for your clarification.

> >> The specific issue as stake here is whether the following is acceptable:
> >
> >>   Content-type: image/tiff; boundary=
> >>     "longboundarystringwrappedtonextlinetolimitlinelength"
> >
> >It is completely legal.

> This is what I believed.  But is it wise?

Not really. While I doubt that many implementations would have trouble
unfolding this, using really long boundary markers where such a fold makes
sense isn't necessary, so why take the chance?

> I ask this question because we have have found in early interoperability
> testing that such headers can cause problems with other vendors' software.
> Does your experience suggest that deployed MIME implementations generally
> allow this form?

All sorts of egregiously incompliant implementations exist, of course. So as
always it is best to be liberal in what you accept, conservative in what you
emit.

But unfolding tends to be a fairly mindless operation so it is difficult to see
how implementations would get this wrong.

Comments in content-type lines, on the other hand, are best avoided, as they
(Continue reading)

Charles Lindsey | 24 May 12:07 1999
Picon
Picon

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

In <3.0.32.19990523173115.01781800 <at> pop.dial.pipex.com> Graham Klyne <GK <at> dial.pipex.com> writes:

>At 10:43 21/05/99 GMT, Charles Lindsey wrote:

>>>>   Content-type: image/tiff; boundary=
>>>>     "longboundarystringwrappedtonextlinetolimitlinelength"
>>
>>>It is completely legal.
>>
>>Fine, but that still does not establish _exactly_ where folding may occur.

>I beg to differ, in this case, because RFC822 (cited directly by the MIME
>document) describes the lexical analysis of structured header fields:

>        These symbols are:

>                     -  individual special characters
>                     -  quoted-strings
>                     -  domain-literals
>                     -  comments
>                     -  atoms

>Thus, folding is permitted between any pair of symbols indicated above.

Ah yes! But is a <token> one of those symbols that count as a "lexical
token"? The syntax for <token> first appeared in RFC2045 (or its
predecessor) AIUI, so it was not mentioned in RFC 822, and RFC 2045 is
silent on the issue.

The particular split we are discussing is legal because the object in
(Continue reading)

Charles Lindsey | 24 May 11:59 1999
Picon
Picon

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

In <v04204d02b36b4173d020 <at> resnick2.qualcomm.com> Pete Resnick <presnick <at> qualcomm.com> writes:

>On 5/21/99 at 10:43 AM +0000, Charles Lindsey wrote:

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

OK. Point taken. If that was indeed the boundary in some multipart (do
image/tiffs have boundaries?), then the boundary actually written in the
(Continue reading)


Gmane