SOAP Version 1.2 Part 1: Messaging Framework

1. Introduction

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It defines, using XML technologies, an extensible messaging framework containing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

Note:

In previous versions of this specification the SOAP name was an acronym. This is no longer the case.

Two major design goals for SOAP are simplicity and extensibility (see XMLP Requirements [16]). SOAP attempts to meet these goals by omitting features from the messaging framework that are often found in distributed systems. Such features are left to be defined as extensions by other specifications. Such features include but are not limited to "reliability", "security", "correlation", "routing", and the concept of message exchange patterns (MEPs). While it is anticipated that many such features will be defined, it is beyond the scope of this specification to do so.

The SOAP specification consists of two parts. Part 1 of the SOAP specification (this document) defines the SOAP messaging framework consisting of:

The SOAP processing model defining the rules for processing a SOAP message (see 2. SOAP Processing Model).
The SOAP message construct defining the structure of a SOAP message (see 5. SOAP Message Construct).
The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes (see 4. SOAP Protocol Binding Framework).

Part 2 [1] describes a set of adjuncts that may be used in connection with the SOAP messaging framework.

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].

This specification uses two namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [10]).

Table 1: Prefixes and Namespaces used in this specification.
Prefix	Namespace
enc	"http://www.w3.org/2001/12/soap-encoding"
env	"http://www.w3.org/2001/12/soap-envelope"

Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [6].

All parts of this specification are normative, with the exception of examples and sections explicitly marked as "Non-Normative".

1.2 Relation to other XML Specifications

A SOAP message is specified as an XML Information Set [10]. While all SOAP message examples in this document are shown using XML 1.0 [8] syntax, this is not a requirement of SOAP (see 4. SOAP Protocol Binding Framework).

Some of the information items defined by this document are identified using XML namespace [7] names (see 5. SOAP Message Construct). In particular, this document defines the following namespace names:

The SOAP envelope has the namespace name "http://www.w3.org/2001/12/soap-envelope" (see 5. SOAP Message Construct).
The SOAP Misunderstood element information item has the namespace name "http://www.w3.org/2001/12/soap-faults" (see 5.4.8 Must Understand Faults).
The SOAP Upgrade element information item has the namespace name "http://www.w3.org/2001/12/soap-upgrade" (see 5.4.7 VersionMismatch Faults).

Normative XML Schema [4], [5] documents for these namespace names can be found by dereferencing the namespace names above.

SOAP does not require any XML schema processing (assessment or validation) in order to establish the values or correctness of element and attribute information items defined by this specification. These information items must, unless stated otherwise, be carried explicitly in the transmitted SOAP message (see 5. SOAP Message Construct).

SOAP attribute information items have types described by XML Schema: Datatypes [5]. Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing, e.g. the boolean lexical forms "1" and "true" are interchangeable. For brevity, text in this specification refers only to one lexical form for each value, e.g. "if the value of the mustUnderstand attribute information item is 'true'".

Specifications for the processing of application-defined data carried in a SOAP message but not defined by this specification MAY call for additional validation of the SOAP message in conjunction with application-level processing. In such cases, the choice of schema language and/or validation technology is at the discretion of the application.

SOAP uses XML Base [11] for determining a base URI for relative URI references used as values in information items defined by this specification (see 6. Use of URIs in SOAP).

1.2.1 Processing Requirements

The ability to use SOAP in a particular environment will vary depending on the actual constraints, choice of tools, processing model, or nature of the messages being exchanged. SOAP has been designed to have a relatively small number of dependencies on other XML specifications, none of which are perceived as having prohibitive processing requirements. Also, limiting use of SOAP to small messages instead of arbitrarily-sized messages and supporting only a few specific message types instead of implementing generalized processing could significantly lower processing requirements.

1.2.2 Robustness Principle

In some cases, the use of XML technologies allows the flexibility for expressing semantically equivalent statements in a variety of different ways. In order to obtain robust and interoperable implementations it is essential that SOAP implementations take into account the Robustness Principle as expressed by RFC 1123 [19] and RFC 793 [20]: "Be liberal in what you accept, and conservative in what you send".

The robustness principle is applied in several instances within this specification. For example, section 5.2.2 SOAP role Attribute specifies that senders SHOULD NOT send but receiver's MUST accept certain values of the role attribute.

1.3 Example SOAP Message

The following example shows a sample notification message expressed in SOAP. The message contains two pieces of application-defined data not defined by this specification: a header block with a local name of alertcontrol and a body element with a local name of alert . In general, header blocks contain information which may be of use to intermediaries as well as the ultimate destination(s) of the message. In this example an intermediary might prioritize the delivery of the message based on the priority and expiration information in the header block. The body contains the actual message payload, in this case the alert message.

Example 1: SOAP message containing a header block and a body

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Header>
  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="http://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

1.4 SOAP Terminology

This section describes the terms and concepts introduced in Part 1 of the SOAP specification (this document).

1.4.1 Protocol Concepts

SOAP: The formal set of conventions governing the format and processing rules of a SOAP message. These conventions include the interactions among SOAP nodes generating and accepting SOAP messages for the purpose of exchanging information along a SOAP message path.
SOAP node: The embodiment of the processing logic necessary to transmit, receive, process and/or relay a SOAP message, according to the set of conventions defined by this recommendation. A SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages (see 2. SOAP Processing Model). It accesses the services provided by the underlying protocols through one or more SOAP bindings.
SOAP role: A SOAP node's expected function in processing a message. A SOAP node may act in multiple roles.
SOAP binding: The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of exchange (see 4. SOAP Protocol Binding Framework). Examples of SOAP bindings include carrying a SOAP message within an HTTP entity-body, or over a TCP stream.
SOAP feature: An abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes (see 3. SOAP Extensibility Model). Examples of features include "reliability", "security", "correlation", "routing", and the concept of message exchange patterns.
SOAP message exchange pattern (MEP): A template for the exchange of SOAP messages between SOAP nodes enabled by one or more underlying SOAP protocol bindings (see 4. SOAP Protocol Binding Framework). A SOAP MEP is an example of a SOAP feature (see 3.3 SOAP Message Exchange Patterns (MEPs)).
SOAP application: A software entity that produces, consumes or otherwise acts upon SOAP messages in a manner conforming to the SOAP processing model (see 2. SOAP Processing Model).

1.4.2 Data Encapsulation Concepts

SOAP message: The basic unit of communication between SOAP nodes.
SOAP envelope: The outermost element information item of a SOAP message.
SOAP header block: An element information item used to delimit data that logically constitutes a single computational unit within the SOAP header. The type of a SOAP header block is identified by the fully qualified name of the block element information item.
SOAP header: A collection of zero or more SOAP header blocks each of which may be targeted at any SOAP receiver within the SOAP message path.
SOAP body: A collection of zero or more element information items targeted at an ultimate SOAP receiver in the SOAP message path (see 5.3 SOAP Body).
SOAP fault: A SOAP element information item which contains fault information generated by a SOAP node.

1.4.3 Message Sender and Receiver Concepts

SOAP sender: A SOAP node that transmits a SOAP message.
SOAP receiver: A SOAP node that accepts a SOAP message.
SOAP message path: The set of SOAP nodes through which a single SOAP message passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP receiver.
Initial SOAP sender: The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.
SOAP intermediary: A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes a defined set of SOAP header blocks in a SOAP message. It acts to forward a SOAP message towards an ultimate SOAP receiver.
Ultimate SOAP receiver: The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message may not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message (see 2. SOAP Processing Model).

2. SOAP Processing Model

SOAP provides a distributed processing model that assumes a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. Note that the SOAP distributed processing model can support many MEPs including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations (see 3.3 SOAP Message Exchange Patterns (MEPs) for a description of how SOAP message exchange patterns are described in terms of the SOAP extensibility model).

This section defines the SOAP distributed processing model. Section 4. SOAP Protocol Binding Framework defines a framework for describing the rules for how SOAP messages can be exchanged over a variety of underlying protocols. Section 3. SOAP Extensibility Model describes how SOAP can be extended and how SOAP extensions may interact with the SOAP processing model and the SOAP protocol binding framework.

2.1 SOAP Nodes

A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. An intermediary is both a SOAP sender and a SOAP receiver.

A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model as described in this section and in the remainder of this specification.

A SOAP node MUST be identified by a URI.

2.2 SOAP Roles and SOAP Nodes

In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is identified by a URI known as the SOAP role name. The roles assumed by a node MUST be invariant during the processing of an individual SOAP message. This specification deals only with the processing of individual SOAP messages. No statement is made regarding the possibility that a given SOAP node might or might not act in varying roles when processing more than one SOAP message.

This specification defines the following SOAP roles:

"http://www.w3.org/2001/12/soap-envelope/role/next". Each SOAP intermediary and ultimate SOAP receiver MUST act in this role and MAY additionally assume zero or more other SOAP roles.
"http://www.w3.org/2001/12/soap-envelope/role/none". SOAP nodes MUST NOT act in this role.
"http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver". To establish itself as an ultimate SOAP receiver a SOAP node MUST act in this role. SOAP intermediaries MUST NOT act in this role.

In addition to those described above, other roles MAY be defined as necessary to meet the needs of SOAP applications.

While the purpose of a SOAP role name is to identify a SOAP node or nodes, there are no routing or message exchange semantics associated with the SOAP role name. For example, SOAP roles MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP roles with names that are related more indirectly to message routing (e.g. "http://example.org/banking/anyAccountMgr") or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concerned software that the containing SOAP message is idempotent, and can safely be cached and replayed).

With the exception of the three SOAP roles defined above, this specification does not prescribe the criteria by which a given node determines the (possibly empty) set of roles in which it acts on a given message. For example, implementations can base this determination on factors including, but not limited to: hard coded choices in the implementation, information provided by the underlying protocol binding (e.g. the URI to which the message was physically delivered), or configuration information made by users during system installation.

2.3 Targeting SOAP Header Blocks

A SOAP header block MAY carry an optional role attribute information item (see 5.2.2 SOAP role Attribute) that is used to target the blocks at the appropriate SOAP node(s). This specification refers to the value of the SOAP role attribute as the SOAP role for the corresponding SOAP header block.

A SOAP header block is said to be targeted at a SOAP node if the SOAP role for the header block is the name of a role played by the SOAP node.

Header blocks targeted at the special role "http://www.w3.org/2001/12/soap-envelope/role/none" are carried with the message to the ultimate SOAP receiver(s), but are never formally processed. Such blocks MAY carry data that is required for processing of other blocks.

2.4 Understanding SOAP Headers

It is likely that specifications for a wide variety of header functions will be developed over time (see 3. SOAP Extensibility Model), and that some SOAP nodes may include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.

SOAP header blocks carry optional mustUnderstand attribute information items (see 5.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory.

Mandatory blocks are presumed to somehow modify the semantics of other headers or body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).

Tagging SOAP blocks as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by a SOAP node to which the header block is targeted.

