- From: Tommy Lindberg <tommy.lindberg@gmail.com>
- Date: Mon, 23 May 2005 23:50:30 +0100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Matt Long <mlong@mvsquared.net>, www-xkms@w3.org
Hi Stephen - > - For the implementers - what does your code do if you > have no good value to include in the response element? RespondWith indicates what the client would prefer to see in the *KeyBinding. The *KeyBinding is only present in the result, if the request succeded. My interop configuration is: If the result contains a *KeyBinding I always include a ds:KeyValue, whether or not it was requested in a RespondWith - XKMS is key centric so I think this makes sense. In addition I include, as far as is possble, whatever artefacts are indicated by the RespondWith's. Regards Tommy On 5/23/05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > > Matt, > > I think that this is ok, but want to check that the MAY > is correct here. > > I guess, (without checking) that if a client includes > a RespondWith that a server SHOULD include a corresponding > element in the response, at least if it has a meaningful > value to place in the element. However, I could buy an > argument that MAY is right, since a server might want to > ignore such a value for some policy reason. > > So, two follow-ups: > > - Can anyone save me the trouble of checking through the > spec to verify whether MAY or SHOULD is right here? > - For the implementers - what does your code do if you > have no good value to include in the response element? > (E.g. Do you omit the element entirely, or include the > element, but without anything inside?) > > And lastly, this seems to be a case where we're adding > a new potentially testable assertion. I think that that > means that we just need to be careful to note that > the spec and test-spec get slightly out of whack at > the point where we include this change. I'm not > bothered that this happens, btw, since the test-spec > was for the PR transition which has happened already. > (At least I hope that that's ok according to the > w3c-process rules of the road;-) > > Stephen. > > Matt Long wrote: > > > Issue: Section 3.2.3 [1] > > - Use of terms strings is semantically incorrect. > > - More RFC[2119] terminology needed for clarity. > > > > Section 3.2.3 [102] states: > > "[102]The <RespondWith> element in the request specifies one or more > > strings included in the request that specify data elements to be > > provided in the <ds:Keyinfo> element of the response. Each string is a > > single identifier corresponding to a sub-element of the XML Signature > > Specification [XML-SIG] > > <http://www.w3.org/TR/xkms2/#XML-SIG#XML-SIG><ds:Keyinfo> element or > > the private key information defined in the section Cryptographic > > Algorithm Specific Parameters > > <http://www.w3.org/TR/xkms2/#privatekeyparameters#privatekeyparameters> > > below. The XML Signature elements are described here for convenience. > > The normative reference is the specification [XML-SIG]." > > > > Purposed Text: > > [102]The <RespondWith> element allows the sender of a request to specify > > which data elements MAY be provided in the <ds:KeyInfo> element in the > > response. One or more <RespondWith> elements MAY be included in a > > request where each <RespondWith> element URI value is an identifier than > > corresponds to either a sub-element of the XML Signature Specification > > [XML-SIG] <ds:KeyInfo> or the private key information defined in section > > Cryptographic Algorithm Specific Parameters below. The XML Signature > > elements are described here for convenience. The normative reference is > > the specification [XML-SIG]. > > > > Justification: > > (1)Eliminates the term 'strings' where URI is required. > > (2)Specifies 'MAY' for <ds:KeyInfo> sub-element response items, which is > > accurate. > > (3)Disambiguates the element's value as the identifier. > > > > > > > > -- > > Matt Long > > MV Squared Technologies > > mlong@mvsquared.net > > 901-848-2640 > > > > > > > > ________________________________________________ > > Message sent using UebiMiau 2.7.2 > >
Received on Monday, 23 May 2005 22:50:36 UTC