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