Eric Burger (eburger@snowshore.com)
Wed, 14 Mar 2001 11:31:47 -0500
OK, here's another choice (thanks to Mark Crispin): How about making the
critical content notation a parameter to Content-Type?
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.
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? I'd like to hear from IMAP server vendors.
Thoughts?
[If you're wondering what this is about, see
http://www.ietf.org/internet-drafts/draft-ietf-vpim-cc-03.txt ]
This archive was generated by hypermail 2.0b3 on Wed Mar 14 2001 - 18:32:17 IST