The mustUnderstand attribute information item is not intended as a mechanism for detecting errors in routing, misidentification of nodes, failure of a node to serve in its intended role(s), etc.. Any of these conditions may result in a failure to even attempt processing of a given SOAP header block from a SOAP envelope. This specification therefore does not require any fault to be generated based on the presence or value of the mustUnderstand attribute information item on a SOAP header block not targeted at the current processing node. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver. This is the case, for example, when a block has survived erronously due to a routing or targeting error at a preceeding intermediairy.

2.5 Structure and Interpretation of SOAP Bodies

An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, with the exception of SOAP faults (see 5.4 SOAP Fault), Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done.

2.6 Processing SOAP Messages

This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing MUST be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification prevents the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order provided all generated SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below.

Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any header blocks and the body, MAY be inspected in making such determination.
Identify all header blocks targeted at the node that are mandatory.
If one or more of the header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with a Value of "env:MustUnderstand" for Code (see 5.4.8 Must Understand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the body MUST NOT be generated in this step.
Process all header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the processing implied by non-mandatory SOAP header blocks targeted at it.
In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message as described in section 2.7 Relaying SOAP Messages.

In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP block and MUST do such processing in a manner fully conformant with the specification for that block. An ultimate SOAP receiver MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.

Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message processing MAY result in the generation of at-most one fault. Header-related faults other than those related to understanding header blocks (see 2.4 Understanding SOAP Headers) MUST conform to the specification for the corresponding SOAP header block.

SOAP nodes MAY make reference to any information in the SOAP envelope when processing a SOAP body or SOAP header block. For example, a caching function can cache the entire SOAP message, if desired.

The processing of a particular SOAP header block MAY control or determine the order of processing for other SOAP header blocks and/or the SOAP body. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a controlling block, the order of header and body processing is at the discretion of the SOAP node. Header blocks MAY be processed in arbitrary order. Header block processing MAY precede, MAY be interleaved with, or MAY follow processing of the body. For example, a "begin transaction" header block would typically precede processing of a "commit transaction" header block, and a "logging" function might run concurrently with body processing.

Note:

The above rules apply to processing at a single node. SOAP extensions may be designed to ensure that headers are processed in an appropriate order, as the message moves along the message path towards the ultimate SOAP receiver. Specifically, such extensions might specify that a fault with a Value of "env:Sender" for Code is generated if some SOAP header blocks have inadvertently survived past some intended point in the message path. Such extensions may depend on the presence or value of the mustUnderstand attribute information item in the surviving headers when determining whether an error has occurred.

2.7 Relaying SOAP Messages

As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and then expressed as SOAP extensions or as part of the underlying protocol binding (see 3. SOAP Extensibility Model and 4. SOAP Protocol Binding Framework). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two types of intermediary are described below.

2.7.1 Forwarding Intermediaries

The semantics of one or more SOAP header blocks in a SOAP message, or the SOAP MEP used MAY require that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP forwarding intermediary.

Forwarding intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the message all SOAP header blocks targeted at themselves, prior to forwarding, regardless of whether these blocks were processed or ignored.

In addition, forwarding intermediaries MUST also obey the specification for the SOAP forwarding feature being used. The specification for such a feature MUST describe the required semantics, including the rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above. Re-inserting processed SOAP header blocks in this manner effectively leaves them in place, but emphasizes the need to process them at each SOAP node along the SOAP message path.

2.7.2 Active Intermediaries

In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. That is, they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: security services, annotation services, and content manipulation services.

The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encrypted some or all of the blocks found in the inbound message. It is strongly recommended that features provided by active intermediaries be described in a manner that allows such modifications to be detected by affected SOAP nodes in the message path.

One mechanism by which an active intermediary can describe the modifications performed on a message is by inserting header blocks into the outbound SOAP message. These header blocks can inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. In this case, the semantics of such inserted header blocks should also call for either the same or other header blocks to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with header blocks removed for encryption passes through a second intermediary (without the original header blocks being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.

2.8 SOAP Versioning Model

The version of a SOAP message is identified by the qualified name of the child element information item of the document information item. A SOAP Version 1.2 message has a child element information item of the document information item with a local name of Envelope and a namespace name of "http://www.w3.org/2001/12/soap-envelope" (see 5.1 SOAP Envelope).

A SOAP node determines whether it supports the version of a SOAP message on a per message basis. In this context "support" means understanding the semantics of that version of a SOAP envelope. The versioning model is directed only at the Envelope element information item. It does NOT address versioning of blocks, encodings, protocol bindings, or anything else.

A SOAP node MAY support multiple envelope versions. However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.

If a SOAP node receives a message whose version is not supported it MUST generate a fault (see 5.4 SOAP Fault) with a Value of "env:VersionMismatch" for Code . Any other malformation of the message construct MUST result in the generation of a fault with a Value of "env:Sender" for Code .

Appendix A. Version Transition From SOAP/1.1 to SOAP Version 1.2 defines a mechanism for transitioning from SOAP/1.1 to SOAP Version 1.2 using the Upgrade element information item (see 5.4.7 VersionMismatch Faults).

3. SOAP Extensibility Model

SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. As a result, most features often found in distributed systems, and generally associated with the exchange of messages, have been left out of the messaging framework. While it is anticipated that many such features will be defined for SOAP, it is beyond the scope of this specification to do so. Instead, they are expected to be defined as extensions to SOAP.

3.1 SOAP Features

For the purpose of this specification, the term "feature" is used to identify an abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes. Although SOAP poses no constraints on the potential scope of such features, examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require a variety of MEPs such as one-way messages, request/response interactions, and peer-to-peer conversations. MEPs are considered to be a type of feature, and unless otherwise stated, references in this specification to the term "feature" apply also to MEPs.

The SOAP extensibility model provides two mechanisms through which features may be expressed: the SOAP Processing Model and the SOAP Protocol Binding Framework (see 2. SOAP Processing Model and 4. SOAP Protocol Binding Framework). The former describes the behavior of a single SOAP node with respect to the processing of an individual message. The latter mediates the act of sending and receiving SOAP messages by a SOAP node via an underlying protocol.

The SOAP Processing Model enables SOAP nodes that include the mechanisms necessary to implement one or more features to express such features within the SOAP envelope as header blocks (see 2.4 Understanding SOAP Headers). Such header blocks can be intended for any SOAP node or nodes along a SOAP message path (see 2.3 Targeting SOAP Header Blocks). A feature expressed as SOAP headers is known as a SOAP module, and each module should be specified according to the rules in 3.2 SOAP Modules.

In contrast, a SOAP protocol binding operates between two adjacent SOAP nodes along a SOAP message path. There is no requirement that the same underlying protocol is used for all hops along a SOAP message path. In some cases, underlying protocols are equipped, either directly or through extension, with mechanisms for providing certain features. The SOAP Protocol Binding Framework provides a scheme for describing these features and how they relate to SOAP nodes through a binding specification (see 4. SOAP Protocol Binding Framework).

The combination of the SOAP Processing Model and the SOAP Protocol Binding Framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as header blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions.

Certain features may require end-to-end as opposed to hop-to-hop processing semantics. While the SOAP Protocol Binding Framework provides for the possibility that such features may be expressed outside the SOAP envelope, it does not define a specific architecture for the processing or error handling of these externally expressed features by a SOAP intermediary. A binding specification that expresses such features external to the SOAP envelope should define its own processing rules to which a SOAP node is expected to conform (for example, describing what information must be passed along with the SOAP message as it leaves the intermediary). It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that the rules defined by the SOAP Processing Model can be employed.

3.1.1 Requirements on Features

The specification of a feature MUST include the following:

The information (state) required at each node to implement the feature.
The processing required at each node in order to fulfill the obligations of the feature including any handling of communication failures that might occur in the underlying protocol (see also 4.2 Binding Framework).
The information to be transmitted from node to node.
In the case of MEPs:
1. Any requirements to generate additional messages (such as responses to requests in a request/response MEP).
2. Rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP.

As an example of a MEP feature specification, SOAP Part 2 [1] includes the specification of a particular request/response MEP.

3.2 SOAP Modules

A SOAP module is a feature which is expressed as SOAP headers.

A module specification follows the following rules. It:

MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation.
MUST clearly and completely specify the content and semantics of the header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model.
MAY utilize the property conventions defined in Part 2 [1], section A Convention for Describing Features and Bindings, in describing the functionality that the module provides. If these conventions are followed, the module specification MUST clearly describe the relationship between the abstract properties and their representations in the SOAP envelope. Note that it is possible to write a feature specification purely in terms of abstract properties, and then write a separate module specification which implements that feature, mapping the properties defined in the feature specification to SOAP header blocks in the module.
MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules). For example, we can imagine a module which encrypts the body and inserts a header containing a checksum and an indication of the encryption mechanism used. The specification for such a module would indicate that the decryption algorithm on the receiving side must run prior to any other modules which rely on the contents of the body.

3.3 SOAP Message Exchange Patterns (MEPs)

A MEP is a template for the exchange of messages between SOAP nodes supported by one or more underlying protocol binding instances.

This section is a logical description of the operation of a MEP. It is not intended to describe a real implementation or to imply that a real implementation should be similarly structured.

In general the definition of a message exchange pattern:

Is named by a URI.
Describes the life cycle of a message exchange conforming to the pattern. A message exchange has a life cycle governed by a message exchange pattern.
Describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern.
Describes the normal and abnormal termination of a message exchange conforming to the pattern.

Underlying protocol binding specifications may declare their support for one or more named MEPs.

4. SOAP Protocol Binding Framework

SOAP enables exchange of SOAP messages using a variety of underlying protocols. The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of exchange is called a binding. The SOAP Protocol Binding Framework provides a scheme for describing bindings and how they relate to SOAP nodes through a binding specification. As an example of a binding specification, SOAP Part 2 [1] includes the specification for a binding to HTTP. Additional bindings can be created by specifications that conform to the binding framework introduced in this chapter.

A SOAP binding specification:

Declares the features provided by a binding.
Describes how the services of the underlying protocol are used to honor the contract formed by the features supported by that binding.
Describes the handling of all potential failures that may be anticipated within the binding.
Defines the requirements for building a conformant implementation of the binding being specified.

A binding does not provide a separate processing model and does not constitute a SOAP node by itself. Rather a SOAP binding is an integral part of a SOAP node (see 2. SOAP Processing Model).

4.1 Goals of the Binding Framework

The goals of the binding framework are:

To set out the requirements and concepts that are common to all binding specifications.
To facilitate homogeneous description in situations where multiple bindings support common features, promoting reuse across bindings.
To facilitate consistency in the specification of optional features.

Two or more bindings may offer a given optional feature, such as reliable delivery, using different means. One binding may exploit an underlying protocol that directly facilitates the feature (e.g., the protocol is reliable), and the other binding may provide the necessary logic itself (e.g., reliability is achieved via logging and retransmission). In such cases, the feature can be made available to applications in a consistent manner, regardless of which binding is used.

4.2 Binding Framework

The creation, transmission, and processing of a SOAP message, possibly through one or more intermediaries, is specified in terms of a distributed state machine. The state consists of information known to a SOAP node at a given point in time, including but not limited to the contents of messages being assembled for transmission or received for processing. The state at each node can be updated either by local processing, or by information received from an adjacent node.

Section 2. SOAP Processing Model of this specification describes the processing that is common to all SOAP nodes when receiving a message. The purpose of a binding specification is to augment those core SOAP rules with additional processing that is particular to the binding, and to specify the manner in which the underlying protocol is used to transmit information between adjacent nodes in the message path.

The distributed state machine that manages the transmission of a given SOAP message through its message path is the combination of the core SOAP processing (see 2. SOAP Processing Model) operating at each node, in conjunction with the binding specifications connecting each pair of nodes. A binding specification MUST enable one or more MEP.

In cases where multiple features are supported by a binding specification the specifications for those features MUST provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.

The binding framework provides no fixed means of naming or typing the information comprising the state at a given node. Individual feature and binding specifications are free to adopt their own conventions for specifying state. Note, however, that consistency across bindings and features is likely to be enhanced in situations where multiple feature specifications adopt consistent conventions for representing state. For example, multiple features may benefit from a consistent specification for an authentication credential, a transaction ID, etc. The HTTP binding in SOAP Part 2 [1] illustrates one such convention.

As described in 5. SOAP Message Construct, each SOAP message is modeled as an XML Infoset that consists of a document information item with exactly one child: the envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP XML Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol.

The binding framework does NOT require that every binding use the XML 1.0 [8] serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate. A binding, if using XML 1.0 serialization of the infoset, MAY mandate that a particular character encoding or set of encodings be used.

Bindings MAY provide for streaming when processing messages. That is, SOAP nodes MAY begin processing a received SOAP message as soon as the necessary information is available. SOAP processing is specified in terms of Envelope XML infosets (see 5. SOAP Message Construct). Although streaming SOAP receivers will acquire such Infosets incrementally, SOAP processing MUST yield results identical to those that would have been achieved if the entire SOAP envelope were available prior to the start of processing. For example, as provided in 2.6 Processing SOAP Messages, identification of targeted headers blocks, and checking of all mustUnderstand attributes must be done before successful processing can proceed. Depending on the representation used for the Infoset, and the order in which it is transmitted, this rule may limit the degree to which streaming can be achieved.

Note:

Section 5. SOAP Message Construct provides that the XML Infoset of a SOAP message MUST NOT include a DTD. Accordingly, a binding that uses the XML 1.0 serialization MUST NOT transmit a DTD; a binding that accepts XML 1.0 serializations MUST fault in a binding specific manner if an XML 1.0 serialization corresponding to a DTD for the SOAP message is received.

Bindings MAY depend on state that is modeled as being outside of the SOAP XML Infoset (e.g. retry counts), and MAY transmit such information to adjacent nodes. For example, some bindings take a message delivery address (typically a URI) that is not within the envelope.

5. SOAP Message Construct

A SOAP message is specified as an XML Infoset that consists of a document information item with exactly one member in its [children] property, which MUST be the SOAP Envelope element information item (see 5.1 SOAP Envelope). This element information item is also the value of the [document element] property. The [notations] and [unparsed entities] properties are both empty. The [base URI], [character encoding scheme] and [version] properties may have any legal value. The [standalone] property either has a value of "true" or has no value.

The XML infoset of a SOAP message MUST NOT contain a document type declaration information item.

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

Element information items defined by this specification may have zero or more character information item children whose character code is amongst the whitespace characters as defined by [8]. Unless otherwise indicated, such character information items are considered insignificant. A SOAP receiver MUST ignore such insignificant character information items. A SOAP intermediary MAY ignore such insignificant character information items when forwarding (see 2.7 Relaying SOAP Messages) a message.

5.1 SOAP Envelope

The Envelope element information item has:

A [local name] of Envelope .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
Zero or more namespace qualified attribute information items amongst its [attributes] property.
One or two element information items in its [children] property in order as follows:
1. An optional Header element information item (see 5.2 SOAP Header).
2. A mandatory Body element information item (see 5.3 SOAP Body).

5.1.1 SOAP encodingStyle Attribute

SOAP defines an optional encodingStyle attribute information item which indicates the encoding rules used to serialize a SOAP message.

The encodingStyle attribute information item has:

A [local name] of encodingStyle .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".

The encodingStyle attribute information item MAY appear on any element information item within the SOAP body or a SOAP header block. Its scope is that of its owner element information item and that element information item's descendants, unless a descendant itself carries such an attribute information item. If no encodingStyle attribute information item is in scope for a particular element information item or the value of such an attribute information item is the zero-length URI ("") then no claims are made regarding the encoding style of that element information item and its descendants.

The encodingStyle attribute information item is of type anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". Its value identifies a set of serialization rules that can be used to deserialize the SOAP message.

Example 2: Values for the encodingStyle attribute information item.

"http://www.w3.org/2001/12/soap-encoding"
"http://example.org/encoding/"
""

5.2 SOAP Header

The SOAP Header element information item provides a mechanism for extending a SOAP message in a decentralized and modular way (see 3. SOAP Extensibility Model and 2.4 Understanding SOAP Headers).

The Header element information item has:

A [local name] of Header .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
Zero or more namespace qualified attribute information items in its [attributes] property.
Zero or more namespace qualified element information items in its [children] property.

Each child element information item of the SOAP Header is called a SOAP header block.

5.2.1 SOAP header block

Each SOAP header block element information item:

MUST have a [namespace name] property which has a value, that is, be namespace qualified.
MAY have an encodingStyle attribute information item in its [attributes] property.
MAY have an role attribute information item in its [attributes] property.
MAY have a mustUnderstand attribute information item in its [attributes] property.

Example 3: Header with a single header block

<env:Header xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <t:Transaction xmlns:t="http://example.org/2001/06/tx" 
                env:mustUnderstand="true" >
   5
 </t:Transaction>
</env:Header>

The SOAP header block attribute information items defined later in sections 5.2.2 SOAP role Attribute and 5.2.3 SOAP mustUnderstand Attribute determine how a SOAP receiver should process an incoming SOAP message, as described in 2. SOAP Processing Model.

A SOAP sender generating a SOAP message SHOULD only use the SOAP header block attribute information items on SOAP header block themselves. A SOAP receiver MUST ignore all such attribute information items on descendants of a SOAP header block.

5.2.2 SOAP role Attribute

A SOAP role is used to indicate the SOAP node to which a particular SOAP header block is targeted (see 2.2 SOAP Roles and SOAP Nodes).

The role attribute information item has the following Infoset properties:

A [local name] of role .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
A [specified] property with a value of "true".

The type of the role attribute information item is anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". The value of the role attribute information item is a URI that names a role that a SOAP node may assume.

Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver". An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the block at an ultimate SOAP receiver.

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP role attribute information item for SOAP header blocks targeted at an ultimate SOAP receiver (see section 1.2.2 Robustness Principle). If relaying a SOAP message, a SOAP intermediary MAY discard the SOAP role attribute information item for SOAP header blocks targeted at an ultimate SOAP receiver (see 2.7 Relaying SOAP Messages).

5.2.3 SOAP mustUnderstand Attribute

The SOAP mustUnderstand attribute information item is used to indicate whether the processing of a SOAP header block is mandatory or optional (see 2.4 Understanding SOAP Headers)

The mustUnderstand attribute information item has the following Infoset properties:

A [local name] of mustUnderstand .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
A [specified] property with a value of "true".

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" or "0".

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP mustUnderstand attribute information item with a value of "false" or "0" (see section 1.2.2 Robustness Principle). If generating a SOAP mustUnderstand attribute information item, a SOAP sender SHOULD use the canonical representation "true" of the attribute value (see [5]). A SOAP receiver MUST accept any valid lexical representation of the attribute value.

If relaying the message, a SOAP intermediary MAY substitute "true" for the value "1", or "false" for "0". The SOAP mustUnderstand attribute information item may be omitted if its value would have been "false" or "0".

5.3 SOAP Body

A SOAP body provides a mechanism for transmitting information to an ultimate SOAP receiver (see 2.5 Structure and Interpretation of SOAP Bodies).

The Body element information item has:

A [local name] of Body .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
Zero or more namespace qualified attribute information items in its [attributes] property.
Zero or more namespace qualified element information items in its [children] property.

5.3.1 SOAP Body child Element

All child element information items of the SOAP Body element information item:

MUST have a [namespace name] property which has a value, that is, be namespace qualified.
MAY have an encodingStyle attribute information item in their [attributes] property.

SOAP defines one particular direct child of the SOAP body, the SOAP fault, which is used for reporting errors (see 5.4 SOAP Fault).

5.4 SOAP Fault

A SOAP fault is used to carry error information within a SOAP message.

The Fault element information item has:

A [local name] of Fault .
A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".
Two or more child element information items in its [children] property in order as follows:
1. A mandatory Code element information item (see 5.4.1 SOAP Code Element).
2. A mandatory Reason element information item (see 5.4.2 SOAP Reason Element).
3. An optional Node element information item (see 5.4.3 SOAP Node Element).
4. An optional Role element information item (see 5.4.4 SOAP Role Element).
5. An optional Detail element information item (see 5.4.5 SOAP Detail Element).

To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child of the SOAP Body .

When generating a fault, SOAP senders MUST NOT include additional element information items in the SOAP Body . A message whose Body contains a Fault plus additional element information items has no SOAP-defined semantics.

A SOAP Fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP Body ; but, in such cases, the element has no SOAP-defined semantics.

5.4.1 SOAP Code Element

The Code element information item has:

A [local name] of Code .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
One or two child element information items in its [children] property, in order, as follows:
1. A mandatory Value element information item as described below (see 5.4.1.1 SOAP Value element (with Code parent))
2. An optional Subcode element information item as described below (see 5.4.1.2 SOAP Subcode element).

5.4.1.1 SOAP Value element (with Code parent)

The Value element information item has;

A [local name] of Value .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .

The type of the Value element information item is faultCodeEnum in the "http://www.w3.org/2001/12/soap-envelope" namespace. SOAP defines a small set of SOAP fault codes covering high level SOAP faults (see 5.4.6 SOAP Fault Codes).

5.4.1.2 SOAP Subcode element

The Subcode element information item has:

A [local name] of Subcode .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
One or two child element information items in its [children] property, in order, as follows:
1. A mandatory Value element information item as described below (see 5.4.1.3 SOAP Value element (with Subcode parent)).
2. An optional Subcode element information item (see 5.4.1.2 SOAP Subcode element).

5.4.1.3 SOAP Value element (with Subcode parent)

The Value element information item has:

A [local name] of Value .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .

The type of the Value element information item is an XML qualified name in the "http://www.w3.org/2001/XMLSchema" namespace. The value of this element is an application defined subcategory of the value of the Value child element information item of the Subcode element information item's parent element information item (see 5.4.6 SOAP Fault Codes).

5.4.2 SOAP Reason Element

The Reason element information item is intended to provide a human readable explanation of the fault.

The Reason element information item has:

A [local name] of Reason .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
An optional attribute information item with a [local name] of lang and [namespace name] of "http://www.w3.org/XML/1998/namespace" (see [8], Language Identification).

This element information item is similar to the 'Reason-Phrase' defined by HTTP [2] and SHOULD provide at least some information explaining the nature of the fault. It is not intended for algorithmic processing.

The type of the Reason element information item is faultreason in the "http://www.w3.org/2001/12/soap-envelope" namespace.

Child character information items whose character code is amongst the whitespace characters as defined by [8] are considered significant.

5.4.3 SOAP Node Element

The Node element information item is intended to provide information about which SOAP node on the SOAP message path caused the fault to happen (see 2. SOAP Processing Model).

The Node element information item has:

A [local name] of Node .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .

As described in section 2.1 SOAP Nodes, each SOAP node is identified by a URI. The value of the Node element information item is the URI that identifies the SOAP node that generated the fault. SOAP nodes that do not act as the ultimate SOAP receiver MUST include this element information item An ultimate SOAP receiver MAY include this element information item to indicate explicitly that it generated the fault.

The type of the Node element information item is anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.

5.4.4 SOAP Role Element

The Role element information item is similar to the SOAP role attribute information item (see 5.2.2 SOAP role Attribute), except that the value of the Role element information item identifies the role the node was playing at the point the fault occurred.

The Role element information item has:

A [local name] of Role .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .

The type of the Role element information item is anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.

5.4.5 SOAP Detail Element

The Detail element information item is intended for carrying application specific error information related to the SOAP Body .

The Detail element information item has:

A [local name] of Detail .
A [namespace name] of http://www.w3.org/2001/12/soap-envelope .
Zero or more attribute information items in its [attributes] property.
Zero or more child element information items in its [children] property.

The Detail element information item MUST 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 absence of the Detail element information item indicates that a SOAP Fault is not related to the processing of the SOAP Body . Presence of the Detail element information item is a signal that the SOAP Body was at least partially processed by an ultimate SOAP receiver before the fault occurred.

All child element information items of the Detail element information item are called detail entries (see 5.4.5.1 SOAP detail entry).

5.4.5.1 SOAP detail entry

Each detail entry:

MAY be namespace qualified.
MAY have any number of element information item children
MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [8] are considered significant.
MAY have an encodingStyle attribute information item.
MAY have any number of other attribute information items from any namespace

The SOAP encodingStyle attribute information item is present indicates the encoding style used for the detail entry (see 5.1.1 SOAP encodingStyle Attribute).

5.4.6 SOAP Fault Codes

SOAP fault codes are intended for use by software to provide an algorithmic mechanism for identifying the fault.

The values of the Value child element information item of the Code element information item are restricted to those in Table 2. Specifications that wish to implement their own fault codes MUST do so by sub-categorizing an existing fault code via the Subcode element information item.

SOAP fault code (see 5.4.1 SOAP Code Element) values are XML qualified names (see XML Namespaces [7]) in the namespace name "http://www.w3.org/2001/12/soap-envelope".

Table 2: SOAP Fault Codes
Local Name	Meaning
VersionMismatch	The faulting node found an invalid element information item instead of the expected `Envelope` element information item. The namespace, local name or both did not match the `Envelope` element information item required by this recommendation (see 2.8 SOAP Versioning Model and 5.4.7 VersionMismatch Faults)
MustUnderstand	An immediate child element information item of the SOAP `Header` element information item that was either not understood or not obeyed by the processing party contained a SOAP `mustUnderstand` attribute information item with a value of "true" (see 5.2.3 SOAP mustUnderstand Attribute and 5.4.8 Must Understand Faults)
DataEncodingUnknown	A header or body targeted at the faulting SOAP node is scoped (see 5.1.1 SOAP encodingStyle Attribute) with a data encoding that the faulting node does not support.
Sender	A `Value` of "env:Sender" for `Code` indicates that the message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change (see also 5.4 SOAP Fault for a description of the SOAP fault `detail` sub-element).
Receiver	A `Value` of "env:Receiver" for `Code` indicates that the message could not be processed for reasons not directly attributable to the contents of the message itself but rather to the processing of the message. For example, processing could include communicating with an upstream SOAP node, which did not respond. The message may succeed at a later point in time (see also 5.4 SOAP Fault for a description of the SOAP fault `detail` sub-element).

5.4.7 VersionMismatch Faults

When a SOAP node generates a fault with a Value of "env:VersionMismatch" for Code , it SHOULD provide, in the generated fault message, an Upgrade header block as described below which detail the XML qualified names (per XML Schema: Datatypes [5]) of the supported SOAP envelopes that the SOAP node supports (see 2.8 SOAP Versioning Model).

The Upgrade header block consists of an Upgrade element information item containing an ordered list of qualified names of SOAP envelopes that the SOAP node supports in the order most to least preferred.

The Upgrade element information item has:

A [local name] of Upgrade .
A [namespace name] of "http://www.w3.org/2001/12/soap-upgrade".
One or more envelope element information items in its [children] property as described below:

The envelope element information item has:

A [local name] of envelope .
A [namespace name] which has no value.
An unqualified attribute information item with a local name of qname whose type is an XML qualified name in the "http://www.w3.org/2001/XMLSchema" namespace.

The following example illustrates the case of a SOAP node that supports both SOAP Version 1.2 and SOAP/1.1 but which prefers SOAP Version 1.2 (see appendix A. Version Transition From SOAP/1.1 to SOAP Version 1.2 for a mechanism for transitioning from SOAP/1.1 to SOAP Version 1.2). This is indicated by including an Upgrade header block with two envelope element information items, the first containing the local name and namespace name of the SOAP Version 1.2 Envelope element information item, the latter the local name and namespace name of the SOAP/1.1 Envelope element.

Example 4: Version mismatch fault generated by a SOAP node. The message includes a SOAP Upgrade header block indicating support for both SOAP Version 1.2 and SOAP/1.1 but with a preference for SOAP Version 1.2.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Header>
  <V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-upgrade">
   <envelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2001/12/soap-envelope"/>
   <envelope qname="ns2:Envelope" 
             xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>
  </V:Upgrade>
 </env:Header>
 <env:Body>
  <env:Fault>
   <env:Code><env:Value>env:VersionMismatch</env:Value></env:Code>
    <env:Reason>Version Mismatch</env:Reason>
   </env:Fault>
 </env:Body>
</env:Envelope>

5.4.8 Must Understand Faults

When a SOAP node generates a fault with a Value of "env:MustUnderstand" for Code , it SHOULD provide, in the generated fault message, Misunderstood header blocks as described below which detail the XML qualified names (per XML Schema: Datatypes [5]) of the particular header block(s) which were not understood.

A SOAP node MAY generate a SOAP fault for any one or more SOAP header blocks that were not understood in a SOAP message. It is NOT a requirement that the fault contain the qualified names of ALL such blocks.

Each such header block element information item has:

A [local name] of Misunderstood .
A [namespace name] of "http://www.w3.org/2001/12/soap-faults".
A qname attribute information item in its [attributes] property as described below.

The qname attribute information item has the following Infoset properties:

A [local name] of qname .
A [namespace name] which has no value.
A [specified] property with a value of "true".

The type of the qname attribute information item is an XML qualified name in the "http://www.w3.org/2001/XMLSchema" namespace. Its value is the XML qualified name of a header block which the faulting node failed to understand.

Consider the following message:

Example 5: SOAP envelope that will cause a fault if Extension1 or Extension2 are not understood

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'>
  <env:Header>
    <abc:Extension1 xmlns:abc='http://example.org/2001/06/ext'
       env:mustUnderstand='true'/>
    <def:Extension2 xmlns:def='http://example.com/stuff'
       env:mustUnderstand='true' />
  </env:Header>
  <env:Body>
    . . .
  </env:Body>
</env:Envelope>

The message in the above example will result in the fault message shown in the example below if the receiver of the initial message does not understand the two header elements abc:Extension1 and def:Extension2 .

Example 6: SOAP fault generated as a result of not understanding Extension1 and Extension2

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'
              xmlns:f='http://www.w3.org/2001/12/soap-faults' >
 <env:Header>
  <f:Misunderstood qname='abc:Extension1'
                   xmlns:abc='http://example.org/2001/06/ext' />
  <f:Misunderstood qname='def:Extension2'
                   xmlns:def='http://example.com/stuff' />
 </env:Header>
 <env:Body>
  <env:Fault>
   <env:Code><env:Value>env:MustUnderstand</env:Value></env:Code>
   <env:Reason>One or more mandatory 
                headers not understood</env:Reason>
  </env:Fault>
 </env:Body>
</env:Envelope>

Note:

When serializing the qname attribute information item there must be an in-scope namespace declaration for the namespace name of the misunderstood header and the value of the attribute information item must use the prefix of such a namespace declaration. The prefix used need not be the same as the one used in the message that was misunderstood.

6. Use of URIs in SOAP

SOAP uses URIs for some identifiers including, but not limited to, values of the encodingStyle (see 5.1.1 SOAP encodingStyle Attribute) and role (see 5.2.2 SOAP role Attribute) attribute information items. To SOAP, a URI is simply a formatted string that identifies a web resource via its name, location, or any other characteristics.

Although this section only applies to URIs directly used by information items defined by this specification, it is RECOMMENDED but NOT REQUIRED that application-defined data carried within a SOAP envelope use the same mechanisms and guidelines defined here for handling URIs.

URIs used as values in information items identified by the "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" XML namespaces can be either relative or absolute.

SOAP does not define a base URI but relies on the mechanisms defined in XML Base [11] and RFC 2396 [6] for establishing a base URI against which relative URIs can be made absolute.

The underlying protocol binding MAY define a base URI which can act as the base URI for the SOAP envelope (see 4. SOAP Protocol Binding Framework and Part 2 [1] section HTTP binding).

SOAP does not define any equivalence rules for URIs in general as these are defined by the individual URI schemes and by RFC 2396 [6]. However, because of inconsistencies with respect to URI equivalence rules in many current URI parsers, it is RECOMMENDED that SOAP senders do NOT rely on any special equivalence rules in SOAP receivers in order to determine equivalence between URI values used in a SOAP message.

The use of IP addresses in URIs SHOULD be avoided whenever possible (see RFC 1900 [18]). However, when used, the literal format for IPv6 addresses in URI's as described by RFC 2732 [12] SHOULD be supported.

SOAP does not place any a priori limit on the length of a URI. Any SOAP node MUST be able to handle the length of any URI that it publishes and both SOAP senders and SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length.

7. Security Considerations

The SOAP Messaging Framework does not directly provide any mechanisms for dealing with access control, confidentiality, integrity and non-repudiation. Such mechanisms can either be provided as SOAP extensions using the SOAP extensibility model (see 3. SOAP Extensibility Model) or through features expressed within the underlying protocol and made available to SOAP applications through the SOAP Binding Framework (see 4. SOAP Protocol Binding Framework). This section describes the security considerations that designers and implementors should take into consideration when designing and using such mechanisms.

SOAP implementors should anticipate rogue SOAP applications sending intentionally malicious data to a SOAP node (see 2. SOAP Processing Model). Similarly, SOAP nodes should be aware of the implications of sending data to other SOAP nodes in case those nodes are malicious. It is strongly recommended that a SOAP node receiving a SOAP message is capable of evaluating to what level it can trust the sender of that SOAP message and its contents. Likewise, any SOAP node sending a SOAP message to another SOAP node should be capable of evaluating to what level it can trust the receiving SOAP node to process the message responsibly. This applies not only to ultimate SOAP receivers but also SOAP intermediaries.

7.1 SOAP Nodes

SOAP can carry application-defined data as SOAP header blocks or as SOAP body contents. Processing a SOAP header block may include dealing with side effects such as state changes, logging of information, or the generation of additional messages. It is strongly recommended that, for any deployment scenario, only carefully specified header blocks with well understood security implications of any side effects be processed by a SOAP node.

As for SOAP header blocks, processing a SOAP body may imply the occurrence of side affects that may, if not properly understood, have severe consequences for the receiving SOAP node. As for SOAP header blocks, it is strongly recommended that only well-defined body contents with known security implications be processed.

Security considerations, however, are not just limited to recognizing the immediate child elements of the SOAP header and the SOAP body. Implementors should pay special attention to the security implications of all data carried within a SOAP message that can cause the remote execution of any actions in the receiver's environment. This includes not only data expressed in XML infoset but data that may be encoded as binary data or carried as parameters, for example URI query strings. Before accepting data of any type, an application should be aware of the particular security implications associated with that data within the context it is being used.

SOAP implementors should be careful to ensure that if processing of the various parts of a SOAP message is provided through modular software architecture, that each module is aware of the overall SOAP security context. For example, a SOAP body should not be processed without knowing the SOAP context in which it was received.

7.2 SOAP Intermediaries

SOAP inherently provides a distributed processing model that may involve a SOAP message passing through multiple SOAP nodes (see 2. SOAP Processing Model). SOAP intermediaries are by definition men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Security breaches on systems that run SOAP intermediaries can result in serious security and privacy problems. A compromised SOAP intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.

In analyzing the security implications of potential SOAP related security problems, it is important to realize that the scope of security mechanisms provided by the underlying protocol may not be the same scope as the whole message path of the SOAP message. There is no requirement in SOAP that all hops between participating SOAP nodes use the same underlying protocol and even if this were the case, the very use of SOAP intermediaries is likely to reach beyond the scope of transport-level security.

7.3 Underlying Protocol Bindings

The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Binding specification authors should describe, in detail, the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification (see 4. SOAP Protocol Binding Framework).

In addition, a binding specification may not address or provide countermeasures for all aspects of the inherent security risks. The binding specification authors should identify any such risks as might remain and indicate where further countermeasures would be needed above and beyond those provided for in the binding specification.

Authors of binding specifications should be aware that SOAP extension modules expressed as SOAP header blocks may affect the underlying protocol in unforeseen ways. A SOAP message carried over a particular protocol binding may result in seemingly conflicting features. An example of this is a SOAP message carried over HTTP, using the HTTP basic authentication mechanism in combination with a SOAP based authentication mechanism. It is strongly recommended that a binding specification should describe any such interactions between the extensions and the underlying protocols.

7.3.1 Binding to Application-Specific Protocols

Some underlying protocols may be designed for a particular purpose or application profile. SOAP bindings to such protocols MAY use the same endpoint identification (e.g., TCP port number) as the underlying protocol, in order to reuse the existing infrastructure associated that protocol.

However, the use of well-known ports by SOAP may incur additional, unintended handling by intermediaries and underlying implementations. For example, HTTP is commonly thought of as a "Web browsing" protocol, and network administrators may place certain restrictions upon its use, or may interpose services such as filtering, content modification, routing, etc. Often, these services are interposed using port number as a heuristic.

As a result, binding definitions for underlying protocols with well-known default ports or application profiles SHOULD document potential interactions with commonly deployed infrastructure at those default ports or in conformance with default application profiles. Binding definitions SHOULD also illustrate the use of the binding on a non-default port as a means of avoiding unintended interaction with such services.

8. References

8.1 Normative References

[1]: W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, @@@@2002 (See soap12-part2.html.)
[2]: IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk Nielsen, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt.)
[3]: IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
[4]: W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)
[5]: W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)
[6]: IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
[7]: W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)
[8]: W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)
[9]: W3C Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 27 June 2001. (See http://www.w3.org/TR/2000/REC-xlink-20010627/.)
[10]: W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)
[11]: W3C Recommendation "XML Base", Johnathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/.)
[12]: IETF "RFC 2732: Format for Literal IPv6 Addresses in URL's", R. Hinden, B. Carpenter, L. Masinter, December 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)

