Bug 16540 - Provide guidelines on Key System string format
Summary: Provide guidelines on Key System string format
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 16611 20798
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-27 17:58 UTC by David Dorwin
Modified: 2013-07-02 14:54 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 2012-03-27 17:58:12 UTC
From v0.1:
It may make sense to provide informal guidelines to avoid these diverging too much. There are probably best practices too. Should platform-specific or protection capability information be contained in these strings?
Comment 1 Martin Soukup 2012-06-12 13:31:06 UTC
May be related to 16611
Comment 2 Adrian Bateman [MSFT] 2012-08-28 20:44:35 UTC
We should clarify the relationship between parent and subsystem strings (using a dot to separate, etc.) and remove mention of capability detection (bug 16611).
Comment 3 Joe Steele 2012-09-04 16:18:12 UTC
I would like to see specifics on how either capability detection is done, or how it should be added to Key System format. I am most interested in selective output control features and robustness levels, for example com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.
Comment 4 David Dorwin 2012-09-05 13:53:55 UTC
(In reply to comment #3)
> I would like to see specifics on how either capability detection is done, or
> how it should be added to Key System format. I am most interested in selective
> output control features and robustness levels, for example
> com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.

This was covered by bug 16611. The last update was:
"We propose not overloading key system strings with capability detection. We should consider if we need a separate capability detection system."
Comment 5 Joe Steele 2012-09-05 16:04:23 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I would like to see specifics on how either capability detection is done, or
> > how it should be added to Key System format. I am most interested in selective
> > output control features and robustness levels, for example
> > com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.
> 
> This was covered by bug 16611. The last update was:
> "We propose not overloading key system strings with capability detection. We
> should consider if we need a separate capability detection system."

I should be more clear. Let's start considering it ASAP.  Those are the capabilities I am currently interested in, although the list might be extended in the future. I am not clear why adding it to the Key System format would not work. I have not been able to glean it from the minutes so far.
Comment 6 David Dorwin 2013-03-07 20:27:05 UTC
Issue 20798 relates to case sensitivity of the string.
Comment 7 David Dorwin 2013-03-26 00:02:15 UTC
What needs to be done here? Adrian suggests some concrete changes in Comment 2. The rest of the discussion seems to focus on capability detection, which should be covered in another bug - possibly bug 16611.
Comment 8 Adrian Bateman [MSFT] 2013-04-24 22:59:53 UTC
We discussed this in the F2F: I believe that the consensus was that we didn't need to complexity of the prefix matching for keysystem strings. Implementers can use whichever reverse-domain strings they want.

We should monitor what capability detection sites want and try to resolve those as they arise.

My proposal is to remove the references to com.example.somesystem.1_5.
Comment 9 David Dorwin 2013-05-09 03:36:11 UTC
It was also pointed out at the F2F that if version detection was supported in some way, "supports minimum version" might be the more helpful thing to check instead of exact version matching.

I agree that the use cases are probably better served with some type of feature detection and support removing references to versions in key systems [1].

I think there might still be use cases for some type of structure. For example, some key systems may choose to expose parent systems, such as "com.example", via isTypeSupported(). For those key systems that do, I think UAs should also expose them, though we don't need to specify exact variations in the spec.

The current draft does not actually say much about prefix matching or subsystems (v0.1b said a bit more). After deleting the version references, it might be good to provide a non-normative note that there may be such variations and that UAs should pass through variations for key systems that support it.

[1] Key System definition, isTypeSupported() examples, Selecting a Supported Key System example
Comment 10 Adrian Bateman [MSFT] 2013-07-02 14:54:50 UTC
Changeset -> https://dvcs.w3.org/hg/html-media/rev/da1d34e19d4f