Re: VOTE - Constraints Registry

This is the position from Aspect.

On Oct 6, 2015, at 8:18 AM, Harald Alvestrand wrote:

> 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?
> 
> [X] 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?
> 
> [X] 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 Monday, 12 October 2015 12:12:53 UTC