This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6730 - Transfer: Redundant SOAP Processing Advice
Summary: Transfer: Redundant SOAP Processing Advice
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Transfer (show other bugs)
Version: FPWD
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: David Snelling
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on:
Blocks:
 
Reported: 2009-03-24 09:09 UTC by David Snelling
Modified: 2009-05-27 04:00 UTC (History)
2 users (show)

See Also:


Attachments

Description David Snelling 2009-03-24 09:09:47 UTC
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).
Comment 1 David Snelling 2009-03-31 20:21:21 UTC
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."

Comment 2 Ram Jeyaraman 2009-04-02 01:46:59 UTC
Please see an amended proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0005.html
Comment 3 Robert Freund 2009-04-08 11:57:14 UTC
Action-54 on Ram
Comment 6 Robert Freund 2009-04-14 19:47:28 UTC
resolved with comment #5