2.1.1 Edge labels

An edge label is an XML qualified name. Two edge labels are equal if and only if their XML expanded names are equal. I.e. both of the following are true:

1. Their local name values are the same.

2. Either of the following is true:

   1. Both of their namespace name values are missing.

   2. Their namespace name values are both present and are both the same.

See2.3 Values for uses of edge labels and position to distinguish the members of encoded values, and XML Schema[XML Schema Part 2] for more information about comparing XML qualified names.

2.2.1 Single and Multi Reference Nodes

A graph node may besingle reference ormulti reference. A single reference graph node has a single inbound edge. A multi reference graph node has multiple inbound edges.

3.1.1 Encoding Graph Edges and Nodes

Each graph edge is encoded as anelement information item and eachelement information item represents a graph edge.3.1.3 Encoding Compound Values describes the relationship between edge labels and the [local name] and [namespace name] properties of suchelement information items.

The graph node at which an edge terminates is determined by examination of the serialized XML as follows:

1. If theelement information item representing the edge does not have arefattribute information item (see3.1.5.2 ref Attribute Information Item) among its attributes then thatelement information item is said torepresent a node in the graph and the edge terminates at that node. In such cases theelement information item represents both a graph edge and a graph node

2. If theelement information item representing the edge does have arefattribute information item (see3.1.5.2 ref Attribute Information Item) among its attributes, then the value of thatattribute information item MUST be identical to the value of exactly oneidattribute information item ( see3.1.5.1 id Attribute Information Item) in the same envelope. In this case the edge terminates at the graph node represented by theelement information item on which theidattribute information item appears. Thatelement information item MUST be in the scope of anencodingStyle attribute with a value of "http://www.w3.org/2003/05/soap-encoding" (see SOAP 1.2 Part 1[SOAP Part 1],SOAP encodingStyle Attribute).

All nodes in the graph are encoded as described in 1 above. Additional inbound edges for multi reference graph nodes are encoded as described in 2 above.

3.1.2 Encoding Simple Values

The lexical value of a graph node representing a simple value is the sequence of Unicode characters identified by thecharacter information item children of theelement information item representing that node. Theelement information item representing a simple value node MAY have among its attributes a 'nodeType'attribute information item (see3.1.7 nodeType Attribute Information Item). Note that certain Unicode characters cannot be represented in XML (see XML 1.0[XML 1.0]).

3.1.3 Encoding Compound Values

An outbound edge of a graph node is encoded as anelement information item child of theelement information item that represents the node (see3.1.1 Encoding Graph Edges and Nodes). Particular rules apply depending on what kind of compound value the graph node represents. These rules are as follows:

1. For a graph edge which is distinguished by label, the [local name] and [namespace name] properties of the childelement information item together determine the value of the edge label.

2. For a graph edge which is distinguished by position:

   • The ordinal position of the graph edge corresponds to the position of the childelement information item relative to its siblings

   • The [local name] and [namespace name] properties of the childelement information item are not significant.

3. The element information item representing a compound value node MAY have among its attributes anodeTypeattribute information item (see3.1.7 nodeType Attribute Information Item).

4. The following rules apply to the encoding of a graph node that represents an "array":

   • Theelement information item representing an array node MAY have among its attributes anitemTypeattribute information item (see3.1.4.1 itemType Attribute Information Item).

   • Theelement information item representing an array node MAY have among its attributes anarraySizeattribute information item (see3.1.6 arraySize Attribute Information Item).

5. If a graph edge does not terminate in a graph node then it can either be omitted from the serialization or it can be encoded as anelement information item with anxsi:nilattribute information item whose value is "true".

3.1.4 Computing the Type Name Property

The type name property of a graph node is a {namespace name,local name} pair computed as follows:

1. If theelement information item representing thegraph node has anxsi:typeattributeinformation item among its attributes then the type name property of thegraph node is the value of thexsi:typeattributeinformation item.

   Note:

   This attribute is of typexs:QName (see XML Schema[XML Schema Part 2]); its value consists of the pair {namespace name, local name}. Neither the prefix used toconstruct the QName nor any information relating to anydefinition of the type is considered to be part of thevalue. The SOAP graph carries only the qualified name of thetype.

2. Otherwise if the parentelement information item of theelement information item representing the graphnode has anenc:itemTypeattributeinformation item (see3.1.4.1 itemType Attribute Information Item)among its attributes then the typename property of the graph node is the value of theenc:itemTypeattribute information item

3. Otherwise the value of the type name property of the graphnode is unspecified.

3.1.5 Unique identifiers

3.1.6 arraySize Attribute Information Item

