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

On Tue, Feb 21, 2012 at 6:35 PM, Adrian Bateman <adrianba@microsoft.com>wrote:

> On Tuesday, February 21, 2012 4:00 PM, Glenn Adams wrote:
> > This a lengthy proposal that is not directly related to the general
> issue of
> > interchanging decoding and/or protocol parameters between author and user
> > agent for the purpose of performing audio and/or video playback.
> >
> > Could you point out the specific elements of the proposal that deals with
> > such parameter interchange? If this proposal offers an alternative
> mechanism
> > to perform such interchange, then is that mechanism suitable for
> purposes not
> > related to encrypted media playback?
>
> Hi Glenn,
>
> Rather than introducing a mechanism that supports generic parameter
> exchange,
> this proposal shows how it is possible to write an extension specification
> to add specific functionality to the existing media elements. User Agents
> supporting this proposal would be interoperable if they implement the
> extension according to the spec.
>
> Having a generic mechanism doesn't guarantee interoperability because you
> still
> need to specify what happens for each potential value. I argue that you
> don't
> need <param> to do that, you just write the specification that defines
> the new capabilities you want the media element to support. You can do
> that with
> an extension at the time you define the values.
>

Of course that is true, but it is also besides the point. Furthermore, your
suggestion would lead to the idea that for every extension specification
ES(0) ... ES(n), one would define an independent mechanism for
interchanging parameters.

The point of having a generic mechanism is that it is useful in may
circumstances, in this case a general syntactic mechanism that has been
successfully implemented and used without requiring changes to the
originating spec (HTML4 in this case).

I continue to maintain that if there is such a generic parameter
interchange mechanism defined and included for <object>, then there should
be such a generic mechanism for <audio> and <video> which seek to define
specific flavors of <object>.

Linking ISSUE 179 to a proposal about handling encrypted content seems to
be a significant stretch.


>
> This specification doesn't provide a mechanism for values used outside
> encrypted media playback.


Exactly, and that's why your proposal does not address the use cases
covered by <param>.


> However, you could write an extension specification
> for whatever those other values you have in mind are whenever you come up
> with
> them so not having <param> in HTML5 isn't restricting that ability.
>

But writing an extension specification for every value or even groups of
values would require defining a new mechanism for interchanging (i.e.,
syntactically expressing) those values.

In the present CP, the proposal is only to maintain the existing syntactic
mechanism, and not to define or adopt any specific values for interchange.

Following your argument (and the zero change counter proposal) seems to be
like saying that HTML (or XHTML) shouldn't define the syntactic mechanism
known as an "attribute", but should instead defer the definition of such a
mechanism to each use where an attribute needs to be expressed.

G.