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... 

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.

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? 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). 

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, 21 May 2002 16:07:35 UTC