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

[media capture] Results of Vote on Media Capture and Streams Constraints Registry

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Wed, 14 Oct 2015 07:45:54 -0400
Cc: Dominique Hazael-Massieux <dom@w3.org>, Harald Alvestrand <harald@alvestrand.no>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Media Capture TF <public-media-capture@w3.org>
Message-Id: <E30EFFFA-84BE-45FA-A8DE-6FD1A7B9699C@fjhirsch.com>
To: W3C Device APIs WG <public-device-apis@w3.org>
The results of the vote on the topic of the Streams Constraints Registry related to the Media Capture and Streams specification  is now available, as follows:

https://lists.w3.org/Archives/Public/public-media-capture/2015Oct/0018.html

[[

-------- Forwarded Message --------
Subject: Result of "VOTE - Constraints Registry"
Date: 14/10/15 08:08
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: public-webrtc@w3.org <public-webrtc@w3.org>
CC: public-media-capture@w3.org <public-media-capture@w3.org>

The vote [1] has now ended. In total eight votes were given, and for
question 1 ("SHOULD THE SPECIFICATION REFERENCE A REGISTRY?") six votes
said "NO" and two said "YES".

As announced already in [1] this means that the text in section 11.2 of
Media Capture and Streams [2] will be replaced with “See section 14 for
constraints defined by this specification. Other specifications may
define additional constraints.”

The chairs will work with the Editors to make this happen.

Stefan for the chairs

[1] https://lists.w3.org/Archives/Public/public-webrtc/2015Oct/0007.html
[2] http://w3c.github.io/mediacapture-main/


]]

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch

> On Oct 6, 2015, at 10:22 AM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> 
> The following is a vote request (one vote per company participating in DAP and/or WebRTC) related to the Media Capture and Streams specification [1] on the topic of the Streams Constraints Registry.  A message has also been sent on the WebRTC list [2].
> 
> Please see the instructions at the end before replying regarding how to vote.
> 
> The deadline for voting is Tuesday, October 13, 23:59 GMT
> 
> [1] http://w3c.github.io/mediacapture-main/getusermedia.html
> 
> [2] https://lists.w3.org/Archives/Public/public-webrtc/2015Oct/0007.html
> 
> regards, Frederick
> 
> Frederick Hirsch
> Chair, W3C Device APIs WG (DAP)
> 
> www.fjhirsch.com
> @fjhirsch
> 
> --- start ---
> 
> In the current version of the “Media capture and streams” specification,
> the following text appears in section 4.3.5
> 
> “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”.
> 
> -- end --
> 
> 
> 
> 
Received on Wednesday, 14 October 2015 11:46:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:34 UTC