8.2 Informative References

[13]: XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)
[14]: XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)
[15]: XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)
[16]: W3C Working Draft "XML Protocol (XMLP) Requirements", Vidur Apparao, Alex Ceponkus, Paul Cotton, David Ezell, David Fallside, Martin Gudgin, Oisin Hurley, John Ibbotson, R. Alexander Milowski, Kevin Mitchell, Jean-Jacques Moreau, Eric Newcomer, Henrik Frystyk Nielsen, Mark Nottingham, Waqar Sadiq, Stuart Williams, Amr Yassin, @@@@2002. This is work in progress. (See xmlp-reqs.html.)
[17]: W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/SOAP/.)
[18]: IETF "RFC 1900: Renumbering Needs Work", B. Carpenter, Y. Rekhter, February 1996. (See http://www.ietf.org/rfc/rfc1900.txt.)
[19]: IETF "RFC 1123: Requirements for Internet Hosts -- Application and Support", R. Braden, October 1989. (See http://www.ietf.org/rfc/rfc1123.txt.)
[20]: IETF "RFC 793: Transmission Control Protocol", DARPA, September 1981. (See http://www.ietf.org/rfc/rfc793.txt.)

A. Version Transition From SOAP/1.1 to SOAP Version 1.2

The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:

A SOAP/1.1 node receiving a SOAP Version 1.2 message will according to SOAP/1.1 generate a version mismatch SOAP fault based on a SOAP/1.1 message construct. That is, the envelope will have a local name of Envelope and a namespace name of "http://schemas.xmlsoap.org/soap/envelope/".
A SOAP Version 1.2 node receiving a SOAP/1.1 message either:
- MAY process the message as a SOAP/1.1 message (if supported), or
- MUST generate a version mismatch SOAP fault based on a SOAP/1.1 message construct following SOAP/1.1 semantics. The SOAP fault SHOULD include an Upgrade header block as defined in this specification (see 5.4.7 VersionMismatch Faults) indicating support for SOAP Version 1.2. This allows a receiving SOAP/1.1 node to correctly interpret the SOAP fault generated by the SOAP Version 1.2 node.

The example below shows a version mismatch SOAP fault generated by a SOAP Version 1.2 node as a result of receiving a SOAP/1.1 message. The fault message is a SOAP/1.1 message with an Upgrade header block indicating support for SOAP Version 1.2.

Example 7: SOAP Version 1.2 node generating a SOAP/1.1 version mismatch fault message including an Upgrade header block indicating support for SOAP Version 1.2.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 <env:Header>
  <V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-upgrade">
   <envelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2001/12/soap-envelope"/>
   </V:Upgrade>
  </env:Header>
  <env:Body>
   <env:Fault>
    <faultcode>env:VersionMismatch</faultcode>
    <faultstring>Version Mismatch</faultstring>
   </env:Fault>
 </env:Body>
</env:Envelope>

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.

B. Acknowledgements (Non-Normative)

This specification is the work of the W3C XML Protocol Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), Charles Campbell (Informix Software), Michael Champion (Software AG), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Colleen Evans (Progress Software), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dietmar Gaertner (Software AG), Rich Greenfield (Library of Congress), Martin Gudgin (DevelopMentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Henry Lowe (OMG), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Highland Mary Mountain (Intel), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (BEA Systems), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Herve Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Asir Vedamuthu (webMethods) Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Jin Yu (Martsoft Corp.).

Previous members were: Eric Fedok (Active Data Exchange), Susan Yee (Active Data Exchange), Dan Frantz (BEA Systems), Alex Ceponkus (Bowstreet), James Tauber (Bowstreet), Rekha Nagarajan (Calico Commerce), Mary Holstege (Calico Commerce), Krishna Sankar (Cisco Systems), David Burdett (Commerce One), Murray Maloney (Commerce One), Jay Kasi (Commerce One), Yan Xu (DataChannel), Brian Eisenberg (DataChannel), Mike Dierken (DataChannel), Michael Freeman (Engenia Software), Bjoern Heckel (Epicentric), Dean Moses (Epicentric), Julian Kumar (Epicentric), Miles Chaston (Epicentric), Alan Kropp (Epicentric), Scott Golubock (Epicentric), Michael Freeman (Engenia Software), Jim Hughes (Fujitsu Limited), Dick Brooks (Group 8760), David Ezell (Hewlett Packard), Fransisco Cubera (IBM), David Orchard (Jamcracker), Alex Milowski (Lexica), Steve Hole (MessagingDirect Ltd.), John-Paul Sicotte (MessagingDirect Ltd.), Vilhelm Rosenqvist (NCR), Lew Shannon (NCR), Art Nevarez (Novell, Inc.), David Clay (Oracle), Jim Trezzo (Oracle), David Cleary (Progress Software), Andrew Eisenberg (Progress Software), Peter Lecuyer (Progress Software), Ed Mooney (Sun Microsystems), Mark Baker (Sun Microsystems), Anne Thomas Manes (Sun Microsystems), George Scott (Tradia Inc.), Erin Hoffmann (Tradia Inc.), Conleth O'Connell (Vignette), Waqar Sadiq (Vitria Technology Inc.), Randy Waldrop (WebMethods), Bill Anderson (Xerox), Tom Breuel (Xerox), Matthew MacKenzie (XMLGlobal Technologies), David Webber (XMLGlobal Technologies), John Evdemon (XMLSolutions) and Kevin Mitchell (XMLSolutions).

The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.

C. Part 1 Change Log (Non-Normative)

C.1 SOAP Specification Changes

Date	Author	Description
20020509	MJH	Added issue 194 resolution - encodingStyle.
20020509	MJG	Changed fault construct in example 7 back to SOAP 1.1 format
20020506	JJM	Removed double-spaces.
20020506	JJM	Fixed typos.
20020503	MJH	Added table cross references.
20020503	JJM	Added back streaming stuff, after CVS hick-up.
20020502	MJH	Decapitalised node and messaging framework in common with part 2.
20020502	JJM	Readability edits for the Abstract.
20020502	JJM	Added back "This is the case, for example, when a block has survived erronously due to a routing or targeting error at a preceeding intermediairy." due to popular demand.
20020502	JJM	Incorporated the readability comments on appendix A.
20020502	JJM	Incorporated the readability comments on section 7 and 6.
20020430	JJM	Incorporated the readability comments on section 5 and 6.
20020430	JJM	Incorporated the readability comments on section 1, 2, 3 and 4.
20020426	JJM	Updated member list.
20020426	MJH	Removed SOAPAction mentions.
20020425	MJH	Added issue 192 resolution.
20020425	MJG	Qualified children of fault, changed local names.
20020425	MJG	Added xspecref to xml:lang
20020425	JJM	Added resolution to issue #201.
20020425	JJM	Added resolution to issue #199.
20020425	JJM	Added resolution to issue #202.
20020425	JJM	Added resolution to issue #203.
20020412	HFN	Added reference from section 2.6 Processing SOAP Messages to 2.7 Relaying SOAP Messages
20020411	MJH	Removed pt2 TOC from intro and cleaned up abstract.
20020410	MJG	Added ids to several divs.
20020410	MJH	Made intro and abstract consistent with pt 2.
20020409	MJH	Added issue 187 resolution.
20020409	JJM	Implemented Noah's comment on the resolution of issue #190 (MAY, but need not).
20020408	JJM	Fixed an incorrect reference to SOAP MEP.
20020408	JJM	Wordsmithing from Chris on a paragraph from Noah amended by JJM.
20020408	MJG	Upgraded section 5.4.1.2.1 to section 5.4.1.3 ( formatting problem)
20020408	JJM	Downgraded part of section 3 to section 3.1.
20020405	MJH	Incorporated most of Noah's most significant comments.
20020405	MJG	Updated description of faultcode entries (5.4.1) to state that the element children must appear in order (now matches 5.4.1.2
20020405	MJG	Updated description of detail entries (5.4.5.1) to state that element and character children are allowed, as are other attributes
20020405	JJM	Incorporated Noah's moderate comments. Raised two issues. Waiting for Gudge's input on two comments.
20020405	JJM	Incorporated Noah's minor comments.
20020404	JJM	Moved the beginning of section "6.0 MEPs" from part 2 as "3.2 MEPs", as suggested by Noah.
20020403	MJG	Modified various infoset property references in Section 5
20020403	MJG	Changed faultactor to faultnode
20020403	JJM	Use sub-bullets to clearly differentiate what the specification for a feature MUST include.
20020403	JJM	Back out the change made to the 1st paragraph of Section 2.7.1 "SOAP intermediaries". Revert to the previous text.
20020403	MJG	Added prose concerning properties of the Document Information Item to Section 5
20020403	JJM	Factorized the common elements in the 1st and 2nd paragraphs from section "SOAP Extensibility Model"
20020403	JJM	Wordsmithing for "Use of SOAP header block Attributes" section.
20020403	JJM	Wordsmithing for "Intermediaries" section.
20020403	JJM	Incorporated the resolution for issue 191, including Henrik's friendly amendments.
20020329	JJM	Removed redundant information in section 5.4.6 SOAP fault codes (the "table below" was referenced 3 times in almost consecutive sentences).
20020329	JJM	Rearranged the order of paragraphs in the 5.4.x fault subsections. Specifically, moved at the top of each section the sentence that describes that section; previously, this sentence was buried further down the section. These sections are now consistently presented as the other 5.x sections.
20020329	JJM	Fixed a number of typos. Added two missing specrefs. Fixed a few must, should or may that should be capitalized.
20020329	JJM	Finished replacing (global replaced) "the ultimate receiver" with "an ultimate receiver", a task originally started by Henrik.
20020329	JJM	Removed the following paragraph from section 1.1 Notational Conventions, since this is already covered Section 1.2 Relationship with other XML Specifications: "A normative XML Schema document for the http://www.w3.org/2001/12/soap-envelope namespace can be found at http://www.w3.org/2001/12/soap-envelope".
20020329	JJM	Adapted the Abstract, so that the description of Part2 is in synch with the Introduction (last paragraph).
20020329	JJM	Section 4.2 Binding Framework, removed the 2nd sentence from the 4th paragraph: "A Binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those features.", since this is already covered (with greater details) in Section 3 Extensibility.
20020327	JJM	Removed extra spaces around parenthesis, dot, semi-colon and comma.
20020326	JJM	Added definition for MEP to the glossary.
20020326	HFN	Removed the word "XML encoding of SOAP" in section 1.2.1 Processing Requirementsas it is not an encoding.
20020326	HFN	Demoted sections 1.2.1 Processing Requirements and 1.2.2 Robustness Principle to be part of section 1.2 Relation to other XML Specifications as they all talk about relations to other specs.
20020326	HFN	Moved paragraph "SOAP attribute information items have types described by XML Schema..." to 1.2.2 Robustness Principle as this is referenced in several places and it fits better there.
20020326	HFN	Changed reference in glossary description to point to SOAP extensibility section and added reference in that section to part 2's example of a MEP specification.
20020326	HFN	Moved the requirements to writing a feature spec from the protocol binding section to the extensibility section as it belongs better there.
20020322	HFN	Changed mU='1' with mu='true' in examples.
20020322	HFN	Fixed section names in cross references to part 2
20020322	HFN	Changed all occurrences of 'recipient' to 'receiver' and 'ultimate' receiver' to 'ultimate SOAP receiver'
20020322	HFN	Reordered spec as follows: introduction processing model extensibility model binding framework envelope construct URI Security
20020322	HFN	Added resolution for issue 176
20020322	MJG	Added clause regarding whitespace characters to infoset description of Envelope, Header and Body.
20020322	MJH	changed all namespace identifiers, URIs to names.
20020322	MJH	removed links in NS URIs.
20020322	MJH	Added in David F review changes.
20020322	JJM	Incorporated Henrik's comments on 1.3 and 1.4.
20020321	MJH	Issue 174 changes.
20020321	MJH	Made styling of URIs consistent throughout.
20020321	MJH	Made styling of references to infoset terms consistent throughout.
20020321	MJH	Made references to faults and fault codes consistent throughout.
20020311	HFN	Say that versioning is determined based on the namespace name AND local name of the document information item. If the namespace name AND local name doesn't match then generate a VersionMismatch fault.
20020311	HFN	Say that ALL VersionMismatch faults SHOULD use the Upgrade header block for describing which revision they support. Editorially, this means moving the description of the Upgrade header block into section 3.4 rather than having it in appendix
20020311	HFN	Make it clear that SOAP/1.1 is ONLY used it VersionMismatch fault IF the sender is a SOAP/1.1 node. Otherwise, use SOAP 1.2 envelope.
20020311	HFN	Turned into a note: "Note that when serializing the `qname` attribute information item there must be an in-scope namespace declaration for the namespace name of the misunderstood header and the value of the attribute information item must use the prefix of such a namespace declaration"
20020311	HFN	In section 5.4.8 Must Understand Faults moved last paragraph to beginning and made the requirements to a SOAP node clear (was written as a note)
20020311	HFN	Moved section on Upgrade fault element from appendix to section 3.4 in a manner similar to the MustUnderstand fault subsection in the same section.
20020314	HFN	Added reference to 5.4 SOAP Fault for issue 182 resolution.
20020320	JJM	Incorporated resolution to issue 40.
20020320	JJM	Incorporated resolution for issue 183, including amendments from Noah (and taking into account later comments from Noah on Part 1).
20020320	JJM	Updated cross-references from saying "bibref" "xspecref" to "bibref" section "xspecref". Otherwise the generated HTML looked funny (the links were back to back) [Ednote issue #33]
20020320	JJM	More generally, made all "bibrefs" more uniform.
20020318	HFN	The section on SOAP Extensibility (see 3. SOAP Extensibility Model) showed signs of originally being the introduction to the Protocol Binding Framework (see 4. SOAP Protocol Binding Framework) and needed some editorial work in order to stand on its own. This section was "promoted" to a top-level section by simply moving it out of section 4. SOAP Protocol Binding Framework. The text is now rebalanced. There should be no semantic changes, merely a rewrite to make it more clear what we mean by features. The involved sections are section 3. SOAP Extensibility Model, the introduction of 4. SOAP Protocol Binding Framework, and section 4.1 Goals of the Binding Framework.
20020318	JJM	Removed duplication between section "2.5 Structure and Interpretation of SOAP Bodies" and section "3.3 SOAP Body".
20020318	JJM	Trimmed down the introductions to the sub-sections of section 3, in a way Henrik and I both feel comfortable with.
20020318	JJM	Finished incorporating Noah's comments on Part1, albeit two issues raised separately.
20020315	HFN	Lower-cased MAY in the last paragraph in section 2.6 Processing SOAP Messages as these are not requirements on anything in our spec and the paragraph is a note in the first place.
20020316	HFN	In the introduction, changed the word "transmit" to "exchange" in places where transmit and receive is implied.
20020316	HFN	In the introduction, removed reference to header block and body before these are introduced.
20020314	HFN	Added reference to 5.4 SOAP Fault for issue 182 resolution.
20020312	HFN	In section 5.1 SOAP Envelope, changed: "The document element information item has:..." with "The `Envelope` element information item has:..."
20020314	JJM	Added back comments from Noah
20020314	JJM	Added revised definition for ultimate receiver, after Henrik and Noah's approval.
20020312	MJH	Added issue 182 resolution.
20020311	HFN	Glossary: added "feature": "An abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes (see 3. SOAP Extensibility Model). Examples of features include "reliability", "security", "correlation", "routing", and the concept of message exchange patterns."
20020311	HFN	Glossary: moved "soap application" under "protocol concepts" (was in "Message Sender and Receiver Concepts") as it belongs better there.
20020310	HFN	Clarified example in section 1.3
20020310	HFN	Made cross references consistent of the form (see X)
20020310	HFN	Made editorial changes to section Envelope Versioning Model and moved to section 2 as it is a part of the processing model
20020310	HFN	Added XML Protocol requirements document as a non-normative reference
20020310	HFN	Removed paragraph as it is no longer used: "The namespace prefixes "xs" and "xsi" used in the prose sections of this document are associated with the namespace names "http://www.w3.org/2001/XMLSchema" and "http://www.w3.org/2001/XMLSchema-instance" respectively, both of which are defined in the XML Schema specifications [4], [5]."
20020310	HFN	Removed paragraph as it is no longer used: "The namespace prefixes "env" used in the prose sections of this document are associated with the SOAP namespace names "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" respectively."
20020310	HFN	Updated example in section 3.1.2: the description of the encodingStyle attribute: it was written as if it is part of the encoding schema, it is not
20020310	HFN	Updated introduction to read better and removed section 1.1 Design Goals as this is now part of the general introduction
20020310	HFN	Changed "SOAP Message Structure" to "SOAP Message Construct" as a) I think it is more appropriate and b) It doesn't confuse the use of structure used elsewhere in the document.
20020310	HFN	Updated abstract to read better
20020308	HFN	Incorporated resolution to issue 137
20020305	JJM	Started incorporating Noah's comments on the latest ed's copy.
20020304	HFN	Changed "It is based on XML..." to "It is based on XML Infoset..."
20020304	HFN	Restructured section 3 and moved to section 1 as 1.3 "Relation to other XML Specifications"
20020304	HFN	Removed the following paragraph from (new) 1.3 as it is duplicated in section 4: "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 described in 2.8 SOAP Versioning Model."
20020304	HFN	Moved the following paragraph to section 4 as it enables us to gather all strict requirements in one place. "People get confused if there are requirements spread out all over the place. 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 5.4 SOAP Fault) with a fault code of "DTDNotSupported". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives."
20020304	HFN	Added text to (new) 1.3 to clarify relationship with XML namespaces, XML base, and XML schema.
20020304	HFN	Clarified relationship to schema based on Noah's formulation
20020324	HFN	Renamed "4 SOAP Envelope" to "4 SOAP Message Structure" and introduced a new section called 4.1 "SOAP Envelope"
20020324	HFN	Removed the heading in section 4.1 "Envelope Encoding and Versioning" and promoted section 4.1.1 and 4.1.2 to 4.1 and 4.2 respectively (I reordered them as I think the versioning model is more important).
20020324	HFN	In section "SOAP encodingStyle Attribute" modified the paragraph to say that encodingStyle can't appear on the Envelope information item
20020324	HFN	As per Gudge's suggestion, moved SOAP Extensibility Model to section 3 just after the processing model.
20020228	HFN	Updated abstract slightly
20020228	HFN	Incorporated resolution to issue 178
20020228	HFN	Insert resolution to issue 179, replacing 'support' with 'enable'
20020228	HFN	Insert resolution of issue 103 with the following modifications; a) "Normally" with "in the absence of faults" b) "recipient" with "receiver" c) "the ultimate" with "an ultimate"
20020228	HFN	Move section 6.3 into 6.4 and add security considerations text.
20020228	HFN	Added first part of resolution of issue 59: "It is the responsibility of transport bindings to specify how the infoset is being transferred to and reconstituted by the binding at the receiving node. Such a binding, if using XML 1.0 serialization of the infoset, may mandate that a particular character encoding or set of encodings be used."
20020221	MJG	Edited examples so that no line is longer than 66 characters
20020219	HFN	Updated section 7: removed reference to href and clarified suggestion for length of URIs.
20020219	MJG	Qualified encoding attributes in examples.
20020218	HFN	Added resolution text for issue 102: "and rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP"
20020216	MJG	Added text to Section 3 explaining where schema documents are located
20020216	MJG	Added hierarchical fault types to soap-envelope schema
20020215	MJH	Inserted section 2 rewrite and associated changes to section 4.
20020215	HFN	Promoted section 5.1 to top-level section 5 and moved the rest of the old section 5 to top-level section 6
20020131	MJH	Removed the sentence that said that an encodingStyle value that was prefixed with the SOAP encoding style URI indicated a restricted version of the SOAP encoding. This change was agreed on the conf call of 20020130, but no issue existed for it.
20020131	MJH	Removed old ednote asking for feedback on the new requirement that direct children of the body be namespace qualified.
20020131	MJH	Fixed text on Body element to match schema. This change was agreed on the conf call of 20020130 but no issue existed for it. Body element allows zero or more unspecified attribute information items including encodingStyle. Removed ednotes that previously highlighted the removed contradiction.
20020129	MJH	Removed duplication in list of goals of binding framework (Sect 5.2).
20020121	MJH	Rolled in most of the suggested editorial changes from John Ibbotson. Section 2 not changed.
20020117	MJH	Added hierarchical fault codes (issue 173).
20011213	MJH	Updated namespace URIs, fixed spelling error.
20011211	MJH	Added section headings for faultcode, faultstring, faultactor and detail elements.
20011211	MJH	Fixed a number of spelling errors and grammatical problems throughout the document. Applied some limited rewording to improve readability.
20011211	MJH	Removed duplicate description of "must happen" extension from section 2.
20011206	MJH	Removed more mentions of body blocks.
20011206	MJH	Limited rewording and removal of duplication from section 2. In particular, removed namespace definition for mU and actor (this is in section 4) and massaged text in processing model to remove duplication and improve readability.
20011206	MJH	Incorporated Chris Ferris suggested changes to glossary and section 2.
20011206	MJH	General editorial work on new sections. Added references and other tagging as required.
20011206	MJH	Incorporated agreed changes to URIs in SOAP section (remove duplication with XML base and cite XML base more strongly).
20011206	MJH	Incorporated issue 155 resolution.
20011205	JJM	Elevated the header removal step to a processing model step.
20011204	MJH	Added bibref to Use of URIs section and tidied up the language in that section.
20011204	MJH	Modified soapEncoding descriptive text - Issues 159 and 166.
20011204	JJM	Added text to section 2.2, second paragraph, to indicate none blocks may carry data for processing of other blocks.
20011204	JJM	Section 2.2, four paragraph, added "anonymous actor" to the list.
20011204	JJM	Section 2.3, remove text for SOAP body blocks.
20011204	JJM	Section 2.3, replace "has assumed the role of the anonymous actor" by "is the ultimate receiver".
20011204	JJM	Section 2.4, incorporated 2 paragraph previously in section 2.
20011204	JJM	Added section 2.5 (text from Noah).
20011204	JJM	Added an extra step to the processing model (now section 2.6).
20011204	JJM	Simplified step 3, and moved the previous text further below in the same section (2.6).
20011204	JJM	Section 2.6, incorporated text from section 4.
20011204	JJM	Section 4.2.2, removed explanation of next and none roles.
20011204	JJM	Section 4.2.2, added text to indicate the meaning of an empty actor attribute.
20011204	JJM	Trimmed section 4.2.3, as the text is now in section 2.
20011204	JJM	Removed section 4.3.1, since body processing is now in section 2.6.
20011204	JJM	Added ednote to flag the definition for SOAP block is out of date.
20011204	JJM	Reformatted section 5 (Binding Framework).
20011204	JJM	Reformatted section 6 (Use of URIs in SOAP). Removed non ASCII characters.
20011204	JJM	Added missing "att" and "attval" around elements and attributes in section 6.
20011204	JJM	Fixed a number of lax references in section 6.
20011201	HFN	Added SOAP Protocol Binding Framework
20011201	HFN	Added section on URIs and XML Base
2001129	MJG	Incorporated resolution text for Issue 146 into Section 2.3
2001129	MJG	Changed "Client" and "Server" fault codes to be "Sender" and "Receiver" respectively as resolution of Issue 143
2001129	MJG	Removed dot notation from spec. Added "DTDNotSupported" fault code to fault code table.
20011122	MJH	Incorporated resolution to issue 172 (criteria for generating version mismatch fault into 2.8 SOAP Versioning Model. Removed duplication of versioning error text and associated ednote from 1.2 Relation to other XML Specifications
20011029	MJH	Changed "default actor" to "anonymous actor".
20011029	MJH	Amended relation to XML section (Issue 135).
20011029	MJH	Amended section 2.5 (Issue 157).
20011029	MJH	Removed citation of ABNF - not used in part 1.
20011029	MJH	Amended section 1.3 (Issue 150)
20011029	MJH	Amended section 1.1 (Issue 149)
20011029	MJH	Amended introductory text (Issue 148)
20011029	MJH	Amended introductory text (Issue 147)
20011029	MJH	Amended abstract (Issue 147)
20011026	MJG	Amended text in Section 2.5 bullet 2 (Issue 158)
20011026	MJG	Amended text in Section 2.4 para 2 (Issue 156)
20011026	MJG	Amended text in Section 2.1 para 2 (Issue 152)
20011026	MJG	Amended prose related to DTDs and PIs (Issue 4)
20011026	MJG	Added text to state that SOAP is no longer an acronym (Issue 125)
20011026	MJG	Amended description of Upgrade extension in Appendix A to be Infoset based.
20011026	MJG	Added an example of returning multiple versions in the VersionMismatch header to Appendix A ( Issue 119)
20011026	MJG	Added definition of SOAP Application to glossary (Issue 139)
20011026	MJG	Added xml declaration to all XML examples with a root of env:Envelope or xs:schema (Issue 10)
20011025	MJG	Changed MAY to MUST regarding namespace qualification of SOAP body blocks (Issue 141)
20011011	MJG	Added para to section 2.2 on criteria (or lack thereof) for determining whether a SOAP node acts as a particular actor
20010926	MJG	Updated member list
20010926	MJG	Removed extra double quotes around certain URLs
20010921	MJG	Changed targetNamespace attribute of faults schema to http://www.w3.org/2001/09/soap-faults
20010921	MJG	Changed targetNamespace attribute of upgrade schema to http://www.w3.org/2001/09/soap-upgrade
20010921	MJG	Changed targetNamespace attribute of envelope schema to http://www.w3.org/2001/09/soap-envelope
20010921	MJG	Modified content model of Envelope complex type in envelope schema to disallow content after the Body element.
20010920	JJM	Included MarkN's text regarding issue 11 and 13 as amended by Stuart in the specification and expand the ednote appropriately.
20010920	JJM	Change the namespace of the envelope to http://www.w3.org/2001/09/...
20010918	JJM	Incorporated several editorial comments from Stuart Williams.
20010918	JJM	Removed reference to trailer from the "SOAP Envelope" section.
20010914	JJM	Fixed issues 124, 126, 127, 128 and 132.
20010914	JJM	Used the rewrite from Mark Nottingham for section "SOAPAction attribute".
20010914	JJM	Incorporated text from Mark Nottingham clarifying the role of none blocks.
20010914	JJM	Reference the XML InfoSet Proposed Recommendation instead of the Candidate Recommendation.
20010911	JJM	Changed XML Information Set into a normative reference. Changed XML Protocol Comments Archive, Discussion Archive and Charter into non-normative references. Removed "as illustrated above" from section 2. Added missing parentheses in sections 2.5 and 4.1.1.
20010905	MJH	Wordsmithed abstract and introduction to better reflect split into parts 1 and 2. Rationalised list of references so only cited works appear. Removed encoding schema changes. Added bibref entries for cross references to Part 2, fixed links so they target the HTML instead of XML version of the doc.
20010831	JJM	Added a close paragraph tag before starting a new olist or ulist.
20010831	JJM	Properly declared the language for the spec, so that we can generate valid HTML.
20010830	MJG	Added an element declaration for a Fault element of type Fault to the envelope schema
20010830	JJM	Removed terminology not relevant for part1.
20010830	JJM	Moved some introductory examples to part2.
20010830	JJM	Moved SOAP example appendix to part2.
20010830	JJM	Added a paragraph to section 1 pointing to part2 for encoding, rpc and http binding.
20010829	JJM	Added a placeholder for the forthcoming Transport Binding Framework section.
20010829	JJM	Updated the spec's title.
20010829	JJM	Replaced specref with xspecref for references to Part2 items.
20010829	JJM	Added bibliography entry for SOAP 1.2 Part 2.
20010829	JJM	Removed former sections 5, 6, 7 and 8.
20010829	JJM	Did split the spec into two parts.
20010829	JJM	Referred to the proper DTD and stylesheet.
20010829	JJM	Updated the list of WG members: one person per line in the XML file, for easier updating.
20010816	MJH	Replaced a mustUnderstand="1" with mustUnderstand="true". Slight rewording in mu description.
20010810	MJH	Merged in RPC fault rules text from Jacek. Added new DataEncodingUnknown fault code to SOAP Fault Codes section. Added editorial notes about introduction of new fault code namespace for RPC.
20010809	MJH	Merged in "mustHappen" descriptive text from Glen and Noah.
20010809	MJH	Fixed language around "default" values of attributes.
20010809	MJH	Removed HTTP extension framework, added editorial note to describe why.
20010808	MJH	Added Infoset "specified" property text from Chris.
20010808	MJH	Removed assumption 4 from version transition appendix.
20010808	MJH	Added reference to SOAP 1.1 specification to references section, removed SOAP 1.1 author list from acknowledgments section.
20010807	MJH	Converted specification from HTML to XML conforming to W3C XMLSpec DTD. Numerous resulting formatting changes.
20010720	MJG	Applied Infoset terminology to sections 1, 2, 3 and 4.
20010629	MJG	Amended description of routing and intermediaries in Section 2.1
20010629	JJM	Changed "latest version" URI to end with soap12а
20010629	JJM	Remove "previous version" URI
20010629	JJM	Removed "Editor copy" in <title>
20010629	JJM	Removed "Editor copy" in the title.
20010629	JJM	Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft.
20010629	JJM	Pre-filed publication URIs.
20010629	JJM	Incorporated David's suggested changes for the examples in section 4.1.1 to 4.4.2
20010629	JJM	Fixed some remaining typos.
20010629	MJH	Fixed a couple of typos.
20010628	MJG	Made various formatting, spelling and grammatical fixes.
20010628	MJG	Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50
20010628	MJG	Changed text in Section 2.1 from 'it is both a SOAP sender or a SOAP receiver' to 'it is both a SOAP sender and a SOAP receiver'
20010628	MJG	Fixed caption on Example 24
20010628	MJH	Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence.
20010628	MJH	Updated figure 1, removed ednote to do so.
20010622	HFN	Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model.
20010622	HFN	Moved the definition of block to encapsulation section in terminology
20010622	HFN	Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and doesn't belong in a terminology section
20010622	HFN	Removed reference to "Web Characterization Terminology & Definitions Sheet" in terminology section as this is not an active WD
20010622	HFN	Added revised glossary
20010622	HFN	Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding
20010622	MJG	Added http://example.com/... to list of application/context specific URIs in section 1.2
20010622	MJG	Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes
20010622	MJG	Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1
20010622	MJG	In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match.
20010622	MJG	Moved MisunderstoodHeader from envelope schema into separate faults schema. Removed entry in envelope schema change table in Appendix D.2 that referred to addition of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2
20010622	MJH	Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions.
20010622	MJG	Made BNF in section 6.1.1 into a table.
20010622	MJG	Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet
20010622	MJG	Amended text regarding namespace prefix mappings in section 1.2
20010622	MJG	Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote.
20010622	MJG	Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document
20010622	MJG	Reordered entries in schema change classification table in Appendix D.2
20010622	MJG	Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly
20010622	JJM	Manually numbered all the examples (53 in total!)
20010622	JJM	Added caption text to all the examples
20010622	JJM	Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>)
20010621	HFN	Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2
20010621	HFN	Added version transition appendix C
20010621	HFN	Applied new styles to examples
20010621	HFN	Changed term "transport" to "underlying protocol
20010621	HFN	Changed example URNs to URLs of the style http://example.org/...
20010621	MJH	Updated the Acknowledgements section.
20010621	JJM	Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2.
20010621	JJM	Incorporated David Fallside's comments on section Status and Intro sections.
20010620	HFN	Changed the status section
20010620	HFN	Changed title to SOAP Version 1.2 and used that first time in abstract and in body
20010620	HFN	Removed question from section 2.4 as this is an issue and is to be listed in the issues list
20010620	HFN	Moved change log to appendix
20010615	JJM	Renamed default actor to anonymous actor for now (to be consistent)
20010615	JJM	Fixed typos in section 2
20010614	JJM	Updated section 2 to adopt the terminology used elsewhere in the spec.
20010613	MJH	Updated mustUnderstand fault text with additions from Martin Gudgin.
20010613	MJH	Added schema changes appendix from Martin Gudgin.
20010613	MJH	Added mustUnderstand fault text from Glen Daniels.
20010612	MJH	Fixed document <title>.
20010612	MJH	Moved terminology subsection from message exchange model section to introduction section.
20010612	MJH	Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate.
20010612	MJH	Removed trailing "/" from encoding namespace URI.
20010612	MJH	Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org.
20010612	MJH	Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places.
20010611	MJH	Incorporated new text for section 2.
20010611	JJM	Changed remaining namespaces, in particular next.
20010609	JJM	Changed the spec name from XMLP/SOAP to SOAP.
20010609	JJM	Changed the version number from 1.1 to 1.2.
20010609	JJM	Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-.
20010609	JJM	Replaced the remaining XS and XE prefixes to env and enc, respectively.
20010601	MJH	Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation.
20010601	JJM	Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation.
20010531	HFN	Removed appendices C and D and added links to live issues list and separate schema files.
20010531	MJH	Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation.

