[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]