This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22209 - "each key MUST be a valid registered constraint name in the IANA-hosted RTCWeb Media Constraints registry"
Summary: "each key MUST be a valid registered constraint name in the IANA-hosted RTCWe...
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 minor
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-30 11:45 UTC by Dominique Hazael-Massieux
Modified: 2014-05-08 09:02 UTC (History)
6 users (show)

See Also:

Attachments

Description Dominique Hazael-Massieux 2013-05-30 11:45:16 UTC 
The description of the MediaTrackConstraintSet and MediaTrackConstraint uses the word MUST to describe the expected content of these values; given that this are values provided by the developer rather than the user agent, it doesn't make much sense, esp. as the algorithm to handle constraints takes care of unknown values.

I would rephrase this as "A MediaTrackConstraintSet is a dictionary containing one or more key-value pairs, where each key is expected to be a valid registered constraint name in the IANA-hosted RTCWeb Media Constraints registry" for instance.
Comment 1 Harald Alvestrand 2013-06-18 14:03:13 UTC 
MUST is inappropriate if we're to allow proprietary constraints and constraints-in-development.
Comment 2 Adam Bergkvist 2013-10-07 07:44:20 UTC 
Let's fix this, if it's still valid, when the new Constrainable interface [1] has been added to the spec.

[1] http://lists.w3.org/Archives/Public/public-media-capture/2013Oct/0027.html
Comment 3 Adam Bergkvist 2013-11-05 08:51:05 UTC 
Keeping the "MUST"-wording for Capabilites since these are provided by the UA.

Proposed change:
https://github.com/fluffy/webrtc-w3c/commit/25b2652dc19897f12076127df307d51fdfc35988
Comment 4 Harald Alvestrand 2013-11-05 16:52:07 UTC 
I'm not sure we can keep the MUST wording for capabilities either, since that would preclude vendor-specific or pre-registration constraints from showing up.

I don't think we want to encourage hiding of vendor capabilities.
Comment 5 Giri Mandyam 2013-11-05 17:20:48 UTC 
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.  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().
Comment 6 Dominique Hazael-Massieux 2014-04-03 12:31:06 UTC 
Assuming the new WebIDL-based approach gets adopted, I think that bug can be closed since dictionaries take care of this issue implicitly.
Comment 7 Stefan Hakansson LK 2014-04-03 13:17:42 UTC 
(In reply to Dominique Hazael-Massieux from comment #6)
> Assuming the new WebIDL-based approach gets adopted, I think that bug can be
> closed since dictionaries take care of this issue implicitly.

I hope it will get adopted - but let's give it a few more days.
Comment 8 Stefan Hakansson LK 2014-05-08 09:02:27 UTC 
Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html