[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Issue 15, request IDs for synchronous requests...
I'm open to a different term if you have a better one, but the request is not the same thing as the operation. Throughout the specification the term "operation" refers to what the provider actually does. A request describes an operation the provider is to perform. The provider's response contains one of the following: - an error if the result is "failure" - output (or "optional content") if the result is "success" - a requestID (or now 'asyncOperationID') if the result is "pending' A provider returns a synchronous response for each request. The synchronous response to a request for an operation that the provider will execute asynchronously contains a requestID (or now 'asyncOperationID') that the requestor can use to cancel or obtain the status of an operation that a provider executing asynchronously. Since the request and response can be separated from the function that the provider is performing (because of the request), we need a term for the function that the provider is performing. The function that the provider is performing is the "operation". gpc Jeff Bohren wrote: >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. > > >> >> >> >> > > > >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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]