W3C home > Mailing lists > Public > www-xkms@w3.org > May 2005

Fwd: Semantic Nit -2

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Tue, 24 May 2005 08:32:50 +0100
Message-ID: <18ec59cc0505240032c19918e@mail.gmail.com>
To: www-xkms@w3.org

Sending [edited] bounced e-mail.

---------- Forwarded message ----------
From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: May 24, 2005 8:21 AM
Subject: Re: Semantic Nit -2
To: Matt Long <mlong@mvsquared.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "www-xkms@w3.org"


On the other hand, if the RespondWith is valid and I don't support it [I
believe] I ignore it and the result will end up having a single
ds:KeyValue.

Regards
Tommy

On 5/24/05, Tommy Lindberg <tommy.lindberg@gmail.com> wrote:
> Hi Matt -
>
> In my case an error/fault is produced. I check the RespondWith values
> against the set of defined RespondWithOpenEnum values in the schema as
> if the anyURI was not part of the union.
>
> Regards
> Tommy
>
> On 5/23/05, Matt Long <mlong@mvsquared.net> wrote:
> > Hi Tommy,
> >
> > Scenario:
> > Sender request encodes a single <RespondWith> identifier that cannot be
> > processed by the receiver.  What should be the response *or* fault.
> >
> >
> > Thx,
> >
> > -Matt
> >
> >
> >
> >
> >
> > --------- Original Message --------
> > From: "Tommy Lindberg" <tommy.lindberg@gmail.com>
> > To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
> > Cc: "Matt Long" <mlong@mvsquared.net>, www-xkms@w3.org
> > Subject: Re: Semantic Nit -2
> > Date: 23/05/05 16:47
> >
> >
> > 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
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >  ________________________________________________
> >
> >  Message sent using UebiMiau 2.7.2
> >
>
Received on Tuesday, 24 May 2005 07:32:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:44 UTC