Subject: Re: media type?

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 2 Dec 2003 16:37:00 -0500

There is ample precedent for confusion here.  Most applications that 
want to make use of MIME media types will want at least form #2, but 
naive implementors may stop at type/subtype and ignore parameters.  In 
particular, I think JSR 168 (the portal/portlet specification) is going 
to have to be amended to clarify this very point, as there are 
apparently implementations that won't support parameters in the media 
type.  -- Nathaniel

On Thursday, November 27, 2003, at 11:36  PM, Jeroen Bekaert wrote:

> Dear Valdis,
>
>
> Thanks for your reply! If I understand this correctly, defining Y as:
>
> 1. "a MIME media type value indicating the type of a resource" results 
> in:
> "text"
>
> 2. "a concatenation of MIME media-type, subtype and parameters 
> indicating
> the type of a resource" results in: "text/xml; charset=utf-8"
>
> 3. "a MIME content-type value indicating the type of a resource" 
> results in:
> "Content-Type: text/xml; charset=utf-8"
>
>
> Regards
> Jeroen Bekaert
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Thursday, November 27, 2003 8:34 PM
>> To: Jeroen Bekaert
>> Cc: [email-masked]
>> Subject: Re: media type?
>>
>> On Thu, 27 Nov 2003 18:32:50 MST, Jeroen Bekaert
>> <[email-masked]>  said:
>>
>>> As such, a possible value of Y could be "text/xml; charset=utf-8"?
>>
>>> As such, a possible value of Y could be: "text"
>>
>> You want media-type to be "text" with a  subtype of "xml" and
>> a parameter "charset=utf-8".
>>
>> I don't see any way to use the BNF of RFC2046, section 5.1 to get any
>> other parse.  In fact, further down in section 5, it says:
>>
>>    type of data.  Thus, a media type of "image/xyz" is enough to tell
>> a
>>    user agent that the data is an image, even if the user agent has
>> no
>>    knowledge of the specific image format "xyz".  Such information
>> can
>>    be used, for example, to decide whether or not to show a user the
>> raw
>>    data from an unrecognized subtype -- such an action might be
>>    reasonable for unrecognized subtypes of text, but not for
>>    unrecognized subtypes of image or audio.  For this reason,
>> registered
>>
>> So the intent is to have the media-type say "this is text" or "this
>> is an
>> image" or "this is a sound" or "this is a composite", and so on, so
>> that an MUA
>> can make a vague guess as to what do with it even if it has no clue
>> at all what
>> to do with the specific subtype or parameters. For instance, an MUA
>> would be
>> within it's rights to refused to deal with *any* flavor of text/*
>> (including
>> even text/plain) if it included a 'charset=' parameter it didn't know
>> how to
>> deal with.  As an example, displaying *any* sort of Big5 text on a
>> display that
>> is ascii/8859-* only is basically doomed...
>>
>
>
>
>
>
>