- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sat, 21 Apr 2012 17:56:07 +0200
- To: "Aaron Colwell" <acolwell@google.com>, "public-html@w3.org" <public-html@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>
- Cc: "Mark Watson" <watsonm@netflix.com>
On Thu, 19 Apr 2012 17:46:24 +0200, Adrian Bateman <adrianba@microsoft.com> wrote: > On Thursday, April 19, 2012 7:54 AM, Aaron Colwell wrote: >> On Thu, Apr 19, 2012 at 1:36 AM, Philip Jägenstedt <philipj@opera.com> >> wrote: >> > I agree, adaptive streaming does not need to be tied to "content > >> protection" and creating a task force covering both seems like a bad >> > idea. They are both related to HTMLMediaElement, but so are a lot of >> > other features that would presumably not be included. Opera is >> > interested in adaptive streaming and would not like to see it mixed >> > up with the more controversial issues. >> >> I agree that the Media Source & Encrypted Media proposals should not be >> unnecessarily tied together. We have intentionally kept them separate >> because we, at Google, believe that some constituencies interested in >> one proposal may not want to participate in developing the other. They are also pretty separate things (modulo the fact that more or less everything has some relationship to everything else, and probably some interoperability dependency). >> We also recognize that there are people interested in supporting both >> proposals and ensuring that they properly interoperate with each other. I would be surprised if anyone was not trying to ensure they interoperate, unless because they are actively trying to sabotage the work of one group by ensuring it doesn't mesh well with the other. >> We believe that considering these proposals in the same forum would >> make it easier for the two proposal development groups to coordinate >> interoperability efforts. In no way are we saying that development of >> one proposal should be gated by the other. > > I agree with Aaron. At Microsoft, we also think many of the same people > with important experience of media scenarios will have useful > contributions to both proposals. Certainly. > For this reason, we think considering the proposals in the same forum > makes it easier. There is already the TV/Web IG that permits this (and where these things are coming from). The point of having work done in the main HTML group is to ensure it gets the technical oversight of people who specialise in the web technology side of what we are trying to develop. Task forces impose a cost in working out of the mainstream. If they are set up around *people* rather than around *tasks* they run a greater risk of losing contact with the main stream of the HTML WG. The Encrypted Media work is clearly controversial (surprise) and equally clearly, is trying to meet the use cases of a real identifiable part of the web. It may make sense to have a task force (to reduce the discussion and the signal/noise ratios to a manageable level). But to add another marginally related task on the basis that it is the same people strikes me as a mistake. > It is also important that people who want to work on some things and not > others are able to do so. The Accessibility Task Force uses sub-teams to > help towards this goal. I'm sure there are other options. Sure. > The Task Force would identify this during its scoping and organising > phase and the proposed framing of the task force states that the Working > Group ultimately owns that decision. Right - that's all required a priori. > On Tuesday, April 17, 2012 10:56 PM, Vickers, Mark wrote: >> We believe the best initial work plan needs to be broad enough to >> include not only refining the current Encrypted Media proposal, but >> also investigate other alternative architectures. In particular, >> there have been several legitimate concerns raised about the >> Encrypted Media proposal. The Media Task Force should look at both >> (a) improving the submitted proposal and >> (b) inviting alternate proposals for handling encrypted media. > > We have made two proposals for media-related extension specifications. > They are just that. Proposals. We see support from a number of > organisations for progressing this work and we believe we've presented > a good starting point but of course anyone who wants to can and should > make alternate proposals. That's how we end up with the best solutions > in the end. I agree with Mark that the Task Force should be open to > alternate proposals. Quite. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Saturday, 21 April 2012 15:56:46 UTC