This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It used to be that this text was what we intended to say: " The Capabilities dictionary specifies the subset of the constrainable properties and values from the registry that the UA supports". (section 11.3) and that it was a static method. Now it is a method on the track, and it is said that: "The getCapabilities() method returns the dictionary of the capabilities that the object supports." (section 11.1.2). Obviously, if the latter is the only thing available, the example is flawed. If the former is going to be true, there will have to be a static method, or a method on NavigatorUserMedia, that exposes the getCapabilities() accessor there. Which should it be?
A possibility is to have getCapabilities available at both levels - as a per-track function, telling you what you can ask this input source about, and as a per-browser function, telling you all possibilities for passing constraints to getUserMedia. These functions need not have the same name. One concern is that the new getCapabilities would either have to be restricted (return less or require permission) or provide additional fingerprinting surface.
This was considered at the Media Capture TF meeting on May 19, and the WG concluded that this doesn't need to be addressed. getCapabilities will only be available on tracks.