[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Issue 15, request IDs for synchronous requests...
Essentially, except I'm not sure about the attribute name 'asyncOperationID'. Again, I am leery about introducing new terms at this point. Also I don't think we should call something an "operation" that we call a "request" everywhere else. 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:52 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: Re: [provision] Issue 15, request IDs for synchronous requests... So, do we then agree to the following? - SpmlRequestType should still have (and perhaps require) requestID. - SpmlResponseType should still have (and perhaps require) requestID. - Add an optional xsd:ID attribute 'asyncOperationID' to SpmlResponseType (used when a provider executes a requested operation asychronously). - Add a required xsd:ID attribute 'asyncOperationID' to CancelRequestType. - Add a required xsd:ID attribute 'asyncOperationID' to StatusRequestType. Jeff Bohren wrote: >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. >> >> >> >> >> > > >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/provision/members/leave_wor kgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]