RE: Locate/Validate Requests for Multiple Keys

Joseph,

My apologies for the very tardy response to this.  Some answers, or at
least my opinions, in-line.

Blair

> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org] 
> Sent: Tuesday, May 21, 2002 1:08 PM
> To: Blair Dillaway; www-xkms@w3.org
> Subject: Re: Locate/Validate Requests for Multiple Keys
> 
> 
> Hi Blair,
> 
> I think issue #2 and #3 are related. I'm presently unclear 
> about what the 
> status and result codes each apply to, and if we address 
> multiple queries, 
> we then need figure out which applies to which, if we want to 
> use them to 
> determine the result... 

If we follow the existing XKMS interface definition, the ResultCode
applies to the entire response message.  Status codes only appear in the
KeyBinding element and apply to only that KeyBinding.  With the
ResultCode, one can basically indicate if the response completely
satisfies the result, partially satisfies the request, or the service
can't provide any information.  This applies to both Locate and
Validate.  With Validate one can also make a status assertion about each
individual KeyBinding.  I believe this is adequate for most use cases.


> 
> With respect to presumed matching, I'm still not sure about our query 
> response model. If I send a request and there's no match, do 
> I get an empty 
> KeyInfo back with a Success? Or no KeyInfo with a Success -- 
> or incomplete. 
> That would affect how one matches those things up.

Following the existing model, if the service can't locate information
that matches the request it would return the ResultMajor=Success,
ResultMinor=NoMatch ResultCode.  A KeyInfo(Locate) or
KeyBinding(Validate) would not appear since the result messages allow
zero or more of these elements to be returned.

> 
> With respect to the sequencing... Are we even sure that separate XKMS 
> requests messages are ordered? For instance, if I send off 
> request 1,2, and 
> 3 as separate messages, and get three responses back, how do 
> I know which 
> corresponds to which? 

XKMS has always been defined as a request-response protocol with the
implicit understanding that the client can match the response received
to the correct request.  I believe the defacto assumption was that the
transport will provide this functionality (at least it was mine).
Perhaps we should be explicit somewhere in the spec?  When using SOAP
over HTTP, the HTTP stack just takes care of it for you.

Your sequences seem to be qualifications in the 
> context of a request (which is globally unique somehow), 
> would that be good 
> enough? (Does that uniquely identify a given request+query 
> amongst all 
> possible ones returning?)  If I have a real UID for each 
> request, that 
> helps in the both cases (sending multiple requests/queries 
> and a single 
> request with multiple queries). 

The simple ID tagging proposal I made is only useful if one can insure
that requests and responses are correctly matched.

> 
> I think what you outline is achievable (though I leave it to other 
> implementors to say whether they face that demand) but I'm 
> still muddled 
> enough on the spec that I'm not sure how one would achieve 
> it. (Again, my 
> impulse is to argue that the  request/query be 
> separated/cleaned-up and we 
> look to other query/directory services for guidance as to how they 
> approached this problem.)
> 
> On Monday 06 May 2002 17:49, Blair Dillaway wrote:
> > Issue #2 - If one asks for information about 'N' keys the 
> service will 
> > likely respond with 'R' KeyInfo structures (where R >= N).  
> This begs 
> > the question as to how the client knows which KeyInfos in 
> the response 
> > correspond to the KeyInfos in the request.  I do not 
> believe this is a 
> > new issue.  The client already must be prepared to deal 
> with multiple 
> > responses and be able to parse these to determine which is 
> appropriate 
> > to its needs.
> >
> > The only difference is that they must now parse these to 
> match up the 
> > returned KeyInfos against multiple keys in the request.  This seems 
> > like a trivial pattern matching problem between the request and 
> > response KeyInfos.  Using the above example, this amounts 
> to matching 
> > KeyName values.  If others feel this is inadequate, then I 
> suggest we 
> > introduce a new child element of KeyInfo to provide a 
> locally unique 
> > Request Sequence Number (e.g., 
> > <xkms:RequestSeqNum>1</xkms:RequestSeqNum>).  The client 
> would simply 
> > tag each KeyInfo in the Request with an integer unique to that 
> > request, the service would return this value in each corresponding 
> > response KeyInfo
> >
> > Issue #3 - If we allow requests for info about multiple 
> keys how do we 
> > indicate when some, but not all, can be satisfied.  I believe our 
> > result codes are already adequate for this and suggest a 
> ResultMajor = 
> > Success combined with ResultMinor=Incomplete be used to 
> indicate the 
> > partial satisfaction case.
>

Received on Tuesday, 18 June 2002 20:04:40 UTC