W3C home > Mailing lists > Public > public-html@w3.org > January 2011

Change Proposal for ISSUE-145, was: ISSUE-145 (codecs-vs-octet): Chairs Solicit Proposals

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 22 Jan 2011 18:02:10 +0100
Message-ID: <4D3B0D92.4030604@gmx.de>
To: Paul Cotton <Paul.Cotton@microsoft.com>
CC: "public-html@w3.org" <public-html@w3.org>
SUMMARY

In the description of Internet Media Types for video playback [1], the 
spec shows the "codecs" parameter in use with 
"application/octet-stream". This is confusing because that parameter 
isn't defined on this media type.

RATIONALE

The spec tries to special-case "application/octet-stream" as a type that 
allows sniffing (whether that's a good idea is a separate question), and 
then use the "codecs" parameter with "application/octet-stream" to 
illustrate when sniffing is not allowed.

This is confusing, as "codecs" isn't defined on this type. The confusion 
could be avoided by rephrasing the note.

DETAILS

In [1], replace

'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, since that parameter is not defined for that type.'

by (first paragraph only shown for context):

'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: "application/octet-stream" is special-cased here; if any parameter 
appears with it, it should be treated just like any other MIME type. 
This is a deviation from the rule that unknown MIME type parameters 
should be ignored."

IMPACT

1. Positive Effects

Avoids confusion about "codecs" on application/octet-stream, and the 
general that recipients should ignore unknown parameters.

2. Negative Effects

None.

3. Conformance Classes Changes

None.

4. Risks

None.


REFERENCES

[1] <http://dev.w3.org/html5/spec/Overview.html#mime-types>
Received on Saturday, 22 January 2011 17:15:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:19 GMT