Registries and Interoperability

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.

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

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.

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?

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:22:57 UTC