A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model and, if appropriate, generate SOAP faults, SOAP responses and send additional SOAP messages, as provided by the remainder of this specification.

Each SOAP node MUST act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/next", and can additionally assume the roles of zero or more other SOAP actors.

A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor.

SOAP nodes MUST NOT act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/none".

SOAP header blocks carry optional attribute information items with a local name of mustUnderstand and a namespace name of http://www.w3.org/2001/09/soap-envelope (see 4.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory. For such SOAP blocks the targeted SOAP node MUST: either process the SOAP block according to the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block; or not process the SOAP message at all, and generate a fault (see 4.4 SOAP Fault).

Generate a single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand Faults) if one or more SOAP blocks targeted at the SOAP node are mandatory and are not understood by that node. If such a fault is generated, any further processing MUST NOT be done.

A SOAP node MUST process SOAP blocks targetted at it that are identified as mandatory.

If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

A SOAP node MUST ensure that all element information items and attribute information items in messages that it generates are correctly namespace qualified. A SOAP node MUST be able to process SOAP namespace information in messages that it receives. It MUST treat messages with incorrect namespace information as a version error (see 4.1.2 Envelope Versioning Model).

Schema documents for these namespaces can be found by dereferencing the namespace identifiers. These schemas are normative.

A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with faultcode of "Client.DTD".

A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives.

A SOAP message MUST NOT impose any XML schema processing (assessment and validation) requirement on the part of any receiving SOAP node.

The introduction of section 4 explains the structure of a SOAP message.

The encodingStyle attribute information item is a whitespace delimited list where each item in the list is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema.

all URIs syntactically beginning with "http://www.w3.org/2001/09/soap-encoding" indicate conformance with the SOAP encoding rules defined in [1](SOAP Encoding), though with potentially tighter rules added.

A value of the zero-length URI ("") explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.

If a SOAP message is received by a SOAP 1.2 node in which the document element information item does NOT have a local name of Envelope and a namespace name of http://www.w3.org/2001/09/soap-envelope the SOAP node MUST treat this as a version error and generate a VersionMismatch SOAP fault (see 4.4 SOAP Fault). A SOAP VersionMismatch fault message MUST use the SOAP/1.1 envelope namespace "http://schemas.xmlsoap.org/soap/envelope/" (see A Version Transition From SOAP/1.1 to SOAP Version 1.2).

The Header element information item has:

• A local name of Header

• A namespace name of http://www.w3.org/2001/09/soap-envelope

• Zero or more namespace qualified attribute information item children.

• Zero or more namespace qualified element information item children.

All child element information items of the SOAP Header are called SOAP header blocks.

Each SOAP header block element information item:

• MUST be namespace qualified;

• MAY have an encodingStyle attribute information item

• MAY have an actor attribute information item

• MAY have a mustUnderstand attribute information item

A SOAP receiver MUST ignore all SOAP header block attribute information items that are applied to other descendant element information items of the SOAP Header element information item.

SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 3 Relation to XML).

The type of the mustUnderstand attribute information item is boolean in the namespace http://www.w3.org/2001/XMLSchema. Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".

If present, the SOAP Fault MUST appear as a SOAP body block and MUST NOT appear more than once within a SOAP Body.

Section 4.4 describes the structure of a fault element, plus:

[The detail element information item] MUST be present when the contents of the SOAP Body could not be processed successfully. It MUST NOT be used to carry error information about any SOAP header blocks. Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.

The SOAP faultcode values defined in this section MUST be used as values for the SOAP faultcode element information item when describing faults defined by SOAP 1.2 Part 1 (this document). The namespace identifier for these SOAP faultcode values is "http://www.w3.org/2001/09/soap-envelope".

Section 4.4.2 defines the syntax of a mustUnderstand fault, i.e. the syntax of the Misunderstood element.

The data serialized according to the rules defined in this section MAY contain references to data outside the serialization. When present, these references MUST be Uniform Resource Identifiers.

SOAP uses unqualified attribute information items with a local name of id and a type of ID in the http://www.w3.org/2001/XMLSchema namespace to specify the unique identifier of an encoded element.

SOAP uses unqualified attribute information items with a local name of href and a type of anyURI in the http://www.w3.org/2001/XMLSchema namespace to specify a reference to such a value, in a manner conforming to the XML Specification[8], XML Schema Specification[5], and XML Linking Language Specification[9].

All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element.

For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an xsi:type attribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted) enc:arrayType attribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.

Section 4.1 and section 4.2 define simple values.

All simple values MUST be encoded as the content of elements whose type is either defined in "XML Schema Part 2: Datatypes" Specification [11], or is based on a type found there by using the mechanisms provided in the XML Schema specification.

A polymorphic accessor instance MUST contain an xsi:type attribute that describes the type of the actual value.

Section 4.1 and section 4.4 & 4.4.1 define compound values.

A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.

Sections 4.1 and 4.4.1 define multi-reference values.

Sections 4.1 and 4.4.2 define arrays.

A partially transmitted array indicates in an enc:offset attribute the zero-origin offset of the first element transmitted.

Each element representing a member value contains a enc:position attribute that indicates its position within the array.

The name of the return value accessor is "result" and it is namespace-qualified with the namespace identifier "http://www.w3.org/2001/09/soap-rpc" The return value accessor MUST be present if the return value of the procedure is non-void. The return value accessor MUST NOT be present if the return value of the procedure is void.

Section 5.1 states the rules for RPCs.

Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in the RPC encoding. If so, it MUST be expressed as a header block.

Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):

1. A soap-env:Server fault SHOULD be generated when the server cannot handle the message because of some temporary condition, e.g. when it is out of memory.

2. A soap-env:DataEncodingUnknown fault SHOULD be generated when the arguments are encoded in a data encoding unknown to the server.

3. An rpc:ProcedureNotPresent fault MUST be generated when the server cannot find the procedure specified.

4. An rpc:BadArguments fault MUST be generated when the server cannot parse the arguments or when there is a mismatch between what the server expects and what the client has sent.

5. Other faults arising in an extension or from the application SHOULD be generated as described in [1](SOAP Faults).

HTTP applications MUST use the media type "application/soap" according to RFC 2376 when including SOAP messages in HTTP exchanges.

this binding only defines SOAP within HTTP POST requests

If a SOAP Receiver does require SOAPAction's presence in order to operate, it MUST respond to requests which either contain an unrecognised SOAPAction header value or do not contain a SOAPAction header with a 427 "SOAPAction Required" HTTP response status code. Such response messages MAY contain a 'Required-SOAPAction' HTTP response header field, whose value is the URI which can be used in the SOAPAction request header field to re-submit the request.

Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receivers specifies its use).

SOAP over HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the SOAP component was successfully received, understood, and accepted etc.

If an error occurs while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP fault (see SOAP Faults) indicating the SOAP processing error.