- From: Cullen Jennings <fluffy@iii.ca>
- Date: Wed, 7 Oct 2015 15:03:22 -0700
- To: Harald Tveit Alvestrand <harald@alvestrand.no>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-Id: <23B99B89-547E-467C-8C54-3BBC86744A2A@iii.ca>
The PR for this is at https://github.com/w3c/mediacapture-main/pull/256 <https://github.com/w3c/mediacapture-main/pull/256> > On Oct 6, 2015, at 5:18 AM, Harald Alvestrand <harald@alvestrand.no> 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? > > [ ] 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 Wednesday, 7 October 2015 22:02:45 UTC