This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20798 - keySystem strings should be compared case-sensitively
Summary: keySystem strings should be compared case-sensitively
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
Depends on:
Blocks: 16540 24673
  Show dependency treegraph
Reported: 2013-01-29 05:03 UTC by Adrian Bateman [MSFT]
Modified: 2014-02-15 01:12 UTC (History)
4 users (show)

See Also:


Description Adrian Bateman [MSFT] 2013-01-29 05:03:01 UTC
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].

Comment 1 David Dorwin 2013-01-29 05:22:19 UTC
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?
Comment 2 Adrian Bateman [MSFT] 2013-01-29 05:28:57 UTC
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.
Comment 3 Adrian Bateman [MSFT] 2013-02-12 14:01:53 UTC
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.
Comment 4 David Dorwin 2013-05-08 20:34:57 UTC 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.
Comment 5 Joe Steele 2013-05-20 05:31:33 UTC
I agree that this would make things easier. Do you have some sample text?
Comment 6 Adrian Bateman [MSFT] 2013-07-02 14:45:52 UTC
Changeset ->