RE: [dss] Pending / TryAgainLater

[Pieter Kasselman <PKasselman@betrusted.com>]

Title: RE: [dss] Pending / TryAgainLater

Hi Trevor

Whether it makes sense to split async support between the core and the profiles is a good question. Having looked at this from various angles, the more I think about it, the more convinced I am that async support must be in the core and not in a profile at all. By splitting and delegating async support to a profile we introduce the risk that different profiles will have different levels of sophistication in dealing with async processing of requests, resulting in different implementations which in turn becomes unproductive. In addition there is no guarantee that a future core specification will adopt the proposed async mechanisms from the profiles. If there is more than one async mechanism, which one will be chosen for inclusion in the core?

As a consequence the right approach here may in fact be to drop async support from the code-signing profile and leave it to the core specification to define this (either now or in the future). I do think this will severely curtail the usefulness of the code-signing profile (and perhaps others as well). Are there any other profiles that require async processing? Note that I am not saying that async support is not important, but instead that it is probably too important to leave to a profile. Any other views on this?

Cheers

Pieter

-----Original Message-----
From:   Trevor Perrin [SMTP:trevp@trevp.net]
Sent:   05 April 2004 23:15
To:     dss@lists.oasis-open.org
Subject:        [dss] Pending / TryAgainLater




While updating the core draft, I thought more about our resolution to add
an additional "Pending" ResultMajor code, and I'm not sure this is the best
approach.

It doesn't make much sense to put only a fraction of the needed
functionality for asynch behavior in the core.  "TryAgainLater" was generic
enough that we could sorta justify it, but if we're going to add an
additional code whose sole use is for asynchronous interaction, then I
would prefer changing the core to allow profiles to introduce new
ResultMajor codes.

So how would people feel if draft 19 removes TryAgainLater, and allows
profiles to define their own ResultMajor codes?




Trevor




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