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-Management v1.1 [1] Section 6.5 defines a mechanism wherein, if an operation causes the EPR of a resource to change, the new EPR can be returned to the requester. This is useful in environments in which the value of the EPR is derived from attributes that are themselves modifiable by wst:Put operations. Without getting into whether or not deriving an EPR from modifiable attributes is, in general, a good idea, we have to accept that there are systems in which, architecturally, the costs of allowing this are less than the costs of not allowing this. The WS-Man WG requests that the WS-RA WG include this extension an as optional feature of WS-Transfer. [1] http://www.dmtf.org/standards/published_documents/DSP0226_1.1.pdf --- Proposal: Although WS-Management defines RequestEPR as a general purpose feature, this proposal narrows its application to the wst:Put/wst:PutResponse message exchange. 1. Modify the wst:PutResponse message to have the following form: [Action] http://www.w3.org/2002/ws/ra/edcopies/ws-tra/PutResponse [Body] <wst:PutResponse ...> <wst:Representation ...> xs:any? </wst:Representation>? <wst:ResourceChanged> <wsa:EndpointReference> wsa:EndpointReferenceType </wsa:EndpointReference> | <wst:EPRInvalid/> | <wst:EPRUnknown/> </wst:ResourceChanged>? xs:any* </wst:PutResponse> 2. Add language to the description of PutResponse that says, effectively, When a service detects that a successful Put operation has changed the EPR of the resource it MUST include the wst:ResourceChanged element in the PutResponse. 3. Define the wst:ResourceChanged element using language similar to the definition of wsman:RequestedEPR in Section 6.5 of WS-Man.
Closed with no action
Tom Rutt to write response
Proposed Response to Originator of Bug 9607 The WS-RA WG have reviewed your review comment 9607, Transfer: Support for WS-Management's RequestEPR feature, and have decided to close with no change. Our rationale is as follows: This is a broader issue, in that it affects more that ws-transfer Put. There are several operations over a network which could also result in such an EPR Change - as such this an issue that is bigger than what WSRA is chartered to work on. For example, if a transfer put induced state change on a resource results it a change of its epr, then that same epr might change due to state changes due to other stimuli associated with the resource. In such an environment, we suggest that using an specific event report notification, perhaps defined as part of WS-Management, such as "state change induced EPR change" , would be a better solution. Using a notification would allow all parties which need to track EPR changes to register for receiving that event report.
Reviewer satisfied http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0056.html