Moving to CR: proposed exit criteria, feastures at risk

Dear all,

We're almost there.

You'll find here below more information concerning the exit
criteria and identification of features at risk and a draft proposal.

Each time that a document reaches a new milestone in its move
towards recommendation, we have to describe the exit criteria
that will allow us to move on to the next milestone. The document
should also quote all features at risk. This information will appear
in the request to move to CR sent to the Director, and also
in the Call for Implementations. Quoting  Section 7.4.3 of the
Process Document [1]:

-------
In the Call for Implementations, the Working Group MAY identify specific
features of the technical report as being "features at risk." General
statements such as "We plan to remove any unimplemented feature" are not
acceptable; the Working Group MUST precisely identify any features at
risk. Thus, in response to a Call for Implementations, reviewers can
indicate whether they would formally object to the removal of the
identified features.
----

I think that the above is clear and fair for building a robust spec.
 
You'll find here below my draft proposal for exit criteria.  It gives
a general list of all the features that XKMS proposes and how many 
implementations we need to have. I mostly considered that all the 
REQUIRED features needed two complete (client/server) implementations 
whereas the recommended or optional ones would be ok with one 
complete implementation. If you think that any of those features is 
at risk, we must specify them as such now. If we don't do so now 
and want to remove them later, it means we'll have to go back to
Last Call, even if it's for a short period.

Please send in your feedback.

Thanks!

[1] http://www.w3.org/2003/06/Process-20030618/tr.html#cfi

-jose

----------------

Exit Criteria

The XKMS Specification describes two different protocol sets (X-KISS,
X-KRSS), a message syntax, as well as three different message
processing mechanisms (Synchronous, Asynchronous, Two-Phase Request,
Compound Requests and Responses). Moreover, part 2 of the XKMS
Specification describes different protocol bindings with security
enhancements for the XKMS messages (HTTP, Soap 1.1 and 1.2, SSL/TLS).

From this basis, we propose the following exit criteria, where one
complete implementation stands for both a client and a server
interoperable implementation:

* Message processing mechanisms:
  - A minimum of two complete implementations for all
    the REQUIRED message processing mechanisms (Synchronous response)
  - A minimum of one complete implementation for all the RECOMMENDED and 
    OPTIONAL message processing mechanisms (Asynchronous response,
    Two-Phase protocol)

* Message syntax:
  - For each of the supported message processing mechanisms, a minimum
    of two 
    complete implementations for all the required and optional
    elements and attributes defined in Section 3 for the Request and
    Response messages as well as for the Compound and Status 
    requests (i.e, if an implementation doesn't support 
    Asynchronous processing of messages, it doesn't need to support
    the Status request elements either, but it does have
    to return a Result code such as Receiver.Refused)

* X-KISS protocol set:
  - A minimum of two complete implementations for each of the following
    X-KISS Services: Locate and Validate
  - A minimum of two complete implementations for all the REQUIRED 
    elements and attributes described in X-KISS message set
  - A minimum of one complete implementation for all the OPTIONAL
    elements and attributes described in the X-KISS message set

* X-KRSS protocol set:
  - A minimum of two complete implementations for each of the following
    X-KRSS services: Register, Reissue, Revoke, and Recover
  - A minimum of two complete implementations for all the REQUIRED 
    elements and attributes described in X-KRSS message set
  - A minimum of one complete implementation for all the OPTIONAL
    elements and attributes described in the X-KRSS message set

* Bindings:
  - A minimum of two complete implementations supporting 
    HTTP Transport and Soap 1.1 encapsulation
  - A minimum of one complete implementation supporting
    HTTP Transport and Soap 1.2 encapsulation
  - A minimum of two complete implementations supporting Exclusive
    Canonicalization together with XML Signature
  - A minimum of one complete implementation supporting of each of
    the following security enhancements: Payload Authentication
    (levels I and II), TLS Bindings (levels I-III)

* Interoperability matrix
  -The WG will create an interoperability matrix with test cases and
   document how implementations satisfy those tests. The role of this 
   matrix will be to enumerate each feature of the XKMS protocol 
   and specify which features exist in which implementations 
   and whether interoperability has been demonstrated or not, as proof
   that we are satisfying the exit criteria.

Received on Tuesday, 9 December 2003 12:58:03 UTC