This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At several places in the Transfer spec the following redundant test appears: "As per the SOAP processing model, other specifications may introduce various types of extensions to the semantics of this message which are enabled through headers tagged with s:mustUnderstand="true". Such extensions may define how resource or subsets of it are to be retrieved or transformed prior to retrieval. Specifications which define such extensions MUST allow processing the basic Get request message without those extensions. Since the response may not be sent to the original sender, extension specifications should consider adding a corresponding SOAP header value in the response to signal to the receiver that the extension is being used. Implementations may respond with a fault message using the standard fault codes defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other components of the outline above are not further constrained by this specification." I believe that currently there is enough experience in the community that advising implementers how to compose specs at the SOAP level is no longer required. Also, this almost reads like advice on how implementers can circumvent the baseline semantics of the Transfer actions. Proposal: Remove this text where it appears in WS-Transfer (several places).
In section 3.1 Remove: "As per the SOAP processing model, other specifications may introduce various types of extensions to the semantics of this message which are enabled through headers tagged with s:mustUnderstand="true". Such extensions may define how resource or subsets of it are to be retrieved or transformed prior to retrieval. Specifications which define such extensions MUST allow processing the basic Get request message without those extensions. Since the response may not be sent to the original sender, extension specifications should consider adding a corresponding SOAP header value in the response to signal to the receiver that the extension is being used. Implementations may respond with a fault message using the standard fault codes defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other components of the outline above are not further constrained by this specification." In section 3.2 Remove: "As per the SOAP processing model, other specifications MAY introduce various types of extensions to this message which are enabled through headers tagged with s:mustUnderstand="true". Such extensions may require that a full or partial update should be accomplished using symbolic, instruction-based, or other methodologies. Extension specifications MAY also define extensions to the original Put request, enabled by OPTIONAL SOAP headers, which control the nature of the response, as discussed in remarks on the PutResponse below. Specifications which define any of these extensions MUST allow processing the Put message without such extensions. In addition to the standard fault codes defined in WS-Addressing, implementations MAY use the fault code wst:InvalidRepresentation if the presented representation is invalid for the target resource. See 5 Faults. Other components of the outline above are not further constrained by this specification." In section 4.1 Remove: "Extension specifications MAY define extensions to the original Create request, enabled by OPTIONAL header values, which specifically control the presence, absence, or format of the initial representation or other child elements in the CreateResponse. These headers MAY override the default behavior if they are marked with s:mustUnderstand="true". In the absence of such OPTIONAL headers, the behavior MUST be as described in the previous paragraphs. Since the response may not be sent to the original sender, extension specifications should consider adding a corresponding SOAP header value in the response to signal to the receiver that the extension is being used."
Please see an amended proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0005.html
Action-54 on Ram
Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0044.html
Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0059.html
resolved with comment #5