This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WS-Transfer does not define the 'safe' or 'idempotent' properties of the "verbs". Whils in HTTP is it safe to reissue a GET or a HEAD as no side effects are expected, WS-T doesn't say a word about reissuing a WS-T GET when something happens (like at the underlying transport level).
(form msg: <http://www.w3.org/mid/Pine.LNX.4.64.0903030824290.23599@ubzre.j3.bet> ) The proposal is as follows, 1/ add a paragraph to explain what 'safe' and 'idempotent' means, and the impact on operations (like being able to redo a request when there is a failure at the underlying protocol level, or using a timeout when that information is not available, like UDP packets). The text might reference http://tools.ietf.org/html/rfc2616#section-9.1 directly or even http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-01 or we can come up with our own definitions if needed (that is the main point of discussion I guess). 2/ for each resource operation, add a small table with the safeness and idempotent properties (and this table would also act as a short summary for each paragrahp, so include the values of /s:Envelope/s:Header/wsa:Action, for example). [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6533
proposal on 2009-03-03 at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0006.html
Action-45 on Yves approach is fine, looking for red-line text
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0040.html In "Resource Operation" Add a paragraph names "Safeness of Operations" with the following text. [[ Safe operations means that the action executed on behalf of the user or service requesting the operation will not result in any side effect imputable to the requester. It means that in case of an underlying protocol error that might get unnoticed, resending the same request can be done automatically. Only [ref to Get] Get is defined as a safe operation. ]] We could add that resending the request makes no implication in getting back the same response as time has changed (like "Get the current time")
Action-98 on Yves
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0082.html << The text in WS-T should stay the same (see [1]) However, each operation should state explicitely that it is safe or not, so for wst:Get [ This operation is safe [ref Safeness of Operations]. ] (a) [ This operation is NOT safe [ref wst:Safeness of Operations]. ] (b) * in RT, no new operations are definet (just wst:Get extended but with no semantic change). * in MEX After the first paragraph of 'GetMetadata', add (a) * in Eventing After the first example in 'Subscribe', add (b) After the first sentence in 'Renew', add (b) After the first example in 'GetStatus', add (a) After the first sentence in 'Unsubscribe', add (b) * in Enumeration After the first paragraph in 'Enumerate', add (b) After the first example in 'Pull', add (b) After the first sentence in 'Renew', add (b) After the first example in 'GetStatus', add (a) After the first example in 'Release', add (b) [1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0040.html >>
2009-09-01 resolved with comments #4 and #6
> Yves, > For the one operation in each spec that has been deemed 'safe', I was > thinking of just adding this text after the definition of the operation: > > This operation will not result in any side effect imputable to the > requester. This means that in case of an underlying protocol error that > might get unnoticed, resending the same request can be done automatically. > > Does this work for you? Yes, with a minor modification, can we say "This operation is safe; It will not result in..." ? (ie: I'd like to keep the 'safe' in the text somewhere)