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] Pending / TryAgainLater


Anreas, Trevor, Pieter

Whilst asynchronous support may be generic, applicable to a range of
concrete profiles, it does not necessarily need to be part of the core.  It
should be possible to define an "abstract" profile for asynchronous
operation in the same way that the policy wise profile defines a set of
generic elements for handling signature policies.

I would prefer to have this as a separate package to the core to keep the
core implementation requirements as simple as possible.

Is there anyone (Andreas? Pieter?) interested in developing such an abstract
profile for asynchronous operation?  Would it be possible to sketch out how
this would operate to ensure that it does not have any impact on the core
before we progress it to CD?

Nick

> -----Original Message-----
> From: kuehneAtKlup@web.de [mailto:kuehneAtKlup@web.de]On Behalf Of
> Andreas Kuehne
> Sent: 07 April 2004 09:41
> To: TrevorPerrin
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Pending / TryAgainLater
>
>
> Hi Trevor !
>
> > Another possibility is to have a single, separate Async Profile.  This
> > would make it clear what the approved way of doing asychronous
> operation
> > is, hopefully avoiding the confusion you mention.
> Do you think of another horizontal profile ?
> Is there demand for several protocol styles  ( XKMS style, home
> grown, ... ) ?
>
> Anyway, the GermanSig profile badly needs asychronous replies !
> In the worst scenario every signing request has to be commited by
> the signature holder explicitly. In the best ( signature law
> compliant ) scenario the certificate holders has a time slot

> usually several hours ) for inspecting the signing request and
> possible rejecting the request. So for sure request processing
> takes hours --> requests have to be processed asynchronously !
>
> Iirc 'asynchronous request' was on our initial requirement list.
> Blame it on me that I didn't track this requirement and now come
> up with a 'must have'  ...
>
>
> > But by keeping it out of the core, we would keep the core smaller and
> > easier to implement in its entirety.
> Sure ! But on the other hand 'asynchronous requests' seem to be a
> generic mechanism valid to be part of the core !
>
> Greetings
>
> Andreas
> _____________________________________________________________________
> Der WEB.DE Virenschutz schuetzt Ihr Postfach vor dem Wurm Netsky.A-P!
> Kostenfrei fuer alle FreeMail Nutzer. http://f.web.de/?mc=021157
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
> kgroup.php.
>
>
>




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