This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In bug 20798, we made all keySystem string comparisons case-sensitive. I believe we should do the same for all content type checks for the same reasons and to be consistent with the keySystem checks. Defining this now will also avoid inconsistencies and incompatibilities as has happened for canPlayType() - see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20798#c4.
Regardless of the decision on the above suggestion, we should recommended that applications use simple lower-case ASCII strings when possible. Even if we can't force case-sensitive comparisons on implementations, this should be the most interoperable option.
I don't think we should make the content type comparisons case-sensitive. I wouldn't want to have to fail playback simply because someone mis-typed "Video/mp4" in their code. RFC6838 defines that top-level type and subtype are case-insensitive and I think we should follow this. See http://tools.ietf.org/html/rfc6838#section-4.2 (In reply to David Dorwin from comment #1) > Regardless of the decision on the above suggestion, we should recommended > that applications use simple lower-case ASCII strings when possible. Even if > we can't force case-sensitive comparisons on implementations, this should be > the most interoperable option. I am fine with suggesting a non-normative best practice to always use lower-case ASCII strings if possible.
FYI, WebKit's and Blink's implementation of canPlayType() is: * container is case-insensitive * codecs are case-sensitive "because MP4 values are case sensitive per http://tools.ietf.org/html/rfc4281#page-7." (The reference should be updated to http://tools.ietf.org/html/rfc6381#section-3.3.) (In reply to Adrian Bateman [MSFT] from comment #2) > I don't think we should make the content type comparisons case-sensitive. I > wouldn't want to have to fail playback simply because someone mis-typed > "Video/mp4" in their code. If browsers are consistent from the beginning, it will fail in all of them and they can detect and fix the problem immediately. Note that since (MP4) codecs are case-sensitive, mis-typing "Avc1" would similarly cause the app to fail. However, the RFC below is clear. > RFC6838 defines that top-level type and subtype are case-insensitive and I > think we should follow this. > See http://tools.ietf.org/html/rfc6838#section-4.2 > > (In reply to David Dorwin from comment #1) > > Regardless of the decision on the above suggestion, we should recommended > > that applications use simple lower-case ASCII strings when possible. Even if > > we can't force case-sensitive comparisons on implementations, this should be > > the most interoperable option. > > I am fine with suggesting a non-normative best practice to always use > lower-case ASCII strings if possible. On second thought, this would actually be inconsistent with RFC 4281/6381 (since http://www.mp4ra.org/codecs.html contains some capitalized codes). Maybe we should just note, possibly non-normatively, that comparisons are based on the respective definitions along with the comment that this means the type and subtype is case-insensitive and codecs are (may be) case-sensitive.
Updated the summary to reflect the current proposal. This was discussed in the telecon this morning, and there were no objections to implementing the last paragraph of comment #3.
We will implement this after addressing bug 24951, since that may eliminate some content type checks.
At least some cases of "contentType" have been replaced with "initDataType" and there is a note that "Initialization data type strings are always matched case-sensitively." We should also add a sentence that "string comparison is case-sensitive" to all algorithms that check of initDataType like we have for key system in the MediaKeys constructor. There is still one use of content type in isTypeSupported, which may still change (bug 24873).
isTypeSupported()'s |contentType| string parameter is addressed per comment #3 in https://dvcs.w3.org/hg/html-media/rev/15c3513a59e4 Other related string checks were addressed in https://dvcs.w3.org/hg/html-media/rev/5af732159d2e.