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 > 901-848-2640 > > ________________________________________________ > Message sent using UebiMiau 2.7.2 > > >Received on Tuesday, 7 June 2005 09:50:04 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2007 14:31:04 GMT