C.2 XML Schema Changes

The envelope schema has been updated to be compliant with the XML Schema Recomendation[4][5]. The table below shows the categories of change.

Table 4: Schema Change Categorisation
Class	Meaning
Addition	New constructs have been added to the schema
Clarification	The meaning of the schema has been changed to more accurately match the specification
Deletion	Constructs have been removed from the schema
Name	The schema has been changed due to a datatype name change in the XML Schema specification
Namespace	A namespace name has been changed
Semantic	The meaning of the schema has been changed
Style	Style changes have been made to the schema
Syntax	The syntax of the schema has been updated due to changes in the XML Schema specification

The table below lists the changes to the envelope schema.

Table 5: Changes to Envelope Schema
Class	Description
Namespace	Updated to use the http://www.w3.org/2001/XMLSchema namespace
Namespace	Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-envelope
Clarification	Changed element and attribute wildcards in Envelope complex type to namespace="##other"
Clarification	Changed element and attribute wildcards in Header complex type to namespace="##other"
Clarification	Added explicit namespace="##any" to element and attribute wildcards in Body complex type
Clarification	Added explicit namespace="##any" to element and attribute wildcards in detail complex type
Clarification	Added an element wildcard with namespace="##other" to the Fault complex type
Name	Changed item type of encodingStyle from uri-reference to anyURI
Name	Changed type of actor attribute from uri-reference to anyURI
Name	Changed type of faultactor attribute from uri-reference to anyURI
Semantic	Added processContents="lax" to all element and attribute wildcards
Semantic	Changed type of the mustUnderstand attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed.
Style	Where possible comments have been changed into annotations
Syntax	Changed all occurrences of maxOccurs="*" to maxOccurs="unbounded"
Syntax	Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type
Syntax	Added <xs:sequence> to all named model group definitions
Name	Changed local name of faultcode element to Code
Name	Changed local name of value element to Value
Name	Changed local name of subcode element to Subcode
Name	Changed local name of faultstring element to Reason
Name	Changed local name of faultactor element to Node
Addition	Added Role element
Name	Changed local name of detail element to Detail
Semantic	Made all local element declaration declare qualified elements

