Re: [VPIM] Critical Content -- Header or Parameter


ned.freed@mrochek.com
Wed, 14 Mar 2001 12:56:15 -0800 (PST)


Sorry, last reply got away from me before I realized you had quoted
the relevant section of the MIME RFC. Here's a more relevant reply.

> OK, here's another choice (thanks to Mark Crispin): How about making the
> critical content notation a parameter to Content-Type?

As you point out, MIME forbids this sort of thing.

> We rejected making critical content a parameter to Content-Disposition,
> since people felt that would bend the semantics of Content-Disposition a bit
> too much.

It bends the semantics of content-disposition a heck of a lot less than it
bends the semantics of content-type. A content-type is supposed to describe
what's in the content. It isn't an appropriate place to put meta-information
about how the content is to be handled, which is what a criticality indicator
is.

Indeed, content-disposition was created specifically to address this issue
for filenames, which again are meta-information that doesn't belong in the
content-type. If content-disposition isn't broad enough to accomodate
criticality perhaps the right thing to do is broaden it a bit.

> The argument for making critical content a parameter to Content-Type is that
> all IMAP servers return Content-Type parameters in the BODY/BODYSTRUCTURE
> methods. They would not have to implement a BODYSTRUCTURE extension to
> return Critical-Content.

> That is, instead of
> Content-Type: TEXT/PLAIN;CHARSET=US-ASCII
> Content-Criticality: IGNORE
> we would use something like
> Content-Type: TEXT/PLAIN;CHARSET=US-ASCII;CRITICALITY=IGNORE

> The argument against making critical content a parameter to Content-Type is
> that it goes directly against two paragraphs in RFC 2045:

> There are NO globally-meaningful parameters that apply to all media
> types. Truly global mechanisms are best addressed, in the MIME
> model, by the definition of additional Content-* header fields.

> a CRITICALITY parameter is a globally-meaningful parameter. A Content-Type
> parameter is supposed to be for modifiers to the Content-Type only:

> Parameters are modifiers of the media subtype, and as such do not
> fundamentally affect the nature of the content. The set of
> meaningful parameters depends on the media type and subtype. Most
> parameters are associated with a single specific subtype. However, a
> given top-level media type may define parameters which are applicable
> to any subtype of that type.

> Do we really care?

Yes, we really care. If there's an issue getting at this information in
IMAP that should be addressed in IMAP. It is wrong to simply cram it into
a field that IMAP happens to currently handle in a way that you like.

                                Ned



This archive was generated by hypermail 2.0b3 on Wed Mar 14 2001 - 23:03:04 IST