headers
John C Klensin | 17 May 2012 01:15

SimpleDowngrade and excising MIME parameters

The things one notices when trying to go through the documents
looking for things that Monday's strategy requires adjusting...

Section 2.2 says:
	"Any MIME parameter [RFC2045] (whether in the message
	header or a bodypart header) which cannot be presented
	as-is to the client is silently excised."

I can't remember examples offhand (others might do better) but
there is nothing in RFC 2045 that prevents a content [media]
type (or header field that uses parameters) from having
parameters whose meaning is interdependent.  In part because of
that, one really can't start dropping parameters (silently or
not) without risking silly states unless the media type or
header field type is understood.  

I believe that you should add to this section (and/or the
Security Considerations one) a note that indicates that
parameter-dropping might turn the associated field into nonsense
or, perhaps even worse, reverse its meaning.

     john
Permalink | Reply |
headers
ned+ima | 17 May 2012 02:41

Re: SimpleDowngrade and excising MIME parameters

> The things one notices when trying to go through the documents
> looking for things that Monday's strategy requires adjusting...

> Section 2.2 says:
> 	"Any MIME parameter [RFC2045] (whether in the message
> 	header or a bodypart header) which cannot be presented
> 	as-is to the client is silently excised."

> I can't remember examples offhand (others might do better) but
> there is nothing in RFC 2045 that prevents a content [media]
> type (or header field that uses parameters) from having
> parameters whose meaning is interdependent.

Not only is is allowed, I believe it's been donee. For example, there are audio
and video formats with multiple parameters specifying encoder settings, and I
think there's one where a couple specify values and another specify the units
for those values.

OTOH, such parameters are unlikely to contain EAI material.

> In part because of
> that, one really can't start dropping parameters (silently or
> not) without risking silly states unless the media type or
> header field type is understood.

In practice the far bigger risk is that of broken behavior from EAI filename
parameters and clients that depend on those parameters for type identification.

Given that we specify that utf-8 in in the subject field should be turned
into encoded-words, and that RFC 2231 encoding is not significantly harder
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 17 May 2012 04:26

Re: SimpleDowngrade and excising MIME parameters


--On Wednesday, May 16, 2012 17:41 -0700 Ned Freed
<ned.freed <at> mrochek.com> wrote:

>> The things one notices when trying to go through the documents
>> looking for things that Monday's strategy requires
>> adjusting...
> 
>> Section 2.2 says:
>> 	"Any MIME parameter [RFC2045] (whether in the message
>> 	header or a bodypart header) which cannot be presented
>> 	as-is to the client is silently excised."
> 
>> I can't remember examples offhand (others might do better) but
>> there is nothing in RFC 2045 that prevents a content [media]
>> type (or header field that uses parameters) from having
>> parameters whose meaning is interdependent.
> 
> Not only is is allowed, I believe it's been donee. For
> example, there are audio and video formats with multiple
> parameters specifying encoder settings, and I think there's
> one where a couple specify values and another specify the units
> for those values.
> 
> OTOH, such parameters are unlikely to contain EAI material.

Yes, but my lack of conviction that it was an actual, rather
than theoretical/potential problem was related precisely to the
question of whether such parameters were likely to end up with
non-ASCII values.  The examples I could think of or make up in
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 17 May 2012 08:40
Picon
Favicon
Gravatar

Re: SimpleDowngrade and excising MIME parameters

John answers Ned:
>> > Given that we specify that utf-8 in in the subject field
>> > should be turned into encoded-words, and that RFC 2231
>> > encoding is not significantly harder to do than that, I have a
>> > really hard time not understanding why that option wasn't
>> > chosen. 
> Arnt can defend his own design choices

That's the one I feel least sure of.

The state of 2231 parsing in clients isn't too good, at least it wasn't
when I last needed to look at it. I feel that asking servers to learn
how to generate 2231 when clients aren't that good at parsing is a bit
too much of a detour.

But it's close.

I wouldn't mind saying this in the document — should I do that?

Arnt
Permalink | Reply |
headers
Arnt Gulbrandsen | 17 May 2012 09:26
Picon
Favicon
Gravatar

Re: SimpleDowngrade and excising MIME parameters

On 05/17/2012 01:15 AM, John C Klensin wrote:
> I believe that you should add to this section (and/or the
> Security Considerations one) a note that indicates that
> parameter-dropping might turn the associated field into nonsense
> or, perhaps even worse, reverse its meaning.

The same applies to header fields.

The only example I've been able to find was more semantic than
syntactic: File sets. "See appended files", before.jpg and after.jpg.

I'll try to wordsmith something suitable.

Arnt
Permalink | Reply |

Gmane