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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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


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



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