Re: [Bug 22209] "each key MUST be a valid registered constraint name in the IANA-hosted RTCWeb Media Constraints registry"

On 11/5/13 8:11 PM, Mandyam, Giridhar wrote:
>> 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?

Who cares, when the constraints api is REQUIRED to be flexible? - This 
bug isn't about "required to implement" is it?

I think Dom nails it in 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22209#c0 - MUST provides 
no useful invariant to the UA here, which doesn't need a registry of 
what it doesn't support.

Saying we desire everyone to register their keys, is different from 
saying the API may crash or detect such a thing. MUST is a FUD-based 
empty mandate, while SHOULD conveys the nature of the mechanism more 
accurately IMHO. I care about clarity, and your confusion about 
implementation fuels my concern that the word MUST is the culprit (see 
below).

>    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.

An error MUST be raised. This is already in there and isn't extra work, 
as IANA-validity totally factors out of this algorithm. Unknown == 
unsupported.

> 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 think vendors should name-prefix for constraints like they do for 
stats. Is that all IANA does?

.: Jan-Ivar :.

>> 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 18:04:07 UTC