OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Andreas -

I haven't looked at it in detail yet but I can see that you have introduced abstract ancestors for both requests and responses - doing the request as well, is a nice touch providing symmetry.

However, what I meant in my note was that there should be a *concrete* <Response> element and that  <SignResponse> and <VerifyResponse> should be extended from that concrete element.

The additional attribute ResponseID should be an optional attribute to the <Response> element.

Regards,
Tommy

On 9/26/05, Nick Pope <pope@secstan.com> wrote:
Andreas,

I understand that this change addresses Tommy's first comment about there
being a common ancestor type for request & response.

Unless I have missed it, I think there is still need to reflect the second
comment about having an optional response ID.

Would it be possible to identify the specific changes made.

Nick

> -----Original Message-----
> From: Andreas Kuehne [mailto: kuehne@klup.de]
> Sent: 25 September 2005 19:48
> To: Nick Pope
> Cc: Tommy Lindberg; dss@lists.oasis-open.org
> Subject: Re: [dss] [Fwd: Async comments by Tommy]
>
>
> Hi all,
>
> as I proposed some days ago here are my extensions of the core schema.
> It's fueled by the shortcomings in the Async profile identified by Tommy.
>
> Now there are new bases type for sign/verify requests and responses.
> This abstraction layer shouldn't any bad impact on other structures.
>
> Please have a sharp look ...
>
> Greetings
>
> Andreeas
>
> >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
> >
> >
>
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]