Re: Issue + Proposal (Section 3.2.3)

Hi Matt,

That's all reasonable stuff, but I suspect that
there will be a subset of (signature checking) clients
who ask for x.509 certs and crls etc purely for auditing
purposes, but which (in the spirit of xkms) only actually
process the ds:keyValue.

Similarly, there'll be a class of encrypting clients
where the x.509 stuff is requested, but only so that
e.g. a CMS data structure can be totally filled-in.

In both cases (well, defo the 1st, the 2nd does have
a glitch wrt issuer/serial - maybe we ought define
a KeyInfo which contains just that?), the additional
RespondWith stuff is kind of optional and its fine
for the responder to not fail.

For a use case where the responder returns something
that wasn't requested, I guess the the auditing client
example works too, as would some types of key escrow
arrangement.

While you could handle all that with a SHOULD, it
seems to me that there are a sufficient number of
exceptional use cases that a MAY is better, but I
can take either if others in the WG prefer or else
just leave it up to the editor to do the right thing.

Cheers,
Stephen.

Matt Long wrote:
> Hi Stephen,
> 
>   
> 
> The reason I used SHOULD fault was that MAY means purely optional, whereas the 
> SHOULD allows the processor to not fault with the caveat that the processor 
> understands the implications of such.
> 
>  
> 
> It seems clear (to me at least) that if the sender encodes one or more 
> <RespondWith>s that the processor will return only the supported URI values that 
> are resolved in the message.  If the processor does not [resolve | support] any 
> of the URI values sent then fault; which includes caveat that if the processor 
> chooses not to fault, it accepts the implications of such.
> 
>  
> 
> I think that the SHOULD is may be more palatable because if the processor cannot 
> [resolve | support] any URI values sent via <RespondWith> and does respond 
> without fault, that means that the sender requested ‘Apples’ and the processor 
> sent ‘Oranges.’  This fact could present issues for a client. 
> 
> 
> Thoughts?
> 
> -Matt
> 
> --
> Matt Long
> MV Squared Technologies
> mlong@mvsquared.net
> 901-848-2640
> 
> 
>     --------- Original Message --------
>     From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>     To: "Matt Long" <mlong@mvsquared.net>
>     Cc: www-xkms@w3.org
>     Subject: Re: Issue + Proposal (Section 3.2.3)
>     Date: 07/06/05 03:47
> 
> 
> 
> 
>     Hi Matt,
> 
>     That looks just about fine to me. Only nit is that the
>     SHOULD fault is perhaps a little too strict and might
>     contradict the behaviour Tommy indicated in his earlier
>     email (As I read it he'll give back a ds:KeyValue if
>     he can, even if you asked for a beer in the RespondWith).
>     So I think I'd prefer a MAY fault.
> 
>     Regards,
>     Stephen.
> 
>     Matt Long wrote:
> 
>      > All,
>      > Issue, Proposal, and Justification for Section 3.2.3
>      >
>      > Issue: Section 3.2.3
>      > - Use of terms strings is semantically incorrect.
>      > - More RFC[2119] terminology needed for clarity.
>      > - More clarity needed with respect to which elements encode <RespondWith>
>      > - Faults conditions not specified.
>      >
>      > Proposed Text
>      > [102] The <RespondWith> element encoded in a request specifies one or more
>      > URI values that SHOULD resolve to data elements provided in either the
>      > [XML-SIG] <ds:KeyInfo> element or private key information defined in the
>      > section Cryptographic Algorithm Specific Parameters below. The
>      > <RespondWith> element MUST be encoded in requests of type LocateRequest,
>      > ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest,
>      > RecoverRequest. If the receiver does not support any of the <RespondWith>
>      > element URI values sent in the request or the specified request is not
>      > encoded with <RespondWith> the receiver SHOULD fault with either [XKMS
>      > Bindings 3.4.1] (5) or [XKMS Bindings 3.4.2] (5). The XML Signature
>      > elements are described here for convenience. The normative reference is the
>      > specification [XML-SIG].
>      >
>      > Justification:
>      > - Eliminates the term 'strings' where URI is required.
>      > - Explicity states which request types encoded <RespondWith>
>      > - Disambiguates the element's value as the identifier.
>      > - Makes normative the expected response of sending 'all' unresolvable URI
>      > values.
>      > - Makes normative the expected response of not encoding <RespondWith> with
>      > required request types.
>      > - Semantic modification clarifies ambiguities in schema.
>      >
>      >
>      > --
>      > Matt Long
>      > MV Squared Technologies
>      > mlong@mvsquared.net <mailto:mlong@mvsquared.net>
>      > 901-848-2640
>      >
>      > ________________________________________________
>      > Message sent using UebiMiau 2.7.2
>      >
>      >
>      >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ________________________________________________
> Message sent using UebiMiau 2.7.2

Received on Wednesday, 8 June 2005 09:21:35 UTC