- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 27 Oct 2011 09:38:26 -0700
- To: Clarke Stevens <C.Stevens@CableLabs.com>
- CC: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Clarke, Unfortunately I did't have the slides in front of me during the call and now I look I have a few comments: On slide 5 (R8): 1) The requirement for better error reporting is not restricted to adaptive streams - various kinds of network errors (DNS, IP, TCP, TLS) can happen with any kind of media playback 2) I don't see the connection with ISSUE-179 - additional errors and statistics should be generic and defined in HTML, not through any kind of param mechanism I'd suggest changing the title to "Additional Media Errors", removing the reference to ISSUE-179 and adding some examples, such as Errors: DNS failures, TCP failures, TLS failures Events: change in rendered stream (for adaptive bit rate) On slide 6 & 7 (R10, R11): 1) Again I don't see the connection with ISSUE-179. What we need is a way defined in HTML that provides specific capabilities for communicating with the DRM agent, not just a general-purpose extensibility mechanism. When did we agree that the param mechanism was the desired solution to content protection in HTML5 ? I'd suggest removing the reference to the ISSUE and bug from this slide. On Slide 7 (R11): For our part (Netflix) we think authorization in the HTML video context should be handled by the service, not the DRM agent: we want to implement our business logic once in a way that is independent of the DRM. So this would mean the examples given are not needed. The kind of error you get would be at the level of a key exchange failure. I think the examples will be a red flag to some. On Slide 8: Please remove the ticks under ISSUE-179 from R8, R9, R11 and the tick under Bug-13625 for R10. On Slide 9, I think you'll get a very negative response to the first bullet. I don't think people see it as their job to provide technical solutions to other people's requirements. If we say "accept our proposals or propose a different solution" I expect the response to be "No, we're rejecting your proposals for x, y, z reasons, please come back with better ones". A better request would be "Assistance from HTML group in developing solutions to these requirements in HTML". ...Mark On Oct 27, 2011, at 7:38 AM, Clarke Stevens wrote: > Here's the slide deck I plan to present at TPAC. We'll review this today. > > -Clarke > > > > On 10/26/11 5:08 PM, "Clarke Stevens" <C.Stevens@CableLabs.com> wrote: > >> Here's the proposed agenda for the MPTF meeting: >> >> http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_27th_October_2011 >> >> Here's the meeting information: >> >> http://www.w3.org/2011/webtv/wiki/MPTF/Telco >> >> >> Thanks, >> -Clarke >> >> > > <W3C MPTF Requirements-v8.ppt>
Received on Thursday, 27 October 2011 16:39:05 UTC