- From: Mandyam, Giridhar <mandyam@quicinc.com>
- Date: Wed, 6 Nov 2013 01:11:16 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
>Why differentiate unknown from unsupported? Are you saying that a valid implementation could choose to support only a subset of the constraints listed in Section 12 currently, even though they constitute a known set of constraints? I was under the impression that the current list (with the exception of noaccess and peeridentity) reflected broad consensus within the group as to the minimum set of constraints necessary for support in an implementation. >Constraints constrain, so if our browser hasn't heard of your mandatory constraint, then we don't support what you want, which is what you wanted to know, which is why we fire the error callback to you. Mission accomplished. We don't need IANA for that. - The browser just has to recognize what it knows and object to or ignore what it doesn't know here. >IANA registration is a good process for knowing what to implement, not for knowing what to support rejection of, because a new constraint may be registered tomorrow. I thought this bug was pretty clear - each key whether vendor-specific or not must appear in the IANA registry. Constraints could get added after implementations roll out, and if those newer constraints are not recognized by older implementations an error can be raised. I think part of the value of putting vendor-specific constraints through the expert review process associated with the registry is so that new vendor-specific constraints don't step on the namespace of future constraints that the group may want to adopt. Do you feel differently? > I agree. It is the error callback in step 4 - http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-4 This version of the spec had not been released when I wrote my comment. My original remark was accurate with respect to the most current working draft of the spec , which was unclear as to expected implementation behavior when encountering an unknown mandatory constraint. -----Original Message----- From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com] Sent: Tuesday, November 05, 2013 4:45 PM To: public-media-capture@w3.org Subject: Re: [Bug 22209] "each key MUST be a valid registered constraint name in the IANA-hosted RTCWeb Media Constraints registry" On 11/5/13 12:24 PM, Harald Alvestrand wrote: > On 11/05/2013 06:20 PM, bugzilla@jessica.w3.org wrote: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22209 >> >> Giri Mandyam <mandyam@quicinc.com> changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> CC| |mandyam@quicinc.com >> >> --- Comment #5 from Giri Mandyam <mandyam@quicinc.com> --- We >> discussed vendor-specific constraints during the F2F at TPAC 2012 >> (http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/att-0196/minutes-2012-10-30.html). >> >> I believe what reflected consensus was that vendor-specific >> constraints be added to the IANA registry, which would allow such >> constraints to undergo expert review as per RFC 5226. We can reconfirm this at the next F2F however. >> >> On a related note, I do believe the spec is unclear as to what the >> implementation should do when a valid IANA-registered vendor-specific >> constraint is provided to MediaStreamTrack.applyConstraints() that >> the implementation does not recognize or support. Why differentiate unknown from unsupported? Constraints constrain, so if our browser hasn't heard of your mandatory constraint, then we don't support what you want, which is what you wanted to know, which is why we fire the error callback to you. Mission accomplished. We don't need IANA for that. - The browser just has to recognize what it knows and object to or ignore what it doesn't know here. IANA registration is a good process for knowing what to implement, not for knowing what to support rejection of, because a new constraint may be registered tomorrow. >> I assume an exception can be >> raised, but I did not find specific guidance in the latest working >> draft. The constrainable interface proposal also defines an error >> callback on applyConstraints(). >> > I believe the desired behaviour is 100% clear. > > If the constraint is mandatory, the applyConstraints() fails. > If the constraint is optional, the constraint is ignored. I agree. It is the error callback in step 4 - http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-4 .: Jan-Ivar :. > Jan-Ivar and I have been exchanging mail on how to express that in > WebIDL form.
Received on Wednesday, 6 November 2013 01:11:46 UTC