Re: Moving to CR: proposed exit criteria, feastures at risk

Jose,

One minor nit with this.

You said:

"...one
complete implementation stands for both a client and a server
interoperable implementation"

But, for clarity, I'd prefer:

"one
complete implementation stands for both a client and a server
interoperable implementation (though the client and server
instances may in fact be separate implementations)"

Maybe it could be better worded, but I want to be able to
count cases where someone who implements a server or only
implements a client, e.g. if Foo only did a server and
Bar only did a client, I'd like the count the combination
of Foo and Bar as a "complete implementation".

That ok with you?
Stephen.

Jose Kahan wrote:
> 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 Wednesday, 10 December 2003 05:34:26 UTC