Re: [dss] [Fwd: Async comments by Tommy]

[Tommy Lindberg <tommy.lindberg@gmail.com>]

Hi Andreas -

Thanks for your reply.

No I didnt mean to remove the RequestID in either request nor response
- I simply meant adding a ResponseID to the response.

(I am on hollidays; back next weekend.)

Regards
Tommy

On 7/18/05, Andreas Kuehne <kuehne@klup.de> wrote:
> Hi Tommy ! 
> I wouldn't mind to widen the core functionality, but you are manadating
> to
narrow the functionality. 
 
> Sorry, I don't understand the second part.

 
> I understand you want to leave out  the client-generated-request-id in
> favour of server-generated-request-id. I see that the client-generated
> approach introduces some problems but I wouldn't want to remove this from
> the core. It's in there right from the start ...
> 
> But I don't mind to add the server-generated id as an useful option.
> 
> Greetings
> 
> Andreas
> 
> 
> 
> Regards,
Tommy

On 7/12/05, Andreas Kuehne <kuehne@klup.de> wrote:
 
> 

---------- Forwarded message ----------
From: Andreas Kuehne
> <akuehne@yahoo.com>
To: Nick Pope <pope@secstan.com>, Tommy Lindberg
> <tommy.lindberg@gmail.com>, kuehne@klup.de
Date: Tue, 12 Jul 2005 05:39:15
> -0700 (PDT)
Subject: Async comments by Tommy
Hi Tommy, hi Nick,

currently I
> am out of reach of my OASIS-licensed mail account. But I don't let more time
> pass by
... I'll submit this to the list tonight.


 
> 1)
For service endpoints that support both the Sign and the
> Verify
protocol's there is no "general purpose" Response element
available
> that can be used as a response in situations where
an unknown request id
> received in a PendingRequest. I.e. an unknown
request id corresponds to
> neither a (previously received) Sign nor Verify
request.

I think DSS (and
> its profiles) would benefit from a <Response> element that
could be used in
> situations like this. This could be implemented
by refactoring the Core
> schema through introduction of a common ancestor
element to SignResponse and
> VerifyResponse and pulling up common information
items. This is identical to
> XKMS from which this profile borrows.
 
> Yes, you are right. It's a problem not limited to the Async profile. But
> working on the Async I
felt the need for a more abstract
> 'request'/'response' objects. But after a short discussion (
iirc with
> Trevor and Ed ) we concluded to leave the core as it is for the sake of
> clear
structures.

But indeed you brought up a good argument ! In case of a
> poll request with an unknown id you may
choose a response type unexpected by
> the client.

I would second an approach of moving up the common parts of the
> different responses to a common
base object. Let's discuss this on the list
> !

 
> 2)
The Asynchronous Processing profile requires the service to index
> responses
*client* generates; the RequestID. I would be in favor of letting
> the
*service*
generate the quantity that it, itself, subsequently uses for
> lookups. This
would ensure that the properties of this quantity suit the
> service,
e.g. constant length, uniqueness, adequate randomness, etc. It
> would also alleviate the
need for request-id collision detection and
> reporting.

This would also require a change in the core schema, allowing an
> additional
optional attribute in the {Sign, Verify}Response that would carry
> a response
id, the use of which the asynchronous profile would mandate.
> Again, this
is identical to XKMS.
 
> Yes, I see the problem, too. But it's the same excuse : I wanted to use the
> mechanism already
defined in the core. I wouldn't mind to widen the core
> functionality, but you are manadating to
narrow the functionality. Let's
> take this to the list, too.

Greetings

Andreas

 
> 
>