22209 2013-05-30 11:45:16 +0000 "each key MUST be a valid registered constraint name in the IANA-hosted RTCWeb Media Constraints registry" 2014-05-08 09:02:27 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC Linux RESOLVED FIXED P2 minor --- 1 dom public-media-capture adam.bergkvist anssi.kostiainen harald mandyam public-media-capture stefan.lk.hakansson oldest_to_newest 88442 0 dom 2013-05-30 11:45:16 +0000 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. 89477 1 harald 2013-06-18 14:03:13 +0000 MUST is inappropriate if we're to allow proprietary constraints and constraints-in-development. 94381 2 adam.bergkvist 2013-10-07 07:44:20 +0000 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 95794 3 adam.bergkvist 2013-11-05 08:51:05 +0000 Keeping the "MUST"-wording for Capabilites since these are provided by the UA. Proposed change: https://github.com/fluffy/webrtc-w3c/commit/25b2652dc19897f12076127df307d51fdfc35988 95811 4 harald 2013-11-05 16:52:07 +0000 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. 95815 5 mandyam 2013-11-05 17:20:48 +0000 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(). 103332 6 dom 2014-04-03 12:31:06 +0000 Assuming the new WebIDL-based approach gets adopted, I think that bug can be closed since dictionaries take care of this issue implicitly. 103348 7 stefan.lk.hakansson 2014-04-03 13:17:42 +0000 (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. 105420 8 stefan.lk.hakansson 2014-05-08 09:02:27 +0000 Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html