Re: Extensibility for constraints and registry

My answer to this whole discussion about registries depends on how
much longer we expect the WG to exist.

If the WG will be around for another year, I'd start a registry
document within the WG - probably as a separate document to the gUM
document to allow the gUM document to go to REC independently.

If the WG is expected to close its work on media capture soon (within
a few months), then writing up the existing constraints and pointing
to IANA for adding further constraints seems ok to me.

However, I think what's been missing in the discussion is the required
process to add new names to the registry (or even to the list in the
W3C).

I would a minimum expect a spec to be written that defines what a
browser is expected to do with a certain name. If that spec is written
in the W3C or in IETF doesn't matter. We should however, specify what
the minimum information is that the spec needs to contain. Pushing
this off to "expert review" is too vague and requires the IANA to
understand what we are expecting them to check up in a name for us.

The point is that browsers need to do something with the name that
they are given. There is an effect that is beyond the mere existence
of the name. The document at
http://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints-registry/?include_text=1
does not contain any information that puts an expert reviewer into a
good position to decide whether a name is appropriate and will provide
a desired effect to a developer. It does not even make sure that the
values used for a new constraint fit the data types that the
constrainable interface expects.

I think that eventually we should end up with an IANA registry &
process. However, I believe that we are not ready for this yet. At
this point in time we have not provided enough of a process to an
expert reviewer to expect them to make good decisions about whether a
proposal for a new constraint is sufficiently detailed that it can be
implemented in a UA.

My recommendation is to start building such a registry within the WG
and keep it going for as long as possible, while at the same creating
and updating a document with a list of all the things that a new
registration needs to fulfill before it can be accepted. That should
allow us to eventually have a registry that we can hand off to IANA.

Regards,
Silvia.


On Thu, Nov 21, 2013 at 7:13 PM, Dominique Hazael-Massieux <dom@w3.org> 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)
>
> Dom
>
> 1. http://www.w3.org/2013/11/14-mediacap-minutes.html#item07
>
>
>

Received on Tuesday, 26 November 2013 01:50:51 UTC