W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Video with MIME type application/octet-stream

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 31 Aug 2010 10:06:28 +0200
Message-ID: <4C7CB804.9010500@gmx.de>
On 31.08.2010 09:36, Ian Hickson wrote:
>> From<http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.1>:
>>
>> "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. Parameters may be required by their defining media type or
>> subtype or they may be optional. MIME implementations must also ignore
>> any parameters whose names they do not recognize."
>>
>> So, as "codecs" is not defined on application/octet-stream, the
>> parameter simply should be ignored, thus the advice [...]:
>>
>> "The MIME type "application/octet-stream" with no parameters is never a
>> type that the user agent knows it cannot render. User agents must treat
>> that type as equivalent to the lack of any explicit Content-Type
>> metadata when it is used to label a potential media resource.
>>
>> Note: In the absence of a specification to the contrary, the MIME type
>> "application/octet-stream" when used with parameters, e.g.
>> "application/octet-stream;codecs=theora", is a type that the user agent
>> knows it cannot render."
>>
>> is incorrect, because it requires handling "application/octet-stream"
>> and "application/octet-stream;codecs=theora" differently.
>
> That's not incorrect. The type with no parameters is a special case that
> corresponds to a common configuration default. The case with parameters is
> not that case, and represents likely intentional configuration and thus
> clearly not a video format the UA supports.

My point is that it's incorrect to make this distinction, and that it's 
furthermore misleading to mention the "codecs" parameter in the context 
of a type that doesn't define it.

>> It's also not clear whether the note applies to all parameters or just
>> "codecs".
>
> The normative text you quote doesn't mention any specific parameters.

In which case it would be a *bit* clearer if the note used a parameter 
that doesn't suggest that "codecs" has any meaning on a/o.

> Regarding codecs="" in particular, it's an implementation reality that
> user agents that support it are likely to support it regardless of the
> type, so there's really no point trying to maintain an artificial boundary
> of which types it has semantics for and which it doesn't.

David Singer pointed out in 
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202#c11> that this is 
the wrong thing to do.

Do you have any evidence that UAs already use "codecs" on types on which 
they aren't defined, *and*, if this is the case, they can't be changed 
anymore?

Best regards, Julian
Received on Tuesday, 31 August 2010 01:06:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC