16540 2012-03-27 17:58:12 +0000 Provide guidelines on Key System string format 2013-07-02 14:54:50 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED FIXED P3 normal --- 16611 20798 1 ddorwin ddorwin adrianba ddorwin hsivonen martin.soukup mike philipj public-html-media public-html-wg-issue-tracking steele public-html-bugzilla oldest_to_newest 66131 0 ddorwin 2012-03-27 17:58:12 +0000 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? 68979 1 martin.soukup 2012-06-12 13:31:06 +0000 May be related to 16611 72917 2 adrianba 2012-08-28 20:44:35 +0000 We should clarify the relationship between parent and subsystem strings (using a dot to separate, etc.) and remove mention of capability detection (bug 16611). 73184 3 steele 2012-09-04 16:18:12 +0000 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. 73227 4 ddorwin 2012-09-05 13:53:55 +0000 (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." 73237 5 steele 2012-09-05 16:04:23 +0000 (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. 84083 6 ddorwin 2013-03-07 20:27:05 +0000 Issue 20798 relates to case sensitivity of the string. 84981 7 ddorwin 2013-03-26 00:02:15 +0000 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. 86748 8 adrianba 2013-04-24 22:59:53 +0000 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. 87477 9 ddorwin 2013-05-09 03:36:11 +0000 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 90112 10 adrianba 2013-07-02 14:54:50 +0000 Changeset -> https://dvcs.w3.org/hg/html-media/rev/da1d34e19d4f