RE: Text for issue 300/359

Glen, all,

I took an action item to provide some tweaks to Glen's proposal. The
proposal tries to take into account that it is not just the media type
that is different between the SOAP protocol bindings for 1.1 and 1.2 but
also the use of the SOAPAction HTTP header field etc. This is done by
referring to the bindings in general rather than pointing out particular
differences.

The complete proposal for issue 300 is as follows:

In Part 1, Appendix A, second sub-bullet of list item 2:

<OriginalPart1>
MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message
construct following SOAP/1.1 semantics.
</OriginalPart1>

Add a sentence so that it says:

<ProposalPart1>
MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message
construct following SOAP/1.1 semantics based on a SOAP/1.1 message
construct following SOAP/1.1 semantics using a SOAP/1.1 binding to the
underlying protocol.
</Proposalpart1>

In Part 1, Appendix A, the last note:

<OriginalPart2>
Note: Note that existing SOAP/1.1 nodes are not likely to indicate which
envelope versions they support using the Upgrade element information
item. If nothing is indicated then this means that SOAP/1.1 is the only
supported envelope.
</OriginalPart2>

Rewrite the note to contain two notes saying the following:

<ProposalPart2>
Note: SOAP nodes wishing to support both SOAP/1.1 and SOAP Version 1.2
are required to use a protocol binding associated with the appropriate
version of SOAP.

Note: An existing SOAP/1.1 node generating a version mismatch SOAP fault
is not likely to indicate which versions it supports using the Upgrade
element information item. If nothing is indicated then this means that
SOAP/1.1 is the only supported version. Note, however that
incompatibilities between underlying protocol bindings might prevent a
SOAP/1.1 node from generating a version mismatch SOAP fault when
receiving a SOAP Version 1.2 message. For instance, a SOAP/1.1 node
supporting the SOAP/1.1 HTTP binding [ref] receiving a SOAP Version 1.2
message using the SOAP 1.2 HTTP protocol binding [ref] might not
understand the difference between the two bindings and generate an HTTP
specific response as a result.
</ProposalPart2>

Comments?

Henrik

>In Part 1, Appendix A, change "Note" to "Notes" and insert the 
>following text before the existing note:
>
><insertedText>
>Note that there may well be transport binding mismatches in 
>either of these situations, which may prevent the nodes from 
>even processing a message.  For instance, the SOAP 1.1[link] 
>HTTP binding requires a content-type of "text/xml", whereas 
>the SOAP 1.2 HTTP binding[link] specifies 
>"application/soap+xml". If a SOAP 1.1 node receives a typical 
>SOAP 1.2 HTTP message, it will not recognize it due to the 
>content-type mismatch.  Therefore, SOAP 1.1 nodes which wish 
>to respond with an upgrade fault (rather than a binding-level 
>fault) over HTTP must be modified to accept the SOAP 1.2 content-type.
>
>SOAP 1.2 nodes wishing to either provide SOAP 1.1 
>functionality OR to respond to SOAP 1.1 messages with an 
>upgrade fault must respect the appropriate SOAP 1.1 transport 
>bindings.  For example, in the HTTP case, SOAP 1.2 nodes must 
>accept HTTP messages with content-type "text/xml" for purposes 
>of SOAP 1.1 processing or faulting. </insertedText>

Received on Monday, 28 October 2002 00:46:18 UTC