VOTE - Constraints Registry

In the current version of the “Media capture and streams” specification,
the following text appears in section 4.2.4, 4.3.5, 4.3.6 and 4.3.7.1
and 4.3.8

“MediaTrackSupportedConstraints represents the list of constraints
recognized by a User Agent for controlling the Capabilities of a
MediaStreamTrack object.
Future specifications can extend the MediaTrackSupportedConstraints
dictionary by defining a partial dictionary with dictionary members of
type boolean and an identifier that is a Property Name registered in the
[RTCWEB-CONSTRAINTS] registry.”

Section 11.2 describes the registry within the Constrainable pattern:

“There is a single IANA registry that defines the constrainable
properties of all objects that implement the Constrainable pattern. The
registry entries must contain the name of each property along with its
set of legal values. The registry entries for MediaStreamTrack are
defined below. The syntax for the specification of the set of legal
values depends on the type of the values. In addition to the standard
atomic types (boolean, long, double, DOMString), legal values include
lists of any of the atomic types, plus min-max ranges, as defined below.”

Section 14.1 contains the initial contents of this registry:

“IANA is requested to register the following constrainable properties as
specified in [RTCWEB-CONSTRAINTS]:
The following constrainable properties are defined to apply to both
video and audio MediaStreamTrack objects:”

>From the discussion in the Media Capture TF, it has become clear that
there is no consensus on whether the proposed registry is an appropriate
mechanism or not, and if it is not appropriate, whether it should be
replaced with some other form of registration, or whether no
registration mechanism is necessary.

Given that the search for consensus has failed, this is a call for a
vote on the issue among member organizations participating in the DAP
and WebRTC WGs (the “parent” WGs of the Media Capture TF). The form of
the vote is designed to decide the direction we wish to go in, and give
guidance to the Task Force on what the text needs to say. There are two
questions, and each member organization is asked to respond to both
(i.e. do not skip the second even if the response to the first is “no”).

QUESTION 1: SHOULD THE SPECIFICATION REFERENCE A REGISTRY?

[  ] Yes
[  ] No

If the majority is NO, the text in section 11.2 will be replaced with
“See section 14 for constraints defined by this specification. Other
specifications may define additional constraints.”
If the majority is YES, the next question will decide further work.

QUESTION 2: SHOULD THE REGISTRY BE HOSTED AT IANA?

[  ] Yes
[  ] No

If the majority is YES, the current text will be retained unchanged.

If the majority is NO, text referring to another registry will be
developed and inserted; the byte stream format registry
(https://w3c.github.io/media-source/byte-stream-format-registry.html) is
a possible candidate for a pattern to build on.


Logistics
=======
This vote runs from Tuesday, October 6 until Tuesday, October 13, 23:59 GMT.
Each company that is a member of DAP or WEBRTC (or both) has one vote.
Please announce your vote by an email to the Media Capture Task Force
mailing list (public-media-capture@w3.org) , with the subject line
“VOTE: Constraints Registry”.

Received on Tuesday, 6 October 2015 12:19:13 UTC