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
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)> 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)
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)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)
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)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, > 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)
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)
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)
RSS Feed1 | |
|---|---|
2 | |
7 | |
3 | |
15 | |
21 | |
12 | |
2 | |
1 | |
1 | |
4 | |
27 | |
2 | |
9 | |
2 | |
21 | |
7 | |
1 | |
1 | |
2 | |
8 | |
37 | |
10 | |
154 | |
1 | |
7 | |
4 | |
16 | |
17 | |
129 | |
26 | |
25 | |
16 | |
4 | |
21 | |
25 | |
50 | |
15 | |
3 | |
4 | |
2 | |
3 | |
2 | |
10 | |
4 | |
8 | |
13 | |
1 | |
2 | |
6 | |
6 | |
7 | |
49 | |
74 | |
123 | |
12 | |
99 | |
104 | |
85 | |
122 | |
118 | |
289 | |
329 | |
273 | |
62 | |
1 | |
16 | |
20 | |
13 | |
80 | |
201 | |
33 | |
40 | |
177 | |
56 | |
32 | |
2 | |
36 | |
16 | |
6 | |
61 | |
280 | |
427 | |
58 | |
56 | |
83 | |
26 | |
95 | |
11 | |
176 | |
235 | |
126 | |
69 | |
240 | |
24 | |
23 | |
31 | |
43 | |
48 | |
10 | |
1 | |
25 | |
114 | |
12 | |
3 | |
19 | |
41 | |
16 | |
15 | |
17 | |
8 | |
2 | |
8 | |
14 | |
15 | |
6 | |
137 | |
2 | |
16 | |
11 | |
22 | |
2 | |
11 | |
13 | |
93 | |
88 | |
50 | |
8 | |
29 | |
50 | |
65 | |
81 | |
3 | |
4 | |
4 | |
82 | |
39 | |
6 | |
75 | |
82 | |
12 | |
2 | |
1 | |
3 | |
1 | |
1 | |
3 | |
6 | |
33 | |
14 | |
8 | |
10 | |
2 | |
11 | |
29 | |
6 | |
21 | |
47 | |
14 | |
1 | |
17 | |
55 | |
46 | |
83 | |
36 | |
23 | |
109 | |
138 | |
187 | |
208 | |
210 | |
100 | |
55 | |
45 | |
23 | |
57 | |
2 | |
18 | |
10 | |
34 | |
52 | |
159 | |
112 | |
141 | |
86 | |
16 | |
104 | |
78 | |
126 | |
324 | |
205 | |
165 | |
96 | |
17 | |
16 | |
13 | |
34 | |
55 | |
57 | |
30 | |
94 | |
201 | |
212 | |
103 | |
186 | |
150 | |
384 | |
293 | |
98 | |
88 | |
136 | |
111 | |
209 |
