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

On Feb 21, 2012, at 5:51 PM, Glenn Adams wrote:


On Tue, Feb 21, 2012 at 6:35 PM, Adrian Bateman <adrianba@microsoft.com<mailto: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>.

As has been pointed out in the earlier discussion on ISSUE 179, this not not correct. <object> embeds *arbitrary* functionality into a page. This functionality is constrained only by browser plugin APIs and so can literally be almost anything. Hence it makes sense to enable the passing of arbitrary parameters.

<video> and <audio>, by contrast, provide the very specific functions of media playback. If they were "flavours" of <object> they would provide for embedding of arbitrary media playback plugins. They do not. They provide access to specific native User Agent media playback functions. It makes sense in this context to provide specific methods related to this functionality. Our proposal introduces specific methods for accessing content protection functionality - one of the use-cases that was proposed for <param>.

...Mark


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.