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

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

--- Comment #39 from Henri Sivonen <hsivonen@iki.fi> 2011-07-29 14:08:22 UTC ---
(In reply to comment #35)
> (In reply to comment #32)
> > 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

UA-targeted stuff in the URL belongs in the fragment part--not the query part.

> 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.

audio/industry-consortium-drm-wrapper would own the semantics of its fragment
ids, though.

> > (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.

Supporting plug-ins doesn't have any effect on DRM in <audio> or <video>.

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

I suppose I don't need to know concretely what products implement the spec you
cite, but I have to say that allegations of products doing something appear
less convincing if the person alleging product behavior consistently avoids
naming concrete products.

> 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 see.

> > 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>
...
> As to your alternative above, media types and DRM are entirely orthogonal
> functions, and implementations of these features tend to remain orthogonal as
> well.

>From the point of view of "does this browser support this format?" it doesn't
matter which part of the media container is container format proper and which
part is DRM obfuscation, so as far as the HTML layer is concerned, it would be
architecturally sound to treat the combination "container format foo obfuscated
by method bar" as a container media type.

> > 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.

You are asking for a spec change to a spec. Whether the motivation of the
change is appropriate for the primary purpose of the spec is relevant to
whether it makes sense to make the change. (The primary purpose of the HTML
spec is to increase interoperability between general-purpose Web browsers. The
primary purpose of DRM is to prevent interoperability with products whose
developers aren't bound by the terms imposed by the DRM proprietor.)

> 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.

Adding <param> children to <source> is pretty late at this point. Unless such
change is backed by strong rationale for advancing goals on the public Web
browsable using general-purpose browsers, I think it doesn't make sense to make
the change. So far, the change has been motivated by considerations that don't
apply to the public Web browsable using general-purpose browsers.

> > 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.

<source x-industry-consortium-foo="bar"> and <source><param
name="industry-consortium-foo" value="bar"></source> are merely syntactic
transformations of each other. They are equally
open/closed/proprietary/product-specific. The main difference is that <source
x-industry-consortium-foo="bar"> doesn't require changes to the HTML parsing
algorithm but <source><param name="industry-consortium-foo"
value="bar"></source> does.

> 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.

Positioning DRM as analogous to i18n or a11y? Wow.

> > 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

All major browsers have shipped parsers that treat <source> as a void element.

(In reply to comment #34)
> > So, why
> > don't you just use "x-param" if that's what you need?
> 
> Because (1) we would need:
> 
> x-param-1
> x-param-2
> x-param-3
> ...
> x-param-n
> 
> where n increases over time.

Why is this any more or less problematic than 
<param name="param-1>
<param name="param-2>
<param name="param-3>
...
<param name="param-n>
increasing over time?

> Because (2) this would introduce a disparity between HTML and XHTML syntaxes,
> and would require:
> 
> foo:x-param-1
> foo:x-param-2
> foo:x-param-3
> ...
> foo:x-param-n
> 
> for XHTML, and who would own "foo"?

You don't need foo: in XHTML. You can use x-param-1="..." in XHTML.

> Because (3) this method may require modifying a UA for every new x-param-*
> added, instead of having a generic mechanism like <param> which can be
> collected by the UA parser (for video/audio) and passed a collection to the
> video/audio component/plugin as a single entity irrespective of which
> parameters are present.

In UAs where <video>/<audio> is implemented by pluggable components, if we
assume a mechanism that passes name-value pairs to the component, why should
the situation be different depending on whether the pairs are collected from
the attributes (as already done for <embed> and NPAPI) or from <param> (as
already done for <object> and NPAPI)?

> Because (4) use of x-* attributes REDUCES interoperability and partitions
> content and implementations.

Why would it reduce interoperability more than <param> would? These are just
syntactic alternatives?

> Firefox supports a plugin architecture that will undoubtedly be used for
> video/audio. 

Firefox very deliberately doesn't support plug-ins for <video>/<audio>.

> Why should authors have to choose between using (1) object plus param to obtain
> compatibility with current practice (including) DRM and (2) video/audio minus
> param to obtain the new functionality of the latter while losing the
> functionality of the former.

If the new functionality of <video>/<audio> manages to lure authors away from
DRM, I think it's a good outcome, because DRM is inherently bad for the ability
of a fully Free Software client stack to compete.

-- 
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 Friday, 29 July 2011 14:08:30 UTC