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



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]