[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] [Fwd: Async comments by Tommy]
Hi Nick,
closely related to the response ID issue there is another problem Tommy
pointed at regarding the return type of an unidentified request. Here I
see the need to add a more abstract return type. This will be the parent
type type to the current *Response types.
I'll try to get out a proposal during this week.
Greetings
Andreas
>Andreas, Tommy and all DSS
>
>Following on from the issue raised by Tommy some time ago suggesting adding
>an optional response ID to the SignResponse and VerifyResponse in support of
>asynchronous operation.
>
>Is there any objection for inclusion of this change in the next draft of the
>CD for confirmation at the next meeting?
>
>Nick
>
>
>
>>-----Original Message-----
>>From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
>>Sent: 24 July 2005 17:18
>>To: kuehne@klup.de
>>Cc: dss@lists.oasis-open.org
>>Subject: Re: [dss] [Fwd: Async comments by Tommy]
>>
>>
>>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
>>
>>
>>
>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail. You may a link to this group and all your
>>TCs in OASIS
>>at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail. You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]