W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2015

VOTE: Constraints Registry

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 6 Oct 2015 18:15:22 +0200
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Cc: "vivien@w3.org" <vivien@w3.org>
Message-ID: <5613F39A.30603@w3.org>
This is the consensus position from the W3C staff (not just Vivien and 
I, but the broader staff with which we discussed the question).

QUESTION 1: SHOULD THE SPECIFICATION REFERENCE A REGISTRY?

[  ] Yes
[ X] No

QUESTION 2: SHOULD THE REGISTRY BE HOSTED AT IANA?

[  ] Yes
[ X] No

Comments:
On question 1, the mechanism of defining new constraints by creating 
partial dictionary seems sufficient, and nor the spec, nor the IANA 
registry document describes what values a registry would add in this 
case, nor why constraints need a different mechanism from the rest of 
the Web platform (HTML elements and attributes, CSS properties, names in 
the global object in JavaScript, etc).

The current draft registry description for the designated expert process 
does not put any requirements on the level of scrutiny, implementors 
interest, IPR commitments or interoperability testing that a reference 
for a new constraint must contain.

Although this could be seen as a mere bug in the proposed registry 
definition, it also demonstrates that a registry can be perceived as 
"just" a list of references (which has low value) or as an evaluation 
process for new references which has high chances of duplicating or 
ignoring existing processes, in this case specifically, the processes 
that W3C has spent many years building around the specificities of the 
Web platform, including its patent policy.


On question 2, if we were to insist that a registry is needed, the use 
of a IANA registry raises the following concerns:
* the use of IANA for IETF registries is governed by an MoU between IANA 
and IETF, which among other things define an escalation path going up to 
the IESG in case of dispute; no similar agreement exists between W3C and 
IANA, and it is thus unclear what the escalation path would be there, 
nor how it would be enforced
   http://tools.ietf.org/html/rfc2860

* having two separate organizations (W3C, IANA) with potential control 
on a given namespace (for constraints) creates confusion and uncertainty 
in the long run both on the status of names defined at a given time, and 
the process to create new ones, which defeats one of the stated goal of 
having a IANA registry

* the reliance on an externally defined and reviewed process for a 
registry seems in general to have hidden rather than resolved the 
questions that have emerged over the past months on this topic: how do 
we define experimental constraints (prefix vs configuration flag vs 
something else)? does a door-bell specific constraint need to be defined 
or registered? are constraints specific to MediaStreamTrack or do they 
apply to other objects? How are namespaces names that would apply to 
different objects? Having a IANA registry strongly suggests that this is 
somebody's else problem, when these are topics that the Device APIs and 
WebRTC Working Groups should consider as their own.

Dom
Received on Tuesday, 6 October 2015 16:15:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 October 2015 16:15:28 UTC