W3C home > Mailing lists > Public > public-html-media@w3.org > November 2013

Re: [EME] MediaKeyError codes proposal (bug 21798)

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 14 Nov 2013 11:23:02 +0800
Message-ID: <CAEnTvdBCxg07KMDuFqxCZ-r6V0b+c71S=HEYtmpokUpryAYSTA@mail.gmail.com>
To: Joe Steele <steele@adobe.com>
Cc: David Dorwin <ddorwin@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>
In the MediaKeyError object we have a systemCode field.


On Thu, Nov 14, 2013 at 10:52 AM, Joe Steele <steele@adobe.com> wrote:

> We don’t currently have a mechanism for reporting a low-level diagnostic
> code. But I would be in favor of that.
> Then the high level codes could be very limited as you suggest.
> Joe Steele
> steele@adobe.com
> On Nov 13, 2013, at 6:41 PM, Mark Watson <watsonm@netflix.com> wrote:
> I would suggest limiting the top-level errors to as few categories as
> possible based on how the application might be expected to respond, except
> for the specific case where there is some action we can reliably suggest to
> the user. So, we could have:
> - Permanant errors (no point in application retrying)
> -- Output protection (suggest to the user that they check their display
> connection, try a different display etc.)
> -- Other permanant failures (suggest the user contacts customer service,
> looks up the low-level status code in a knowledge base etc.)
> - Temporary failures (application might retry, with or without user
> notification)
> ...Mark
> On Thu, Nov 14, 2013 at 9:38 AM, Joe Steele <steele@adobe.com> wrote:
>> Replies inline —
>>  Joe Steele
>> steele@adobe.com
>> On Nov 12, 2013, at 11:56 PM, David Dorwin <ddorwin@google.com> wrote:
>> This e <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798>mail
>> provides a framework and suggestions for resolving Bug 21798<https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798>- Revisit MediaKeyError codes.
>> I think we should have the following goals:
>>    - Codes should be for things that would allow the application do one
>>    of the following:
>>    - Adapt/respond to enable playback to continue
>>       - Give the user a useful/actionable message.
>>       - Codes should be commonly useful across implementations.
>>    - Codes should generally be for things that are only known to the
>>    user agent/CDM. (In contrast, there are other ways to report errors known
>>    to the server.)
>>    - Codes should be described in sufficient detail that they can
>>    interpreted unambiguously by different implementers and it is clear how an
>>    application should respond.
>>    - Start with codes we know will be useful. We can always add them
>>    later based on implementation experience.
>> With that in mind, I’ve identified the following categories of errors I
>> think we must include. Some may make sense to split into separate codes,
>> and I’ve mentioned potential individual cases where applicable. I’ve also
>> included the expected application behavior for each, which I think is an
>> important consideration for any error code.
>>    1. Unknown/Other - “An unspecified error occurred. This value is used
>>    for errors that don't match any of the following codes.”
>>    1. Expected application behavior: General failure message. It is not
>>       possible to recover since there is no specified cause.
>> This would be useful although of course frustrating for the user.
>>     1. Output [protection]
>>    1. The current description is “There is no available output device
>>       with the required characteristics for the content protection system.” That
>>       seems like a subset or inaccurate description of cases that should be
>>       covered.
>>       2. Is it useful to differentiate the case where the error resulted
>>       from a display change (new display, player window moved, etc.)? (An
>>       application might be able to infer this based on the amount of time it has
>>       been playing without such a separation.)
>> I don’t think this would be particularly useful and would be difficult to
>> determine in some cases.
>>    1.
>>       2. Expected application behavior: Inform the user of the problem
>>       and/or try a different license, possibly using alternate streams. (The
>>       response may be different depending on whether the error resulted from a
>>       change.)
>>       1. Expired
>>    1. The key/license is no longer valid.
>>       2. This could be broken up into multiple scenarios:
>>       1. Renewal failed
>>          2. The time window has passed
>>          3. Number of plays exceeded
>>          4. Instructed to stop by license server
>> I am not sure how useful different i. and iv. are. Are you thinking in
>> one case the user could request a new license and in the other it could
>> not? (i.e. don’t bother)
>>    1. Expected application behavior: Inform the user there was a problem
>>       (renewing, rental expired, etc.).
>>       2. If we use a single error code, the application will need to
>>       derive the messaging based on knowledge of the application, licensing, etc.
>>       1. Key System/CDM cannot be used
>>    1. There are potentially several classes of causes that could
>>       potentiall be separate codes:
>>       1. Key System (CDM) is disabled (by the user)
>>          1. I can imagine this being useful as it allows applications to
>>             provide the user with specific instructions, but it also enables
>>             fingerprinting and exposes something about a user that is probably
>>             concerned about privacy.
>>             2. Identifiers are disabled (by the user)
>>          1. Similar issues to above.
>>             3. CDM could not be found, failed to load (i.e. due to
>>          dependencies), has not been initialized/enabled.
>>          1. Similar to or could be merged with to “Key System (CDM) is
>>             disabled”, though the desired messaging for each scenario would be very
>>             different.
>>             2. Expected application behavior: Inform the user that there
>>       is a problem and possibly general text about how to address it.
>>        1. For the latter, it may be useful to at least differentiate
>>          user controllable/resolvable issues vs. more complex issues (i.e. CDM
>>          failed to load).
>>          3. If we want to use a single code, we might just use “client”
>>       (where client refers to the CDM). Maybe there is an even better name.
>> I think the following would also be useful:
>>    1. Platform capabilities not available
>>    1. Similar to Output [Protection], but this device can never meet the
>>       license requirements.
>>       2. Expected application behavior: Try a different license,
>>       possibly using alternate streams.
>>       2. Initialization failure (needs a better name)
>>    1. Some implementations have various individualization, etc. steps.
>>       2. Expected application behavior: Inform the user, possibly
>>       telling them to try again or contact the device manufacturer.
>> I agree both of these would be useful.
>> Another possibility - this really depends on how we want to handle such
>> delays.
>>    1. Deferred/Delayed (more of a status than an error)
>>    1. This mostly relates to initial use [on an origin], which may take
>>       longer in some implementations.
>>       2. The code is an indication that the operation is not possible
>>       now but should be soon. As a status, it just means the operation (likely
>>       createSession()) is pending. Alternatively, the error could be fatal and
>>       the application should try again (calling createSession() again).
>>       3. Expected application behavior: This is mostly a hint that the
>>       application should not time out in cases where message or ready events may
>>       not be fired soon.
>> The following codes are currently in the spec but not included above. If
>> someone would like to make an argument for one of these, please consider
>> the goals above and the “expected application behavior”.
>>    - Client - “The Key System could not be installed or updated.”
>>    - Since CDMs should not be installed, the first part of the error
>>       definition is obsolete. It’s unclear what would cause a “not updated” error.
>> I disagree that CDMs should not be installed. I think a better way to put
>> it is that the UA may not support installing CDMs. Some UAs may support
>> this. “Not updated” in this context means that the CDM was installed, and
>> when an update was attempted because of a newer version of the CDM, that
>> update failed. Since CDMs may be updated in response to DRM breaches, and
>> we cannot assume that the core UA will be updated along with it.
>>    - We could reuse “client” for the “Key System/CDM cannot be used”
>>       class above.
>>    - Service - “The message passed into update indicated an error from
>>    the license service.”
>>    - What would be reported here that a) couldn’t be reported directly
>>       to the app and b) isn’t in the list above?
>> Since there is no EME defined way for a key server to indicate an error
>> to the application (other than regular HTTP errors) I am not sure what you
>> mean by reporting to the app. Having said that, I think the list of errors
>> you have provided is pretty comprehensive.
>>    - Hardware Change - “A hardware configuration change caused a content
>>    protection error.”
>>    - What would cause this to be fired? Are there cases other than the
>>       Output error? Would this be detected on the client or server? Is this
>>       common enough to warrant its own code?
>>       - Domain - “An error occurred in a multi-device domain licensing
>>    configuration. The most common error is a failure to join the domain.”
>>    - It seems to be TBD how “domain keys” would be supported. If this is
>>       handled at the application level, do we need a specific domain error? Or is
>>       this something different?
>> I think domain failures can be handled at the application layer, but I am
>> not opposed to this error. I would use it if available to report these
>> failures from the CDM.
Received on Thursday, 14 November 2013 03:23:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:42 UTC