Re: Registries and Interoperability

On Mon, Feb 4, 2013 at 1:22 PM, Harry Halpin <hhalpin@w3.org> wrote:
> Quick note,
>
> I agree with Ryan's concerns as regards registries not allowing
> interoperability and possibly being dangerous from an IRP perspective.
> However, from W3C's perspective we we're not planning on running the Working
> Group in an open-ended manner like the WebApps Working Group (see below for
> reasoning). Thus, it seems we should determine:
>
> 1) If we want any extensibility in algorithm identifiers, which requires
> either a very low-bar approach (wiki) or a high-bar approach (IANA)
> 2) If we don't want any extensibility in algorithm identifiers, so they
> essentially "freeze" when we go to Last Call, and adding new ones requires
> rechartering the Working Group
>
> I think there's the situation where there's a new algorithm people may want
> to use, but we don't have enough industry momentum to reopen the Working
> Group.

If there's not industry momentum and within implementors, what value
does it serve the broader web community of users, authors, and
developers? If there is broad consensus, then what's the challenge?

>
> As I understand it (and Wendy's a lawyer, so she can correct re IPR), the
> real advantage of process is testing and IPR RF commitments.
>
> From a W3C Process point, the IPR is assigned at the Recommendation phase,
> with initial commitments made to charter. The advantage is that features of
> the W3C Rec for Web Cryptography will have a high assurance of royalty-free
> implementation, regardless of the test-cases.

We should be clear here: royalty-free with respect to participants.
There's always the possibility of external factors here, which is part
of why having the WG process works, to identify and find solutions to
these factors.

> The disadvantage of that is to
> add a new algorithm via adding a new identifier, we'd have to re-open the
> Working Group and start the IPR process all over again.  However, any
> registry would not have W3C RFF IPR policy, although we could apply an IETF
> policy to it (which I would strongly suggest).
>
> From a testing standpoint, another strong point is that W3C requires
> demonstrated interoperability. However, *running* the test suite and adding
> new tests does not require re-opening the Working Group, unlike making
> modifications to the specification. The test-suite can be stored using Git
> in order to allow merges, and will be maintained by W3C after the lifetime
> of the Working Group. We can add our test-suite to be part of a larger
> test-suite (I would think HTML WG's test suite would make sense) so it can
> be easily added to by others and maintained after the lifetime of the
> Working Group.
>
> My suggestion for a process is then:
>
> 1) Keep algorithm identifiers in the specification up until we go to Last
> Call, and that the test-cases for Rec status test each of them. Thus, no
> text is removed from spec. We clearly specify that algorithms in the spec
> have RFF status, demonstrated interoperability (via test-suite), and are to
> be preferred by WebApp developers.
>
> 2) Then after that period, people proposing new algorithms are asked to go
> to the IANA registry, which will have some explanatory text referenced in
> the spec.

As mentioned, this remains a troubling proposal.

>
> 3) The IANA registry have a fairly stringent requirement of at least two
> interoperable user-agents as well as the "Well-Specified" text given by Ryan
> in the spec already in order to get in registry.

As I mentioned, this text was certainly not intended to be a long-term
text. I would propose this be removed, as it was more of an editorial
note (before I discovered the "ednote" attribute of the tools)

I think it's demonstrably harmful to the spec and the process to
include this text going forward.

>
> 4) The W3C/IANA contact for the registry check new requests for algorithm
> identifiers by demanding test-cases. These can get added to an
> "experimental" branch of the HTML test-suite.
>
> 5) If we get to the point where we have lots of new algorithms and momentum
> is clear, the contact recommends re-opening/re-chartering the Working Group
> to the W3C. The W3C/IANA can reject spurious new identifiers (including ones
> that make only minor modifications to those in spec) or one's that are known
> to have IPR issues.
>
> Ryan, does that address the your concerns?

No

>
> Any thoughts?
>
> The W3C and IANA have a fairly close relationship, and we are used to
> dealing with IANA in this way in other WGs, so the mechanics aren't an
> issue. We just need to figure out what's best for the WG - to have an
> extensibility point or not, and if so, what are the requirements that we at
> W3C (and any volunteers!) can maintain after the lifetime of the WG. We do
> prefer to close WGs as it helps get us the IPR closed, and in general
> increases the chances of interoperability by demanding implementation by a
> given date.
>
>    cheers,
>      harry
>
>
>
>
>
>

Received on Monday, 4 February 2013 21:56:25 UTC