- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 29 Sep 2015 15:32:36 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <560A92F4.80207@alvestrand.no>
Responses inline. On 09/29/2015 02:39 PM, Eric Rescorla wrote: > > > On Tue, Sep 29, 2015 at 2:37 AM, Harald Alvestrand > <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote: > > 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. > > > Why do you say "guidance"? The purpose of this vote is to definitively > decide the issue. Or do you believe that there will still be discretion as > to these questions? Yes, this is not well formulated. The vote should decide the issue, and give guidance to the text. Since this document doesn't have the text in it, it can't be decisive on the precise wording. Can you suggest alternative wording that captures that? > > > > 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? > > > This seems unnecessarily leading, since it might be appropriate and > desirable, but not necessary. I would write "SHOULD WE DEFINE A REGISTRY" That reformulation seems appropriate, except that we have already defined a registry; the question is whether we should delete it. What about: 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: IS AN IANA REGISTRY APPROPRIATE? > > > This is leading in the opposite direction. I would write > "SHOULD THE REGISTRY BE HOSTED AT IANA" That formulation looks good to me. > > -Ekr > > [ ] 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. > > > -- Surveillance is pervasive. Go Dark.
Received on Tuesday, 29 September 2015 13:33:10 UTC