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

Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Smylers <Smylers@stripey.com>
Date: Wed, 29 Feb 2012 13:09:44 +0000
To: public-html@w3.org
Message-ID: <20120229130944.GF27198@stripey.com>
Glenn Adams writes:

> On Wed, Feb 29, 2012 at 1:20 AM, Smylers <Smylers@stripey.com> wrote:
> > Glenn Adams writes:
> >
> > > SmartTVs do not try to support browsing the web at large. Rather,
> > > they support specific walled garden content that has been
> > > specifically tested against the device.
> >
> > In that case, why is what they do relevant to this working group?
> >
> > If they define their own behaviour, not HTML as a whole, and only
> > need to work with walled gardens then why should their requirements
> > have an affect on the WWW?
> (1) I am describing current behavior above for TV devices,

OK. Thanks for your reply.

> however, there is a desire to support full HTML5 behavior to the
> extent that is possible on such devices;

Does that desire include displaying web pages served over HTTP, or
merely re-using HTML as an internal format for walled garden content?

> (2) a common solution for commercial video services must satisfy
> delivery of such services to multiple classes of devices, desktop,
> televisions, set-top boxes, handheld phones etc

I can see why providers of commercial video services would find a common
solution for all of those to be convenient.

And I can see why it's important for the web that when video is served
over the web it's done in a way where it can be watched on all those
sorts of devices.

But what I'm not sure about is why it's good for the web for the
mechanism for serving video over the web to also have to be capable of
being used for serving video in other circumstances, such as walled
garden content delivered directly to devices.

In particular, it seems hard enough to get this to work on the web.
Trying to make it also work elsewhere puts additional constraints and
requirements on the design, which may result in a design that is less
good in some way than if only the web's requirements had been taken into

> (3) these issues are relevant to this WG because these service
> providers and their end users are both customers and members of this
> WG;

As a user of a device which provides walled garden content I don't care
in the slightest if it does so by internally re-using a web spec or by a
bespoke mechanism of its provider's own devising; it's a black box, so
surely I wouldn't even be able to tell the difference?

Could we at least focus on web (delivered over the internet)
requirements first, and try to come up with something which works well
for those?

Then we could look at what additional requirements others have, and
whether it'd be possible to also meet those without causing significant
detriment to the web requirements.


Received on Wednesday, 29 February 2012 13:10:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC