[Bug 13333] audio, video (and source) elements require param children or equivalent

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #35 from Glenn Adams <glenn@skynav.com> 2011-07-28 14:55:45 UTC ---
(In reply to comment #32)
> (In reply to comment #0)
> > <audio>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> >   </source>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo"
> > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> >   </source>
> > </audio>
> 
> Why isn't this written as 
> <audio>
>   <source src="rtsp://something/audio.mp3">
>   <source src="http://something/audio.mp3">
> </audio>
> ?

Because there are additional protocol parameters that are needed beyond simply
the scheme component of the URL.

The alternative is to standardize the encoding of additional protocol
parameters as part of the query component of the URL, but since such parameters
are intended to be used by the UA and not necessarily sent to the server, the
UA would have to:

* parse the URL to extract specific parameters targeted for use by the UA
* rewrite the URL's query part to remove the UA targeted parameters

This approach would introduce more complexity and risk than a separate <param>
approach. For example, one risk is that a UA targeted param appearing in the
query part would conflict with (i.e., use the same name as) a server targeted
query parameter.

> (In reply to comment #28)
> > (In reply to comment #26)
> > > (In reply to comment #24)
> > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > 
> > > What browsers are those?
> > 
> > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > and Mobile Devices, particularly those that participate in the playback and
> > sharing of DRM controlled video or audio content. There are a variety of
> > standards/specifications that apply to such devices, such as those defined by
> > DLNA and other industry associations.
> 
> I meant the names of the browsers.

Any browser that supports a silverlight or flash plugin which includes
Microsoft or Adobe defined or supported DRM schemes.

Any browser that supports the Open IPTV Forum (OIPF) content protection
architecture [1].

[1]
http://www.openiptvforum.org/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-7-Authentication-Content-Protection-and-Service-Protection-2_1-2011-09-21.pdf

etc.

I work with a large Consumer Electronics company that happens to support the
above in various device browsers. I'm not in a position to enumerate actual
products or other companies' products, but they are out there in the field. I
admit these are real world needs that exist beyond the simple, non-content
protected scenarios that exist in many Web interactions; however, that does not
make these needs less relevant.

> Why does your DRM scheme require parameters to be supplied alongside the
> DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> as a special kind of file format? Like this:
> <audio>
>   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> </audio>

Firstly, I am not advocating any specific DRM scheme. I am not even advocating
DRM.

I only used DRM as one example of the need to allow authors to specify
arbitrary parameters to be interpreted by a DRM component in a UA component or
plugin.

As to your alternative above, media types and DRM are entirely orthogonal
functions, and implementations of these features tend to remain orthogonal as
well. Combining the two into a single artificial media type is not a realistic
approach, if for no other reason, because of the combinatorics involved.
Further it would be architecturally unsound.

> Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> multiple vendors can implement clients without asking permission from a DRM
> proprietor.

Now you are descending into a discussion about the merits or appropriateness of
DRM. This is entirely outside the scope of this thread.

Adding <param> as a child of video/audio or source in no way impacts the goals
of the W3C to define RF technology solutions. And this still holds if the use
of <param> happens to be to communicate DRM information.

> While it's possible to reuse Web specs in closed systems, I think
> we shouldn't design HTML5 for closed systems, since that's a distraction that
> takes attention and focus away from making the Web better. That is, I think we
> shouldn't spend time adding closed system-motivated features.

Actually, by not supporting <param>, you are effectively advocating a closed
system, where the currently defined video/audio attributes define the limit of
that system. In the case of object, and as video/audio is currently supported
in the field via object, the system (of parameter configuration data) is open.
It should remain so for video/audio elements as well.

In any case, where would I18N and A11Y be if generic solutions weren't sought
to these problems. One can't argue that DRM support is not relevant while
simultaneously advocating for I18N or A11Y support. Or at least one can't do so
without hypocrisy.

> More concretely, I don't want to disrupt the parsing of <source> (a void
> element--for better or worse--in shipped Web browsers) in order to cater to
> closed-system use cases.

param is already parsed in object; no shipped browser supports all of HTML5 and
related specs; browsers are currently being modified to implement many HTML5
features; this comment about 'disruption' is entirely irrelevant at this stage
of deployment

I may add that HTML5 is just in its first LC, with a strong probability that
more LCs will occur BEFORE a call for implementation in a CR. This is the time
when implementation experience and change occurs, so please don't pretend that
HTML5 is locked up merely because some of its features have been experimentally
deployed.

This bug report represents a requirement for a consistent, standardized
solution for specifying arbitrary parameter data on video/audio elements that
is targeted to the UA (or a plugin used by the UA). The motivation, use,
standardization status, and proprietariness of such parameters is outside the
scope of the need for a standardized mechanism used to specify such arbitrary
parameters. The fact that HTML5 and related specs already incorporates such
mechanisms in various contexts (enumerated previously) shows there is good
cause and sets a precedent for such functionality. As a consequence, it is
disingenuous to argue against this functionality in general terms unless you
are also advocating the removal of the existing mechanisms.

G.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 28 July 2011 14:55:54 UTC