Re: Requirements for constraints maintenance

On 07/07/2015 03:01 PM, Dominique Hazael-Massieux wrote:
> 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.

Thanks for starting this!

There wasn't much response to this in July; I'm hoping that a few more
people are back from vacation now.

<contributor hat>
I note that the IANA registry process has dealt with almost exactly the
same kind of questions for the last 10 years. Whether or not we want to
establish a relationship with the actual IANA, we should make sure we
learn from the experience.

>
>
>
> 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).

IANA experience, multiple contexts: We can't make the determination of
whether a constraint will be widely used or not at the time we define it.
There are two choices:

- Register a name that's "obviously wrong" (X-header, experimental OID,
googAnything constraint), and change it when it's clear that it's going
to be widely used

- Register a name that we're willing to live with if it turns out that
it is widely used, and accept as a cost of doing business that we'll
"burn" some good names by registering them with a definition that turns
out to be useless down the road.

Experience with IANA registries has tended to lean heavily towards the
second option.

Some comments below - where there is no comment, I agree with the
requirement.

>
> 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)

This is the essential point of a registry.
>
> * MUST ensure that formally approved constraints can be implemented
> interoperably
I'd phrase this as "are well enough defined that they 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
I'd drop this. They will, but we can't tell how - the requirement should
be that their specification documents any privacy, internationalization
or accessibility issues introduced.
>
> * SHOULD make it easy to find all constraints (both experimental and
> formally approved)

I think this falls out naturally from the uniqueness constraint; if it's
not easy to find all constraints registered, it's also difficult to
verify that we're not re-registering with the same name.
>
> * SHOULD enable implementors to experiment with new constraints before
> they get formally approved

I don't think we need to mention this - we can't prevent it even if we
wanted to.
Actually I'd argue that the requirement is the flipside: That the
registration process should be lightweight enough that implementors take
the time to register constraints before they start widespread
experimentation.

>
> * SHOULD (MUST?) provide users and implementors with strong guarantees
> in terms of RF licensing for formally approved constraints
I'd say "under IPR conditions no more restrictive than for W3C
Recommendations" - there are no guarantees in RF land.
>
> * SHOULD operate under a clear governance
I'd say "MUST" here. No matter what the governance model is, we need to
know what it is.
>
> * SHOULD offer strong guarantees of maintenance for as long as adding
> new constraints remain useful
Since I'm skeptical of guarantees (they are so often lies), I'd go with
"strong assurances".
>
> * 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.

See argument above; it's clear that we have different opinions here.

What do other people think?

Received on Tuesday, 18 August 2015 10:24:22 UTC