Extensibility for constraints and registry

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)

Dom

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

Received on Thursday, 21 November 2013 08:14:06 UTC