Re: Extensibility for constraints and registry

On 2013-11-21 09:14, Dominique Hazael-Massieux wrote:
> Hi,
>
> During the Media Capture TF F2F last week, we had a detailed discussion
> on the proposed IANA registry for registering new constraints beyond the
> ones we are defining in the Media Capture and Streams spec [1].
>
> I argued during that discussion that the case for an external registry
> (whether hosted by IANA or using a separate mechanism) wasn't clear, and
> that it was probably premature for us to tie ourselves to this specific
> extensibility mechanism.
>
> Given that this was the first time that I argued this point, I was
> tasked with bringing my arguments and a concrete proposal to the list
> (ACTION-28).
>
> Here are the points that I think make it unclear that an external
> registry for constraints is warranted:
> * adding a constraint requires interoperable support from browsers;
> while we could build a process to make this a requisite of final
> registration in the IANA registry, we would likely reinvent an existing
> process made exactly to ensure interoperable support among browsers: the
> W3C process
>
> * while coming up with a name is easy, ensuring that a given constraint
> fits the spec model (which we're still struggling with) requires time,
> expertise and consensus; this group seems like a better fit for such a
> review than a TBD-expert. The frequently used example of "3d camera" as
> a constraint illustrates this: it's not clear to me that a constraint
> would be the right approach to handle 3d cameras, since what you would
> want to get out of it is probably very different from a video stream;
> figuring out the model of how to extend getUserMedia to new use cases
> should be made thoughtfully, esp. as we have so little experience with
> it at this time.
>
> * looked from a few steps back, any W3C spec is in fine a registry of
> names that has special meaning (HTML is a registry of element and
> attribute names, CSS a registry of CSS properties, values, JavaScript
> APIs are a registry of method, attribute, interface names, etc); the
> fact that we have something that looks like a registry (a list of
> constraint names) should not automatically make us think of IANA as the
> right place, and moving something out of W3C into IANA hands should come
> with specific reasons
>
> I heard the following possible reasons for going to IANA rather than W3C
> for registering constraints:
> * registration in IANA can be fast (if the attached process if quick);
> but I think given the interop impact of constraints, fast is probably
> not the most important parameter for that registry; while the W3C
> process is never a matter of days, specs that define small things (e.g.
> hiresdomtimestamp) can reach rec in a matter of a few months
>
> * IANA is here forever, this group (and/or W3C) is not; I would think
> that W3C will probably be needed (and thus exists) as long as IANA;
> whether this particular group exists or not, W3C has a well-known
> process for restarting groups if and when needed; if there is indeed a
> need of defining interoperable constraints for getUserMedia, I see no
> reason to doubt W3C would get such a group started. If for any reason
> this is not possible, I see no reason why W3C could not then point
> people to an external registry that would be emerge out of that
> unfulfilled need (and in fact, even if it didn't, presumably the lack of
> pointer would have no effect on actual interoperability assuming such a
> registry is built with support from implementors)
>
> * constraint names might be reused beyond the W3C spec (e.g. at the
> protocol layer), in which case having a W3C-independent registry would
> make sense; that might (or might not) be true, but given that we don't
> have such a case at this time, it doesn't seem like this should be part
> of our decision.
>
> Overall, I can imagine that once we have experience with extending
> getUserMedia (with constraints and other mechanisms), we realize that
> there are cases where a IANA registry, a wiki page, or another
> registry-based extensibility mechanism will be useful. But I think we
> have way too little experience at this point to commit ourselves to any
> such process, and I don't think we'll get such experience before the
> first version of the core spec finishes its standardization process.
>
> My concrete proposal to replace what is currently in the spec would be
> thus:
> * remove the IANA registry registration from the spec
> * remove mentions of the registry in the spec
> * add a note to implementors in the spec encouraging them to bring
> proposals of new constraints to this group, and to not make new
> constraints available publicly (i.e. without a flag) until two
> independent implementations of such a constraint have surfaced
> (mimicking the CSS WG policy)

I have not thought a lot about this, but to me this proposal makes 
sense. Other opinions?

Stefan

>
> Dom
>
> 1. http://www.w3.org/2013/11/14-mediacap-minutes.html#item07
>
>
>
>

Received on Friday, 22 November 2013 11:48:14 UTC