RE: [provision] Issue 15, request IDs for synchronous requests...

["Jeff Bohren" <jbohren@opennetwork.com>]

In SPML 1.0 the request ID of a status or cancel request served the dual
purpose of identifying the request and identifying the request to
statused or canceled (BTW, I am aware statused is not a real word). This
was done intentionally because no presented a use case that required
anything else. The assumption was that the status can cancel requests
are "second class" requests that can't be statused or canceled
themselves.

Revisiting this issue, I think perhaps the status and cancel requests
should have the own request ID. Not for the purposes of statusing
(another word that's not a real word) or canceling, but for out-of-band
usages such as auditing.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Wednesday, December 01, 2004 1:31 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Issue 15, request IDs for synchronous
requests...

Perhaps I misunderstood the purpose of the requestID attribute of 
SpmlRequestType.  I thought that this attribute allowed a requestor to 
specify an identifier for an asynchronous operation (as a holdover from 
SPML 1.0).

If the requestID attribute of SpmlRequestType is used for digitally 
signing the request, then
how does an instance of CancelRequestType specify the operation to
cancel?

If the "requestID" attribute identifies the request itself, then:
- SpmlRequestType should still have (and perhaps require) requestID.
- SpmlResponseType should still have (and perhaps require) requestID.
- Add an optional attribute 'asyncOperationID' to SpmlResponseType
   (used when a provider executes a requested operation asychronously).
- Add a required attribute 'asyncOperationID' to CancelRequestType and 
StatusRequestType.


Jeff Bohren wrote:

> Issue 15 reads:
>
>  
>
> 15.    Remove (optional) requestID from SpmlRequestType
>
>           and add (required) requestID to CancelRequestType
>
>           and add (required) requestID to StatusRequestType
>
>  
>
> Removing the request ID from the SpmlRequestType would have a huge 
> implication. First, this ID is also used for the purpose of digitally 
> signing the request, if that is desired. Second, the request ID may be

> needed for out-band-usage such as auditing and debugging. If anything 
> I would lean more towards making the request ID mandatory for every 
> request.
>
>  
>
> It also seems that status and cancel request could be improved by 
> having the ID of the request being statused or canceled as a sepparate

> ID. In otherwords one ID for the status request itself, and another ID

> for the request for which the status is being queired.
>
>  
>
> Regardless, I think this deserves some more discussion.
>
>  
>