{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/mediacapture-main/issues/115","labels_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/115/labels{/name}","comments_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/115/comments","events_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/115/events","html_url":"https://github.com/w3c/mediacapture-main/issues/115","id":53843585,"number":115,"title":"Cababilities need to clearly specify that they are constant over time","user":{"login":"dontcallmedom","id":216410,"avatar_url":"https://avatars.githubusercontent.com/u/216410?v=3","gravatar_id":"","url":"https://api.github.com/users/dontcallmedom","html_url":"https://github.com/dontcallmedom","followers_url":"https://api.github.com/users/dontcallmedom/followers","following_url":"https://api.github.com/users/dontcallmedom/following{/other_user}","gists_url":"https://api.github.com/users/dontcallmedom/gists{/gist_id}","starred_url":"https://api.github.com/users/dontcallmedom/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dontcallmedom/subscriptions","organizations_url":"https://api.github.com/users/dontcallmedom/orgs","repos_url":"https://api.github.com/users/dontcallmedom/repos","events_url":"https://api.github.com/users/dontcallmedom/events{/privacy}","received_events_url":"https://api.github.com/users/dontcallmedom/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-01-09T08:13:47Z","updated_at":"2015-01-09T08:14:07Z","closed_at":null,"body":"*Initially [reported in bugzilla](https://www.w3.org/Bugs/Public/show_bug.cgi?id=27077) by Harald Alvestrand 2014-10-16 13:07:45 UTC*\r\n\r\nFrom Jan-Ivar, in [bug 25777](https://www.w3.org/Bugs/Public/show_bug.cgi?id=25777):\r\n\r\nWhile examples are nice, I would argue they're no replacement for specification.\r\n\r\nAre capabilities accurate?\r\n\r\nWhile it is possible to deduce from the applyConstraints algorithm [1] that capabilities are allowed to be a super-set of what the UA supports, I find no mention of this where Capabilities is defined [2].\r\n\r\nI've read the definition a couple of times, and even though it uses the word \"subset\" four times in one paragraph, it still seems to equate what the capabilities read with what \"the UA supports\", which doesn't allow for capabilities to be either-or (e.g. super framerate OR super resolution).\r\n\r\nI think it would help implementations if the spec stated that returned capabilities must a set or super-set of what the UA supports.\r\n\r\nAre capabilities constant?\r\n\r\nI find conflicting text on this in the spec:\r\n\r\n\"The UA may choose new settings for the Capabilities of the object at any time. When it does so it must attempt to satisfy the current Constraints, in the manner described in the algorithm above.\" [2]\r\n\r\nvs.\r\n\r\n\"Source capabilities are effectively constant. Applications should be able to depend on a specific source having the same capabilities for any session.\" [3]\r\n\r\n[1] http://w3c.github.io/mediacapture-main/getusermedia.html#dfn-applyconstraints\r\n[2] http://w3c.github.io/mediacapture-main/getusermedia.html#capabilities\r\n[3] http://w3c.github.io/mediacapture-main/getusermedia.html#terminology"},"comment":{"url":"https://api.github.com/repos/w3c/mediacapture-main/issues/comments/69305163","html_url":"https://github.com/w3c/mediacapture-main/issues/115#issuecomment-69305163","issue_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/115","id":69305163,"user":{"login":"dontcallmedom","id":216410,"avatar_url":"https://avatars.githubusercontent.com/u/216410?v=3","gravatar_id":"","url":"https://api.github.com/users/dontcallmedom","html_url":"https://github.com/dontcallmedom","followers_url":"https://api.github.com/users/dontcallmedom/followers","following_url":"https://api.github.com/users/dontcallmedom/following{/other_user}","gists_url":"https://api.github.com/users/dontcallmedom/gists{/gist_id}","starred_url":"https://api.github.com/users/dontcallmedom/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dontcallmedom/subscriptions","organizations_url":"https://api.github.com/users/dontcallmedom/orgs","repos_url":"https://api.github.com/users/dontcallmedom/repos","events_url":"https://api.github.com/users/dontcallmedom/events{/privacy}","received_events_url":"https://api.github.com/users/dontcallmedom/received_events","type":"User","site_admin":false},"created_at":"2015-01-09T08:14:07Z","updated_at":"2015-01-09T08:14:07Z","body":"*Comment by Harald Alvestrand 2014-10-16 13:08:35 UTC*\r\n\r\nFrom Harald, on mailing list October 10:\r\n\r\nI think the definition is intended to say that it be a superset.\r\nThat's what the example was supposed to demonstrate: even though only two resolutions are supported, the values given are ranges.\r\n\r\n>\r\n> Are capabilities constant?\r\n>\r\n> I find conflicting text on this in the spec:\r\n>\r\n> \"The UA may choose new settings for the Capabilities of the object at any time.\r\n> When it does so it must attempt to satisfy the current Constraints, in the\r\n> manner described in the algorithm above.\" [2]\r\n\r\nI think \"new settings for the Capabilities of the object\" was meant to be parsed as\r\n\r\n(new settings for) (the Capabilities of the object)\r\n\r\nie it is the settings that are new. The capabilities remain unchanged.\r\n(and I think capitalizing Capabilities here is probably misleading)."}}