Questions for a vote - Constraints registry

As per the outcome of discussion in Seattle, I have drawn up a set of
questions that I propose we ask the member companies of WEBRTC and DAP
to vote on in order to resolve this issue.

The text is below. I'll leave this open for comment until the end of
Friday, October 2; if no good reason not to send it out has been found
by then, we expect to issue the vote to the WGs on Monday, October 5,
with a closing date of Monday, October 12.

For those who like documents better, or want to follow along on any
changes, the link is here:

https://docs.google.com/document/d/1Mb503stH_BOREidt85dLDw2MHLwbbq1yeU66PpoG97U/edit?usp=sharing
---------------------------------------------------------------------------
Question for a 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 give guidance to the Task Force that can be
captured in text as soon as possible. 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: IS A REGISTRY NEEDED?

[  ] 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: IS AN IANA REGISTRY APPROPRIATE?

[  ] 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.


-- 
Surveillance is pervasive. Go Dark.

Received on Tuesday, 29 September 2015 09:38:31 UTC