ThearraySizeattribute information item has the following Infoset properties:

• A [local name] ofarraySize .

• A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".

The type of thearraySizeattribute information item isenc:arraySize. The value of thearraySizeattribute information item MUST conform to the following EBNF grammar

The array's dimensions are represented by each item in the list of sizes (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list. The default value of thearraySizeattribute information item is "*", that is by default arrays are considered to have a single dimension of unspecified size.

3.1.7 nodeType Attribute Information Item

ThenodeTypeattribute information item has the following Infoset properties:

• A [local name] ofnodeType .

• A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".

• A [specified] property with a value of "true".

The type of thenodeTypeattribute information item isenc:nodeType.

The value of thenodeTypeattribute information item MUST, if present, be one of the strings "simple" or "struct" or "array". The value indicates what kind of a value this node represents - a simple value, a compound struct value or a compound array value respectively.

4.1.1 Identification of RPC Resources

The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to procedures, or in the names of those procedures. For example, the call:

updateQuantityInStock(PartNumber="123", NewQuantity="200")

suggests that the resource to beupdated is theQuantityInStock forPartNumber "123".Accordingly, when mapping toor from a programming language method or procedure call, any arguments that serve to identify resources(such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed. When mapping to or from a programming language method or procedure call, the name of whichidentifies or qualifies the identification of a resource (such as QuantityInStock above), such naming orqualification should when practical be represented in the URI to which the SOAP message is addressed.No standard means of representation of arguments or method names is provided by this specification.

4.1.2 Distinguishing Resource Retrievals from other RPCs

The World Wide Web depends on mechanisms that optimize commonly performed information retrievaltasks. Specifically, protocols such as HTTP[RFC 2616] provide a GET method which is used to perform saferetrievals, i.e. to perform retrievals that are idempotent, free of side effects, and for which security considerations do notpreclude the use of cached results or URI-based resource identification.

Certain procedure or method calls represent requests for information retrieval. For example, the call:

getQuantityInStock(PartNumber="123")

might be used to retrieve the quantity established inthe example above.

The following conventions can be employed to implement SOAP retrievals and otherRPCs on the Web:

• The conventions described in4.1.1 Identification of RPC Resources are used to identify theresource with a URI.

• In cases where all the arguments have been represented in the URI,no SOAP header blocks are to be transmitted and the operation is a saferetrieval, the6.4 SOAP Web Method Feature and the6.3 SOAP Response Message Exchange Pattern are used. Accordingly, no SOAP envelope istransmitted for the request, and thehttp://www.w3.org/2003/05/soap/features/web-method/Method property is set to "GET". The results of the retrievalare a SOAP RPC response as described in4.2.2 RPC Response

• In cases where the operation to be performed is not a retrieval, whenSOAP header blocks are to be transmitted (a digital signature, for example),or when a retrieval is not safe, the6.4 SOAP Web Method Feature and the6.2 SOAP Request-Response Message Exchange Pattern are used. Therequest envelope is encoded as described in4.2.1 RPC Invocation, and the results are as described in4.2.2 RPC Response. Thehttp://www.w3.org/2003/05/soap/features/web-method/Method property isset to "POST".

The SOAP RPC Representation does not define any other value for thehttp://www.w3.org/2003/05/soap/features/web-method/Method .

4.2.1 RPC Invocation

An RPC invocation is modeled as follows:

• The invocation is represented by a single struct containing an outbound edge for each [in] or [in/out] parameter. The struct is named identically to the procedure or method name and the conventions ofB. Mapping Application Defined Names to XML Names SHOULD be used to represent method names that are not legal XML names.

• Each outbound edge has a label corresponding to the name of the parameter. The conventions ofB. Mapping Application Defined Names to XML Names SHOULD be used to represent parameter names that are not legal XML names.

Applications MAY process invocations with missing parameters but also MAY fail to process the invocation and return a fault.

4.2.2 RPC Response

An RPC response is modeled as follows:

• The response is represented by a single struct containing an outbound edge for the return value and each [out] or [in/out] parameter. The name of the struct is not significant.

• Each parameter is represented by an outbound edge with a label corresponding to the name of the parameter. The conventions ofB. Mapping Application Defined Names to XML Names SHOULD be used to represent parameter names that are not legal XML names.

• A non-void return value is represented as follows:

  1. There MUST be an outbound edge with a local name ofresult and a namespace name of "http://www.w3.org/2003/05/soap-rpc" which terminates in a terminal node

  2. The type of that terminal node is a xs:QName and its valueis the name of the outbound edge which terminates in theactual return value.

  If the return value of the procedure is void then an outbound edge with a local name ofresult and a namespace name of "http://www.w3.org/2003/05/soap-rpc" MUST NOT be present.

• Invocation faults are handled according to the rules in4.4 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.

4.2.3 SOAP Encoding Restriction

When using SOAP encoding (see3. SOAP Encoding) in conjunction with the RPC convention described here, the SOAPBody MUST contain only a single childelement information item, that child being the serialized RPC invocation or response struct.

Note:

Senders might receive different faults from those listed above in response to an RPC invocation if the receiver does not support the (optional) RPC convention described here.

5.1.1 Properties

Under the convention, properties are represented as follows:

• Properties are named with URIs.

• Where appropriate, property values SHOULD have an XML Schema[XML Schema Part 1][XML Schema Part 2] type listed in the specification which introduces the property.

5.1.2 Property Scope

Properties within a SOAP node differ in terms of their scope and theorigins of their values. As shown in the figure below, we make thedistinction between per message-exchange and more widely scopedproperties by assigning them to different containers called MessageExchange Context and Environment Context respectively. All properties,regardless of their scope, are shared by a SOAP node and a particularBinding.

Figure 1: Model describing properties shared between SOAP and Binding

5.1.3 Properties and Features

A feature may be expressed through multiple properties and a single propertymay enable more than one feature. For example, the properties called User ID andPassword may be used to enable a feature called Authentication. As a second example,a single property called Message ID could be used to enable one feature calledTransaction and a second feature called Message Correlation.

6.2.1 SOAP Feature Name

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1[SOAP Part 1]SOAP Features):

