Re: Ambiguity in the interpretation of [Optional] in XKMS

IMO, a client/server implementation should not choke when it receives a 
message with optional elements that it does not support. The server can 
generate an error while the client can deduce that it has not been 
correctly configured to talk to the server. IMO, this behavior is 
consistent with wire level interoperability.

Making elements optional/required/recommended is really about trying to 
get XKMS services/applications to interoperate, which is a more than 
just specifying the elements that need to be present in an XKMS message.

- Vamsi

Jose Kahan wrote:
> After some thought and analysis, my feeling is that XKMS has
> an ambiguous use of the term [Optional] when referring to
> elements and attributes.
> 
> The interpretations that this term can have here are:
> 
> - An element or attribute that a client or a server may
>   choose to include in a message.
> - Implementation of a given element or attribute is 
>   required/recommended/optional
> 
> The point I want to make here is that we may have an optional 
> element, but whose implementation is required by a server.  If the
> implementation is optional, the server may then decide to ignore
> it. However, it should not ignore it if the implementation is required.
> 
> In few cases, the spec actually says that the implementation is optional. 
> Most of the time it just says optional and it lets the reader the guesswork
> as to whether the inclusion of the element/attribute or its support by a
> client/server is optional.
> 
> In my opinion, this is is a source of confusion and of potential
> interoperability problems. The spec should be more precise here, while
> still leaving freedom of choice to the user.
> 
> You'll find here below a list of all the elements and attributes 
> that are optional.  I think it would really be good to have 
> some extra text that says if their implementation is optional,
> recommended or required. We could add this as an appendix too.
> 
> Thoughts?
> 
> -jose
> 
> [88] MessageAbstractType
> 
> <ds:Signature> [Optional]
> <OpaqueClientData>[Optional]
> Nonce [Optional]
> 
> [97] RequestAbstractType
> 
> <PendingNotification> [Optional]
> OriginalRequestId [Optional]
> ResponseLimit [Optional]
> 
> [114] <Result>
> <RequestSignatureValue> [Optional]
> ResultMinor [Optional]
> RequestId [Optional]
> 
> [134] <StatusResult>
> Success [Optional]
> Failed [Optional]
> Pending [Optional]
> 
> [172]  KeyBindingAbstractType
> 
> Id [Optional]
> <ds:KeyInfo>  [Optional]
> 
> [189]  <UnverifiedKeyBinding>
> 
> ValidityInterval> [Optional]
> 
> [191]  <ValidityInterval>
> 
> NotBefore     [Optional]
> NotOnOrAfter     [Optional]
> 
> [213]  <QueryKeyBinding>
> 
> <TimeInstant> [Optional]
> 
> [282]  <PrototypeKeyBinding>
> 
> <ValidityInterval> [Optional]
> <RevocationCodeIdentifier> [Optional]
> 
> [291] <Authentication>
> 
> KeyBindingAuthentication>     [Optional]
> <NotBoundAuthentication>    [Optional]
> 
> [311]  <RegisterRequest>
> 
> <ProofOfPossesion>     [Optional]
> 
> [313]  <RegisterResult>
> 
> <PrivateKey>     [Optional]
> 
> [315]  <ReissueRequest>
> 
> <ProofOfPossesion>     [Optional]
> 
> [325]  <RecoverResult>
> 
> <PrivateKey>    [Optional]
>

Received on Thursday, 3 March 2005 21:15:23 UTC