W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2012

[Bug 17658] need procedure for selection of Key System

From: <bugzilla@jessica.w3.org>
Date: Wed, 04 Jul 2012 05:15:56 +0000
Message-Id: <E1SmHwS-0002CU-AF@jessica.w3.org>
To: public-html-bugzilla@w3.org

--- Comment #2 from Yang Sun <eric.sun@huawei.com> 2012-07-04 05:15:56 UTC ---
Thanks for your reply.

I guess you misunderstand my question.
My question is when encrypted block is detected by media element during
resource fetch algorithm , 
how to choose the key system.

>From specification,

In step 6 of section 5.1 encrypted block encounted
It is said if the media element has a selected key system, then use it,
If not, jump to key presence, there is no key system selection text  in step 9
Key Presence.
Step 9 only mentioned 3 choices: 1 key is available, 2 fire needKey event with
“keySystem”,3 abort resource fetch procedure

What’s more, I think before the generateKeyRequest(KeySystem, initData) is
called, the KeySystem is already
Selected, and the specification mentioned if KeySystem is null, it will throw a

(In reply to comment #1)
> The key system is selected with the call to generateKeyRequest(). If that
> keysystem is not supported (by the browser, or by the file) then the call will
> fail and the app can try a different keysystem.
> Note that all three of the app, the file and the browser may support multiple
> keysystems. Only a keysystem in the intersection of these three sets may be
> used. There may still be more than one. The app needs to choose its favorite
> from that set, as there may be commercial implications of the choice for the
> app.
> The way we chose to implement that was by allowing the app to attempt
> generateKeyRequest with different key systems, in preference order, until one
> succeeded.
> That seems acceptable given that the set of keysystems in the intersection I
> describe above is likely to be very small (coming up with an example where
> there are 3, say, is already a challenge).

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 4 July 2012 05:15:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:30 UTC