• "http://www.w3.org/2003/05/soap/mep/request-response/"

6.2.2 Description

The SOAP Request-Response MEP defines a pattern for the exchange of a SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of failure in the underlying protocol, this MEP consists of exactly two SOAP messages.

In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is first transferred from the requesting SOAP node to the responding SOAP node. Following the successful processing of the request message by the responding SOAP node, a response message is transferred from the responding SOAP node to the requesting SOAP node.

Abnormal operation during a Request-Response message exchange might be caused by a failure to transfer the request message, a failure at the responding SOAP node to process the request message, or a failure to transfer the response message. Such failures might be silent at either or both of the requesting and responding SOAP nodes involved, or might result in the generation of a SOAP or binding-specific fault (see6.2.4 Fault Handling). Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.

The scope of a Request-Response MEP is limited to the exchange of a request message and a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

6.2.3 State Machine Description

The Request-Response MEP defines a set of properties described inTable 3.

To initiate a message exchange conforming to the Request-Response MEP, the requesting SOAP node instantiates a local message exchange context.Table 4 describes how the context is initialized.

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of thehttp://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a base URI value carried in thehttp://www.w3.org/2003/05/soap/bindingFramework/ ExchangeContext/Role property of the local message exchange context.

Figure 2: Request-Response MEP State Transition Diagram.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context.Table 5 describes the properties that the binding initializes as part of the context's instantiation.

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties.Table 6 andTable 7 describe these updates for the requesting and the responding SOAP nodes, respectively.

Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:

• All the rules in SOAP 1.2 Part 1[SOAP Part 1]Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.

• When using streaming SOAP bindings, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted.

  Note:

  Depending on the implementation used and the size of the messages involved, this rule MAY require that SOAP applications stream application-level response processing in parallel with request generation.

• A requesting SOAP node MAY enter the "Fail" state, and thus abort transmission of the outbound SOAP request, based on information contained in an incoming streamed SOAP response.

6.2.4 Fault Handling

During the operation of the Request-Response MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the responding SOAP node while it is in the "Receiving" state, the SOAP fault is made available inhttp://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the "Receiving+Sending" state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the "Success" state in the requesting SOAP node's state transition table (seeTable 6).

6.3.1 SOAP Feature Name

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1[SOAP Part 1]SOAP Features):

• "http://www.w3.org/2003/05/soap/mep/soap-response/"

6.3.2 Description

The SOAP Response MEP defines a pattern for the exchange of a non-SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of failure in the underlying protocol, this MEP consists of exactly two messages, only one of which is a SOAP message:

• A request transmitted in a binding-specific manner that does not include a SOAP envelope and hence does notinvolve any SOAP processing by the receiving SOAP node.

• A response message which contains a SOAPenvelope. The MEP is completed by the processing of the SOAP envelopefollowing the rules of the SOAP processing model (seeSOAP 1.2 Part 1[SOAP Part 1], sectionSOAP Processing Model).