In addition several changes occured in the names of datatypes in the XML Schema specification and some datatypes were removed. The following table lists those changes.

Table 6: Changes Resulting from Changes to XML Schema Specification
Datatype	Class	Description
timeDuration	Renamed	New name is duration
timeInstant	Renamed	New name is dateTime
recurringDuration	Removed	The recurringDuration datatype no longer exists.
recurringInstant	Removed	The recurringInstant datatype no longer exists.
binary	Removed	The binary datatype has been replaced by the hexBinary and base64Binary datatypes.
month	Renamed	New name is gYearMonth
timePeriod	Removed	The timePeriod datatype no longer exists
year	Renamed	New name is gYear
century	Removed	The century datatype no longer exists
recurringDate	Renamed	New name is gMonthDay
recurringDay	Renamed	New name is gDay

SOAP Version 1.2 Part 1: Messaging Framework

Editors' Copy May 14 2002

Abstract

Status of this Document

Short Table of Contents

Table of Contents

Appendices

1. Introduction

1.1 Notational Conventions

1.2 Relation to other XML Specifications

1.2.1 Processing Requirements

1.2.2 Robustness Principle

1.3 Example SOAP Message

1.4 SOAP Terminology

1.4.1 Protocol Concepts

1.4.2 Data Encapsulation Concepts

