Requirements for constraints maintenance

Hi,

As part of our discussions of last call comments, there has been debates 
around how to maintain the list of recognized constraints in the long term.

When the group was polled to understand if we were close to a consensus 
on this issue, there was a sharp divide of opinions:
   http://doodle.com/9v3beu55pgtq4ndh

In order to progress beyond that, I'm suggesting we look back at the 
requirements we feel any process we adopt to maintain constraints over 
time should fulfill.

I'm listing below some requirements — as a first step, I'm interested on 
feedback on:
* whether these are the right requirements, at the right level of 
mandatoriness (MUST vs SHOULD)
* whether there are other requirements that need to be considered

Once we have an acceptable list of requirements, I think a useful next 
step would be to ask interested parties to explain how their solution 
addresses the said requirements, and possibly why others don't or can't.



We expect the set of constraints to grow over time: there are already 
identified needs for additional ways to constrain these audio/video 
streams (as well as as new type of streams, e.g. depth stream), and we 
expect new needs to emerge as capture devices themselves evolve.

This message tries to list requirements that a process to maintain that 
list of recognized constraint should fulfill based on previous 
discussions in the group as well as my own analysis.

Based on discussions so far, we seem to need to distinguish experimental 
constraints (that are not meant for wide-scale deployment) from formally 
approved constraints (whose approval process make them adapted to 
wide-scale deployment).

With that distinction, the constraint maintenance process:

* SHOULD prevent from formally approving two different constraint names 
for equivalent semantics

* MUST prevent two different semantics from being registered for the 
same constraint name (both at experimental and approved stage)

* MUST ensure that formally approved constraints can be implemented 
interoperably

* MUST ensure that formally approved constraints match the architecture 
of constraints defined in Media Capture and Streams

* MUST ensure that (experimental and approved) constraints are defined 
in WebIDL

* SHOULD ensure that formally approved new constraints don't introduce 
privacy, internationalization or accessibility issues

* SHOULD make it easy to find all constraints (both experimental and 
formally approved)

* SHOULD enable implementors to experiment with new constraints before 
they get formally approved

* SHOULD (MUST?) provide users and implementors with strong guarantees 
in terms of RF licensing for formally approved constraints

* SHOULD operate under a clear governance

* SHOULD offer strong guarantees of maintenance for as long as adding 
new constraints remain useful

* MUST be documented well enough to enable newcomers to propose 
additional constraints

* SHOULD have its documentation easy to discover from the initial list 
of constraints

As I was discussing this list of requirements with Harald, he suggested 
that the path from "experimental" to "formally approved" should happen 
without changing the name used during the "experimental" phase; I 
personally don't think that's a useful requirement, but I would be 
interested in other people opinions.

Dom

Received on Tuesday, 7 July 2015 13:01:33 UTC