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 general, key system [1] strings will commonly be described using lower-case (following the reverse domain name convention). We propose that any matching against key system should be done case sensitively to avoid having to define interoperable case-handling rules and to simplify coding. This will usually mean simply always specifying strings in lower case. This will be important for the isTypeSupported method [2] and the keystem source attribute [3]. [1] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-system [2] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-istypesupported [3] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-sourcekeysystem
Some initial thoughts: * Is |type| case sensitive? I think it makes sense to match this behavior. * Are other (common) reverse domain name conventions case sensitive? People might expect similar behavior. * Domain names are not case sensitive. Can you explain your concerns about interoperable case-handling rules? Is this related to IDNs?
It's just to keep things simple. Currently the spec doesn't define how to do this matching. If we don't pick case sensitively then we have to explicitly define how to do it and which parts to apply that to.
As we discussed on the call, the key system string is simply a Unicode string. While it is typically expected to be a reverse domain name it could contain any characters. If we choose to match case insensitively then we must pick and define the algorithm for this. My proposal for case sensitivity is just because it is the simplest option. I'm not against specifying something else provided that it is well-defined.
https://bugzilla.mozilla.org/show_bug.cgi?id=800600 notes that the spec doesn't say whether canPlayType() is case-sensitive and that browsers differ in case-sensitivity. Presumably, browsers would use the same behavior for the |type| parameter of isTypeSupported(). For those that allow case-insensitive |type|, it might be odd that the other parameter (|keySystem|) does not. However, for simplicity and because we have the opportunity to establish consistent behavior, I think it's fine to do an exact string match, which is also consisten with the direction of bug 16540. We can always change to case insensitive later but never the other way. I think we should include an informative note that these should be lowercase strings. If all applications are implementations use lowercase (whatever that means for a given character), we should not have interoperability issues.
I agree that this would make things easier. Do you have some sample text?
Changeset -> https://dvcs.w3.org/hg/html-media/rev/7fba91203de5