Abnormal operation during a SOAP Response message exchange might becaused by a failure to transfer the request message or theresponse message. Such failures might be silent at either or bothof the requesting and responding SOAP nodes involved, or mightresult in the generation of a SOAP or binding-specific fault (seesection6.3.4 Fault Handling). Also, during abnormaloperation each SOAP node involved in the message exchange mightdiffer in its determination of the successful completion of themessage exchange.

The scope of a SOAP Response MEP is limited tothe request for an exchange of a response message betweenone requesting and one responding SOAP node. This pattern doesnot mandate any correlation between multiple requests norspecific timing for multiple requests. Implementations MAY chooseto support multiple ongoing requests (and associated responseprocessing) at the same time.

6.3.3 State Machine Description

The SOAP Response MEP defines a set of properties described inTable 8.

To initiate a message exchange conforming to theSOAP Response MEP, the requesting SOAP node instantiates alocal message exchange context.Table 9 describes howthe context is initialized.

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of thehttp://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a Base URI value carried in thehttp://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role property of the local message exchange context.

Figure 3: SOAP Response MEP State Transition Diagram

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context.Table 10 describes the properties that the binding initializes as part of the context's instantiation.

When the requesting and responding SOAP nodes transition betweenstates, the local binding instance (logically) updates a number ofproperties.Table 11 andTable 12 describe these updates for the requestingand the responding SOAP nodes, respectively.

6.3.4 Fault Handling

During the operation of the SOAP Response MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generatedby the responding SOAP node while it is in the"Receiving" state, the SOAP fault ismade available inhttp://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the"Sending" state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the "Success" state in the requesting SOAP node's state transition table (seeTable 11).

6.4.1 SOAP Feature Name

The SOAP Web Method feature is identified by the URI (see SOAP 1.2 Part 1[SOAP Part 1]SOAP Features):

• "http://www.w3.org/2003/05/soap/features/web-method/"

6.4.2 Description

Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE.These methods are formally defined in the HTTP specification[RFC 2616], but other underlying protocols might also support them. Bindings to HTTP or such other protocols SHOULD use the SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message.

Bindings supporting this feature SHOULD use the appropriate embodiment of that method if provided by the underlying protocol; for example, the HTTP bindingprovided with this specification represents the "GET" Web method as an HTTP GET request, and the "POST" methodas an HTTP POST request (see7. SOAP HTTP Binding). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.