1.4.3 Message Sender and Receiver Concepts

2. SOAP Processing Model

2.1 SOAP Nodes

2.2 SOAP Roles and SOAP Nodes

2.3 Targeting SOAP Header Blocks

2.4 Understanding SOAP Headers

2.5 Structure and Interpretation of SOAP Bodies

2.6 Processing SOAP Messages

2.7 Relaying SOAP Messages

2.7.1 Forwarding Intermediaries

2.7.2 Active Intermediaries

2.8 SOAP Versioning Model

3. SOAP Extensibility Model

3.1 SOAP Features

3.1.1 Requirements on Features

3.2 SOAP Modules

3.3 SOAP Message Exchange Patterns (MEPs)

4. SOAP Protocol Binding Framework

4.1 Goals of the Binding Framework

4.2 Binding Framework

5. SOAP Message Construct

5.1 SOAP Envelope

5.1.1 SOAP encodingStyle Attribute

5.2 SOAP Header

5.2.1 SOAP header block

5.2.2 SOAP role Attribute

5.2.3 SOAP mustUnderstand Attribute

5.3 SOAP Body

5.3.1 SOAP Body child Element

5.4 SOAP Fault

5.4.1 SOAP Code Element

5.4.1.1 SOAP Value element (with Code parent)

5.4.1.2 SOAP Subcode element

5.4.1.3 SOAP Value element (with Subcode parent)

5.4.2 SOAP Reason Element

5.4.3 SOAP Node Element

5.4.4 SOAP Role Element

5.4.5 SOAP Detail Element

5.4.5.1 SOAP detail entry

5.4.6 SOAP Fault Codes

5.4.7 VersionMismatch Faults

5.4.8 Must Understand Faults

6. Use of URIs in SOAP

7. Security Considerations

7.1 SOAP Nodes

7.2 SOAP Intermediaries

7.3 Underlying Protocol Bindings

7.3.1 Binding to Application-Specific Protocols

8. References

8.1 Normative References

8.2 Informative References

A. Version Transition From SOAP/1.1 to SOAP Version 1.2

B. Acknowledgements (Non-Normative)

C. Part 1 Change Log (Non-Normative)

C.1 SOAP Specification Changes

C.2 XML Schema Changes