The SOAP Web Method feature MAY be implemented by bindings to underlyingtransports that have no preferred embodiment of particular Web methods (e.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature.

6.4.3 SOAP Web Method Feature State Machine

The SOAP Web Method feature defines a single property, which is described inTable 13.

This specification provides for the use of the SOAP Web Method feature in conjunction with the6.2 SOAP Request-Response Message Exchange Pattern and6.3 SOAP Response Message Exchange Pattern message exchange patterns. Thisfeature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.

A node sending a request message MUST provide a value for thehttp://www.w3.org/2003/05/soap/features/web-method/Method property. A protocol binding supporting this feature SHOULD set the value of thehttp://www.w3.org/2003/05/soap/features/web-method/Method property at the receiving node to match that provided by the sender;the means oftransmission for the method property is binding-specific.

A responding node SHOULD respond in a manner consistent with the Web method requested (e.g. a"GET" shouldresult in retrieval of a representation of the identified resource) or SHOULD fault in anapplication-specific manner if the Web method cannot be supported.

Bindings implementing this feature MUST employ a Message Exchange Pattern with semantics that are compatible with the Web method selected. For example, the SOAP Response Message Exchange Pattern (see6.3 SOAP Response Message Exchange Pattern) is compatible with GET.

6.5.1 SOAP Feature Name

The SOAP Action feature is identified by the URI (see SOAP 1.2 Part 1[SOAP Part 1]SOAP Features):

• "http://www.w3.org/2003/05/soap/features/action/"

6.5.2 Description

Many SOAP 1.2 underlying protocol bindings will likelyutilize the "application/soap+xml" media type (described inA. The application/soap+xml Media Type) to transmit XML serializations of SOAP messages.The media type specifies an optionalaction parameter (seeA.3 The action Parameter), which can be used to optimize dispatch or routing,among other things. The Action Feature specifies well-knownURIs to indicate support for theaction parameter inbindings which use MIME, and also to refer to value of theparameter itself.

6.5.3 SOAP Action Feature State Machine

The SOAP Action feature defines a single property, which is described inTable 14.

If thehttp://www.w3.org/2003/05/soap/features/action/Action property has a value at a SOAP sender utilizing abinding supporting this feature, the sender MUST use theproperty value as the value of theaction parameter inthe media type designator.

Conversely, if a value arrives in theaction parameter ofthe media type designator at a SOAP receiver, the receiver MUSTmake that value available as the value of thehttp://www.w3.org/2003/05/soap/features/action/Action property.

7.1.1 Optionality

The SOAP HTTP Binding is optional and SOAP nodes are NOT required to implement it. A SOAP node that correctly and completely implements the SOAP HTTP Binding may to be said to "conform to the SOAP 1.2 HTTP Binding."

The SOAP version 1.2 specification does not preclude development of other bindings to HTTP or bindings to other protocols, but communication with nodes using such other bindings is not a goal. Note that other bindings of SOAP to HTTP MAY be written to provide support for SOAP Message exchange patterns other than6.2 SOAP Request-Response Message Exchange Pattern or the6.3 SOAP Response Message Exchange Pattern. Such alternate bindings MAY therefore make use of HTTP features and status codes not required for this binding. For example, another binding might provide for a 202 or 204 HTTP response status to be returned in response to an HTTP POST or PUT (e.g. a one-way "push" MEP with confirmation).

7.1.2 Use of HTTP

The SOAP HTTP binding defines a base URI according to the rules in HTTP/1.1[RFC 2616]. I.e. the base URI is the HTTP Request-URI or the value of the HTTP Content-Location header field.

This binding of SOAP to HTTP is intended to make appropriate use of HTTP as an application protocol. For example, successful responses are sent with status code 200, and failures are indicated as 4XX or 5XX. This binding is not intended to fully exploit the features of HTTP, but rather to use HTTP specifically for the purpose of communicating with other SOAP nodes implementing the same binding. Therefore, this HTTP binding for SOAP does not specify the use and/or meaning of all possible HTTP methods, header fields and status responses. It specifies only those which are pertinent to the6.2 SOAP Request-Response Message Exchange Pattern or the6.3 SOAP Response Message Exchange Pattern, or which are likely to be introduced by HTTP mechanisms (such as proxies) acting between the SOAP nodes.

Certain optional features provided by this binding depend on capabilities provided by HTTP/1.1, for example content negotiation. Implementations SHOULD thus use HTTP/1.1[RFC 2616] (or later compatible versions that share the same major version number). Implementations MAY also be deployed using HTTP/1.0, although in this case certain optional binding features may not be provided.

7.1.3 Interoperability with non-SOAP HTTP Implementations

Particularly when used with the6.3 SOAP Response Message Exchange Pattern, the HTTP messages produced by this binding are likely to beindistinguishable from those produced by non-SOAP implementationsperforming similar operations. Accordingly, some degree of interoperation can be made possible between SOAP nodes and other HTTPimplementations when using this binding.For example, a conventional Web server (i.e. one notwritten specifically to conform to this specification) might be used to respondto SOAP-initiated HTTP GET's with representations ofContent-Type "application/soap+xml".Such interoperation is not a normative feature of this specification.

Even though HTTP often is used on the well-known TCP port 80, the use of HTTP is not limited to that port. As a result, it is possible to have a dedicated HTTP server for handling SOAP processing on a distinct TCP port. Alternatively, it is possible to use a separate virtual host for dealing with SOAP processing. Such configuration, however, is a matter of convenience and is not a requirement of this specification (see SOAP 1.2 Part 1[SOAP Part 1]Binding to Application-Specific Protocols).

7.1.4 HTTP Media-Type

Conforming implementations of this binding:

1. MUST be capable of sending and receiving messages serialized using media type "application/soap+xml" whose proper use and parameters are described inA. The application/soap+xml Media Type.

2. MAY send requests and responses using other media types providing that such media types provide for at least the transfer of SOAP XML Infoset.

3. MAY, when sending requests, provide an HTTP Accept header field. This header field:

   • SHOULD indicate an ability to accept at minimum "application/soap+xml".

   • MAY additionally indicate willingness to accept other media types that satisfy 2 above.

Note:

other SOAP Version 1.2 bindings to HTTP may permit other combinations ofhttp://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName andhttp://www.w3.org/2003/05/soap/features/web-method/Method .

7.5.1 Behavior of Requesting SOAP Node

The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with either6.2 SOAP Request-Response Message Exchange Pattern or6.3 SOAP Response Message Exchange Pattern (differences are indicated as necessary.) This binding supports streaming and, as a result, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted (see6.2.3 State Machine Description). The following subsections describe each state in detail.

7.5.2 Behavior of Responding SOAP Node

The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with either6.2 SOAP Request-Response Message Exchange Pattern or6.3 SOAP Response Message Exchange Pattern (differences are indicated as necessary). The following subsections describe each statein detail.