SOAP Version 1.2 Part 1: Messaging Framework

Editors Copy $Date: 2002/11/08 17:54:58 $ @@ @@ @@

This version:
soap12-part1.html
Latest version:
http://www.w3.org/TR/soap12-part1
Previous versions:
http://www.w3.org/TR/2001/WD-soap12-part1-20011217
Editors:
Martin Gudgin, Microsoft
Marc Hadley, Sun Microsystems
Noah Mendelsohn, IBM
Jean-Jacques Moreau, Canon
Henrik Frystyk Nielsen, Microsoft

Abstract

SOAP Version 1.2 is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. "Part 1: Messaging Framework" defines, using XML technologies, an extensible messaging framework containing a message construct that can be exchanged over a variety of underlying protocols.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is the W3C Last Call Working Draft of the SOAP Version 1.2 specification for review by W3C members and other interested parties. It has been produced by the XML Protocol Working Group (WG), which is part of the Web Services Activity.

This document references "The 'application/soap+xml' media type" Internet Draft [SOAP MediaType] which defines the "application/soap+xml" media type. The XML Protocol Working Group intends to use [SOAP MediaType] in an IANA application to register the "application/soap+xml" media type. The Working Group also intends to incorporate the technical content of [SOAP MediaType] into a near future version of SOAP Version 1.2 Part 2, and to maintain that content as part of the SOAP specification.

Following completion of Last Call, the XML Protocol Working Group has agreed to advance the specification according to four exit criteria:

  1. Sufficient reports of implementation experience have been gathered to demonstrate that SOAP processors based on the specification are implementable and have compatible behavior.

  2. An implementation report shows that there are at least two different and interoperable implementations of every mandatory and optional feature.

  3. Formal responses to all comments received by the Working Group.

  4. If these criteria are met, the specification will advance to Proposed Recommendation. If the implementation exit criteria are not met then the specification will enter a Candidate Recommendation phase to ensure they are met.

A list of open Last Call issues against this document can be found at http://www.w3.org/2000/xp/Group/xmlp-lc-issues.

Comments on this document should be sent to xmlp-comments@w3.org (public archive [XMLP Comments]). It is inappropriate to send discussion email to this address. Comments should be sent during the last call review period, which ends on 19 July 2002.

Discussion of this document takes place on the public xml-dist-app@w3.org mailing list [XMLP Dist-App] under the email communication rules in the XML Protocol Working Group Charter [XMLP Charter].

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "works in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.


Short Table of Contents

1. Introduction
2. SOAP Processing Model
3. SOAP Extensibility Model
4. SOAP Protocol Binding Framework
5. SOAP Message Construct
6. Use of URIs in SOAP
7. Security Considerations
8. References
A. Version Transition From SOAP/1.1 to SOAP Version 1.2
B. Acknowledgements (Non-Normative)
C. Part 1 Change Log (Non-Normative)


Table of Contents

1. Introduction
1.1 Notational Conventions
1.2 Relation to Other 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 Header Blocks
2.5 Structure and Interpretation of SOAP Bodies
2.6 Processing SOAP Messages
2.7 Relaying SOAP Messages
2.7.1 Relaying SOAP Header Blocks
2.7.2 SOAP Forwarding Intermediaries
2.7.3 SOAP Active Intermediaries
2.7.4 SOAP Intermediaries and Relayed Infoset
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.2.4 SOAP relay 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.2.1 SOAP Text 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 SOAP mustUnderstand 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

Appendices

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


1. Introduction

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing 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.

Two major design goals for SOAP are simplicity and extensibility (see [XMLP Requirements]). SOAP attempts to meet these goals by omitting, from the messaging framework, features 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

"Message Exchange Patterns"

the concept of message exchange patterns

(MEPs). While it is anticipated that many such features will be defined,

this specification provides specifics only for two MEPs.

it is beyond the scope of this specification to do so.

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

  1. The SOAP processing model defining the rules for processing a SOAP message (see 2. SOAP Processing Model).

  2. The SOAP message construct defining the structure of a SOAP message (see 5. SOAP Message Construct).

  3. 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).

[SOAP Part0] is a non-normative document intended to provide an easily understandable tutorial on the features of the SOAP Version 1.2 specifications.

[SOAP Part2] describes a set of adjuncts that can be used in connection with the SOAP messaging framework.

Note:

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

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].

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

Table 1: Prefixes and Namespaces used in this specification.
PrefixNamespaceNotes
env"http://www.w3.org/2002/06/soap-envelope"A normative XML Schema [XML Schema Part1], [XML Schema Part2] document for the "http://www.w3.org/2002/06/soap-envelope" namespace can be found at http://www.w3.org/2002/06/soap-envelope.
flt"http://www.w3.org/2002/06/soap-faults"A normative XML Schema [XML Schema Part1], [XML Schema Part2] document for the "http://www.w3.org/2002/06/soap-faults" namespace can be found at http://www.w3.org/2002/06/soap-faults.
upg"http://www.w3.org/2002/06/soap-upgrade"A normative XML Schema [XML Schema Part1], [XML Schema Part2] document for the "http://www.w3.org/2002/06/soap-upgrade" namespace can be found at http://www.w3.org/2002/06/soap-upgrade.
enc"http://www.w3.org/2002/06/soap-encoding"Defined by [SOAP Part2].
xs"http://www.w3.org/2001/XMLSchema"The namespace of the XML Schema [XML Schema Part1], [XML Schema Part2] specification

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

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

1.2 Relation to Other Specifications

A SOAP message is specified as an XML Information Set [XML InfoSet]. While all SOAP message examples in this document are shown using XML 1.0 [XML 1.0] syntax, other representations MAY be used to transmit SOAP messages between nodes (see 4. SOAP Protocol Binding Framework).

Some of the information items defined by this document (see 5. SOAP Message Construct) are identified using XML namespace [Namespaces in XML] names. See Table 1 for a list of the namespace names defined in this document.

In particular, this document defines the following namespace names:

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

SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by this specification. The values associated with element and attribute information items defined in this specification MUST be carried explicitly in the transmitted SOAP message except where stated otherwise (see 5. SOAP Message Construct).

SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by Parts 1 and 2 of this specification. The values associated with element and attribute information items defined in this specification MUST be carried explicitly in the transmitted SOAP message except where stated otherwise (see 5. SOAP Message Construct).

SOAP attribute information items have types described by [XML Schema Part2]. 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] 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).

The media type "application/soap+xml" [SOAP MediaType] SHOULD be used for XML 1.0 serializations of the SOAP message infoset.

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] and [RFC 793]: "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 SOAP header block with a local name of alertcontrol and a body element with a local name of alert . In general, SOAP header blocks contain information which might be of use to SOAP intermediaries as well as the ultimate destination of the message. In this example an intermediary might prioritize the delivery of the message based on the priority and expiration information in the SOAP header block. The body contains the actual message payload, in this case the alert message.

Example 1: SOAP message containing a SOAP header block and a SOAP body
<env:Envelope xmlns:env="http://www.w3.org/2002/06/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 can 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).

An optional extension of the SOAP messaging framework (see 3. SOAP Extensibility Model).

Examples of features include "reliability", "security", "correlation", "routing", and

"Message Exchange Patterns" (MEPs)

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

A collection of zero or more SOAP header blocks each of which might be targeted at any SOAP receiver within the SOAP message path.

SOAP header block (or just 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 header block element information item.

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 the SOAP header blocks targeted at it and 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 might 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 the relationship between SOAP message exchange patterns and the SOAP extensibility model).

This section defines the SOAP distributed processing model. The SOAP processing model specifies how a SOAP receiver processes a SOAP message.

It applies to a single message only, in isolation from any other SOAP message. The SOAP processing model itself does not maintain any state or perform any correlation or coordination between messages, even, for example, when used in combination with a feature which involves sending multiple SOAP messages in sequence, each subsequent message depending on the response to the previous message. It is the responsibility of each such features to define such combined processing.

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 might 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.

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.

A SOAP node is identified by a URI, see 5.4.3 SOAP Node Element

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:

This specification defines the following SOAP role names (see 2.6 Processing SOAP Messages):

This specification defines the following role names which have special significance in a SOAP message (see 2.6 Processing SOAP Messages):

  • "http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP intermediary and the ultimate SOAP receiver MUST act in this role and MAY additionally assume zero or more other SOAP roles.

  • "http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes MUST NOT act in this role.

  • "http://www.w3.org/2002/06/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.

Table 2 defines three role names which have special significance in a SOAP message (see 2.6 Processing SOAP Messages).

Table 2: SOAP Roles defined by this specification
Short-nameNameDescription
next "http://www.w3.org/2002/06/soap-envelope/role/next"

Each SOAP intermediary and the ultimate SOAP receiver MUST act in this role.

none "http://www.w3.org/2002/06/soap-envelope/role/none"

SOAP nodes MUST NOT act in this role.

ultimateReceiver "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver"

The ultimate receiver MUST act in this role.

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

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

In addition to the three SOAP role names defined above, other role names MAY be defined as necessary to meet the needs of SOAP applications.

In addition to the SOAP role names defined in Table 2, other role names 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 SOAP header block 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,

With the exception of the three SOAP role names 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 provided by users during system installation.

2.3 Targeting SOAP Header Blocks

A SOAP header block MAY carry a role attribute information item (see 5.2.2 SOAP role Attribute) that is used to target the header block at SOAP nodes operating in the specified role. This specification refers to the value of the SOAP role attribute information item 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 in which the SOAP node operates.

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

SOAP header blocks targeted at the special role "http://www.w3.org/2002/06/soap-envelope/role/none" are never formally processed. Such SOAP header blocks MAY carry data that is required for processing of other SOAP header blocks. Unless removed by the action of an intermediary (see 2.7 Relaying SOAP Messages) , such blocks are relayed with the message to the ultimate receiver (see also 3.2 SOAP Modules).

2.4 Understanding SOAP Header Blocks

It is likely that specifications for a wide variety of header functions

(i.e. SOAP modules)

will be developed over time (see

3. SOAP Extensibility Model)

3.2 SOAP Modules

, and that some SOAP nodes might 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

[local name] and [namespace name]

of the outer-most element information item of that header block.

SOAP header blocks MAY carry 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 SOAP header blocks are presumed to somehow modify the semantics of other SOAP header blocks or SOAP body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header 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 header 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 can 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 SOAP 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 SOAP header block has survived erroneously due to a routing or targeting error at a preceding intermediary.

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.

  1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any SOAP header blocks and the SOAP body, MAY be inspected in making such determination.

  2. Identify all header blocks targeted at the node that are mandatory.

  3. If one or more of the SOAP header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with the Value of Code set to "env:MustUnderstand" (see 5.4.8 SOAP mustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the SOAP body MUST NOT be generated in this step.

  4. Process all

    mandatory

    SOAP 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 application level processing specified by non-mandatory SOAP header blocks targeted at it.

    A SOAP node MAY also choose to process non-mandatory SOAP header blocks targeted at it.

  5. 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 header block and MUST do such processing in a manner fully conformant with the specification for that header block. An ultimate SOAP receiver MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.

In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP header block and MUST do such processing in a manner fully conformant with the specification for that header block. The successful processing of one header block does not guarantee successful processing of another block with the same fully qualified name within the same message: the specification for the header block determines the circumstances in which such processing would result in a fault. 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

at most

one fault. Header-related faults other than those related to understanding SOAP header blocks (see 2.4 Understanding SOAP Header Blocks) MUST conform to the specification for the corresponding SOAP header block.

A message may contain or result in multiple errors during processing. Except where the order of detection is specifically indicated (as in 2.4 Understanding SOAP Header Blocks), a SOAP node is at liberty to reflect any single fault from the set of possible faults prescribed for the errors encountered. The selection of a fault need not be predicated on the application of the "MUST", "SHOULD" or "MAY" keywords to the generation of the fault, with the exception that if one or more of the prescribed faults is qualified with the "MUST" keyword, then any one fault from the set of possible faults MUST be generated.

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 one or more SOAP header blocks 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 SOAP header 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 SOAP body. For example, processing of a "begin transaction" header block would typically precede body processing, a "logging" function might run concurrently with body processing and a "commit transaction" header block might be honored following completion of all other work.

Note:

The above rules apply to processing at a single node. SOAP extensions can be designed to ensure that SOAP header blocks 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 Code set to "env:Sender" is generated if some SOAP header blocks have inadvertently survived past some intended point in the message path. Such extensions might depend on the presence or value of the mustUnderstand attribute information item in the surviving SOAP header blocks 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 SOAP features and then expressed as

SOAP extensions

SOAP modules

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 Relaying SOAP Header Blocks

The specification for a SOAP header block may call for the header block to be forwarded to the next SOAP node if the header block is targetted at a role played by the forwarding SOAP intermediary, but not otherwise processed by the intermediary. By default, SOAP does not require that unprocessed header blocks targetted at a role assumed by a SOAP intermediary be forwarded.

SOAP header blocks MAY carry relay attribute information items (see 5.2.4 SOAP relay Attribute). When the value of such an attribute information item is "true", the header block is said to be relayable. The forwarding of relayable header blocks is described in section 2.7.2 SOAP Forwarding Intermediaries.

The relay attribute information item has no effect on SOAP header blocks targetted at a role other than one assumed by a SOAP intermediary.

The relay attribute information item has no effect on the SOAP processing model when the header block also carries a mustUnderstand attribute information item with a value of "true".

The relay attribute information item has no effect on the processing of SOAP messages by the SOAP ultimate receiver.

Table 3 summarizes the forwarding behaviour of a SOAP node.

Table 3: SOAP Nodes Forwarding behaviour
RoleHeader block
Short-nameAssumedUnderstood & ProcessedForwarded
next YesYesNo, unless reinserted
NoNo, unless relay ="true"
user-definedYesYesNo, unless reinserted
NoNo, unless relay ="true"
Non/aYes
ultimateReceiver YesYesn/a
Non/a
none Non/aYes

2.7.2 SOAP 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 SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. They MUST also remove from the SOAP message all SOAP header blocks targeted at themselves, prior to forwarding, regardless of whether these header blocks were processed or ignored.

Forwarding SOAP intermediaries MUST process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. In addition, when generating a SOAP message for the purpose of forwarding, they MUST:

  1. Remove all processed SOAP header blocks.

  2. Remove all non-relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.

  3. Retain all relayable SOAP header blocks that were targeted at the forwarding node but ignored during processing.

In addition, forwarding SOAP 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 SOAP header blocks. Inserted SOAP header blocks might 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

Processing is defined here in terms of re-inserting header blocks (rather than leaving them in place) to emphasize

the need to process them at each SOAP node along the SOAP message path.

2.7.3 SOAP Active Intermediaries

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

The results of such active processing could impact the interpretation of SOAP messages by downstream SOAP nodes. For example, as part of generating an outbound SOAP message, an active SOAP intermediary might have removed and encrypted some or all of the SOAP header blocks found in the inbound SOAP message. It is strongly recommended that SOAP features provided by active SOAP 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 SOAP intermediary can describe the modifications performed on a message is by inserting SOAP 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 SOAP header blocks should also call for either the same or other SOAP 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 SOAP message with SOAP header blocks removed for encryption passes through a second SOAP intermediary (without the original SOAP header blocks being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed SOAP message.

2.7.4 SOAP Intermediaries and Relayed Infoset

This section provides guidelines for behaviour of SOAP intermediaries with respect to preserving various Infoset properties of a SOAP message such that applications that have a dependency on the XML lexical form (in particular, XML Signature) can function successfully.

All Infoset properties of a message need to be preserved with the following exceptions:

  1. The element information item for a header block targetted at an intermediary can be removed from the [children] property of the soap:Header element information item as detailed in [ref to header block processing rules].

  2. Element information items for additional header blocks can be added to the [children] property of the soap:Header element information item as detailed in [ref to header block processing rules].

  3. Whitespace character information items can be removed from the [children] property of the soap:Envelope element information item.

  4. Whitespace character information items can be added to the [children] property of the soap:Envelope element information item.

  5. Whitespace character information items can be removed from the [children] property of the soap:Header element information item.

  6. Whitespace character information items can be added to the [children] property of the soap:Header element information item.

  7. Comment information items can be added to the [children] property of the soap:Envelope element information item.

  8. Comment information items can be removed from the [children] property of the soap:Envelope element information item.

  9. Comment information items can be added to the [children] property of the soap:Header element information item.

  10. Comment information items can be removed from the [children] property of the soap:Header element information item.

  11. Attribute information items can be added to the [attributes] property of the soap:Envelope element information item.

  12. Attribute information items can be added to the [attributes] property of the soap:Header element information item.

  13. Attribute information items can be added to the [namespace attributes] property of the soap:Envelope element information item.

  14. Attribute information items can be added to the [namespace attributes] property of the soap:Header element information item.

  15. The [base URI] property of the document information item need not be maintained.

  16. The [base URI] property of element information items need not be maintained.

  17. The [character encoding scheme] property of the document information item need not be maintained.

  18. The [in-scope namespaces] property of element information items need not be maintained.

These rules allow for signing of header blocks, that is [children] of soap:Header . It also allows for the signing of soap:Body . In addition It allows for signing combinations of header blocks and the soap:Body

Items 1-6, 11-14 are incompatible with signing the soap:Envelope element when the http://www.w3.org/TR/2001/REC-xml-c14n-20010315 canonicalization algorithm is used. Items 1, 2, 5, 6, 12 and 14 are incompatible with signing the soap:Header when the http://www.w3.org/TR/2001/REC-xml-c14n-20010315 canonicalization algorithm is used.

In addition, if the http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments canonicalization algorithm is used then 7 and 8 are incompatible with signing the soap:Envelope element and 9 and 10 are incompatible with signing the soap:Header element.

Note:

Whitespace character information items are those whose [character code] property has a value of #x20, #x9, #xD or #xA.

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

[local name]

of Envelope and a

namespace name

[namespace name]

of "http://www.w3.org/2002/06/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 SOAP header 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 Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".

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. The extensibility mechanisms described below can be used to add capabilities found in richer messaging environments.

3.1 SOAP Features

For the purpose of this specification, the term "feature" is used to identify an extension of the SOAP messaging framework typically associated with the exchange of messages between communicating SOAP nodes. Although SOAP poses no constraints on the potential scope of such features, example features include "reliability", "security", "correlation", and "routing". In addition, the communication might require a variety of message exchange patterns (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 request-response MEP specified in [SOAP Part2] illustrates the specification of a MEP feature.

The SOAP extensibility model provides two mechanisms through which features can 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 SOAP header blocks (see 2.4 Understanding SOAP Header Blocks). 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 header blocks is known as a SOAP module, and each module is specified according to the rules in 3.2 SOAP Modules.

When a feature is expressed this way, the combined syntax and semantics of such SOAP header blocks are known as a SOAP Module, and are 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).

Certain features might 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 could 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. Although the SOAP Protocol Binding Framework allows end-to-end features to be expressed outside the SOAP envelope, no standard mechanism is provided for the processing by intermediaries of the resulting messages. A binding specification that expresses such features external to the SOAP envelope needs to define its own processing rules to which a SOAP node is expected to conform (for example, describing what information is 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.

Certain features might require end-to-end as opposed to hop-to-hop processing semantics. Although the SOAP Protocol Binding Framework allows end-to-end features to be expressed outside the SOAP envelope, no standard mechanism is provided for the processing by intermediaries of the resulting messages. A binding specification that expresses such features external to the SOAP envelope needs to define its own processing rules for those externally expressed features. A SOAP node is expected to conform to these processing rules (for example, describing what information is passed along with the SOAP message as it leaves the intermediary). The processing of SOAP envelopes in accordance with the SOAP Processing Model (see 2. SOAP Processing Model) MUST NOT be overridden by binding specifications.

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:

  1. A URI used to name the feature. This enables the feature to be unambiguously referenced in description languages or during negotiation.

  2. The information (state) required at each node to implement the feature.

  3. 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).

  4. The information to be transmitted from node to node.

  5. In the case of MEPs:

    Any requirements to generate additional messages (such as responses to requests in a request/response MEP).

    1. Rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP.

    2. The request-response MEP specified in SOAP 1.2 Part 2 [1] illustrates the specification of a MEP feature.

See 3.3 SOAP Message Exchange Patterns (MEPs) for additional requirements on MEP features.

3.2 SOAP Modules

A SOAP module is a feature which is expressed as SOAP header blocks.

A module specification follows the following rules. It:

The term 'SOAP Module' refers to the set of syntax and semantics associated with implementing a particular feature (see 3.1 SOAP Features) as SOAP header blocks. A Module is described in a Module Specification, which adheres to the following rules. It:

  1. MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation.

  2. MUST, if the Module implements a Feature which has already been defined elsewhere, clearly refer to that Feature's URI. Note that a Module may EITHER explicitly refer to a separate Feature in this way OR may implicitly define a Feature simply by describing the semantics of the Module.

  3. MUST clearly and completely specify the content and semantics of the SOAP header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model.

    The SOAP extensibility model does not limit the extent to which SOAP can be extended. Nor does it prevent extensions from modifying the SOAP processing model from that described in 2. SOAP Processing Model

  4. MAY utilize the property conventions defined in [SOAP Part2], 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 SOAP module.

  5. 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 SOAP body and inserts a SOAP header block 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 is to be run prior to any other modules which rely on the contents of the SOAP body.

3.3 SOAP Message Exchange Patterns (MEPs)

A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. In general the definition of a message exchange pattern:

A Message Exchnage Pattern (MEP) is a template that establishes a pattern for the exchange of messages between SOAP nodes. The specification of a message exchange pattern MUST:

  • Is named by a URI.

    As mandated by 3.1.1 Requirements on Features, provide a URI to name the MEP.

  • Describes the life cycle of a message exchange conforming to the pattern.

    Describe the life cycle of a message exchange conforming to the pattern.

  • Describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern.

    Describe the temporal/causal relationships, if any, of multiple messages exchanged in conformance with the pattern (e.g. responses follow requests and are sent to the originator of the request.)

  • Describes the normal and abnormal termination of a message exchange conforming to the pattern.

    Describe the normal and abnormal termination of a message exchange conforming to the pattern.

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

In addition to the requirements on all features (see 3.1.1 Requirements on Features), the specification of an MEP feature MUST also include the following:

MEPs are SOAP features, so an MEP specification MUST conform to the requirements for SOAP feature specifications (see 3.1.1 Requirements on Features). An MEP specification MUST also include:

  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.

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 general rules for the specification of protocol bindings; the framework also describes the relationship between bindings and SOAP nodes that implement those bindings. The HTTP binding in [SOAP Part2] illustrates the specification of a binding. Additional bindings can be created by specifications that conform to the binding framework introduced in this chapter.

A SOAP binding specification:

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:

  1. To set out the requirements and concepts that are common to all binding specifications.

  2. To facilitate homogeneous description in situations where multiple bindings support common features, promoting reuse across bindings.

  3. To facilitate consistency in the specification of optional features.

Two or more bindings can offer a given optional feature, such as reliable delivery, using different means. One binding might exploit an underlying protocol that directly facilitates the feature (e.g., the protocol is reliable), and the other binding might 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.

MEPs.

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. Similarly if a certain feature cannot be used if another feature is present this MUST be specified.

; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.

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. Similarly, any dependencies of one feature on another (i.e. if successful use of one feature depends on use or non-use of another) MUST be specified. This binding framework does not provide any explicit mechanism for controlling the use of such interdependent 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 might benefit from a consistent specification for an authentication credential, a transaction ID, etc. The HTTP binding in [SOAP Part2] 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 [XML 1.0] 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 SOAP header blocks, and checking of all mustUnderstand attributes is to 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 might 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 can have any legal value. The [standalone] property either has a value of "yes" 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.

SOAP messages sent by initial SOAP senders MUST NOT contain processing instruction information items. SOAP intermediaries MUST NOT insert processing instruction information items in SOAP messages they relay. SOAP receivers receiving a SOAP message containing a processing instruction information item SHOULD generate a SOAP fault with the Value of Code set to "env:Sender". However, in the case where performance considerations make it impractical for an intermediary to detect processing instruction information items in a message to be relayed, the intermediary MAY leave such processing instruction information items unchanged in the relayed message.

Element information items defined by this specification

that only have element information items defined as allowable members of their [children] property

can

also

have zero or more character information item children whose character code is amongst the whitespace characters as defined by [XML 1.0]. 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/2002/06/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

The encodingStyle attribute information item indicates the encoding rules used to serialize parts of a SOAP message.

The encodingStyle attribute information item has:

  • A [local name] of encodingStyle .

  • A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".

The encodingStyle attribute information item MAY only appear on:

  1. A SOAP header block (see 5.2.1 SOAP header block).

  2. A child element information item of the SOAP Body element information item (see 5.3.1 SOAP Body child Element).

  3. A child element information item of the SOAP Detail element information item (see 5.4.5.1 SOAP detail entry).

  4. Any descendent of 1, 2, and 3 above.

The scope of the encodingStyle attribute information item 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 ("")

"http://www.w3.org/2002/06/soap-envelope/encoding/none"

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

xs:anyURI.

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/2002/06/soap-encoding"
"http://example.org/encoding/"
"http://www.w3.org/2002/06/soap-envelope/encoding/none"

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 Header Blocks).

The Header element information item has:

  • A [local name] of Header .

  • A [namespace name] of "http://www.w3.org/2002/06/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, MUST be namespace qualified.

  • MUST have a [namespace name] property which has a value, that is the name of the element MUST be namespace qualified.

  • MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

  • MAY have an encodingStyle attribute information item in its [attributes] property.

  • MAY have an role attribute information item in its [attributes] property.

  • MAY have an mustUnderstand attribute information item in its [attributes] property.

  • MAY have any number of element information item children. Such element information items MAY be namespace qualified.

  • MAY have zero or more attribute information items in its [attributes] property. Among these MAY be any or all of the following, which have special significance for SOAP processing:

Example 3: SOAP Header with a single SOAP header block
<env:Header xmlns:env="http://www.w3.org/2002/06/soap-envelope" >
 <t:Transaction xmlns:t="http://example.org/2001/06/tx" 
                env:mustUnderstand="true" >
   5
 </t:Transaction>
</env:Header>

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/2002/06/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".

xs:anyURI.

The value of the role attribute information item is a URI that names a role that a SOAP node can assume.

Omitting the SOAP role attribute information item is equivalent to supplying that attribute with a value of "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver".

An empty value for this attribute is equivalent to omitting the attribute completely, i.e. targeting the SOAP header block at an ultimate SOAP receiver.

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP role attribute information item with a value of "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver".

(see 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 when the value of the role attribute information item is "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" (see 2.7 Relaying SOAP Messages).

A SOAP sender generating a SOAP message SHOULD use the role attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

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 Header Blocks)

The mustUnderstand attribute information item has the following Infoset properties:

  • A [local name] of mustUnderstand .

  • A [namespace name] of "http://www.w3.org/2002/06/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".

xs:boolean.

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 [XML Schema Part2]). 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".

A SOAP intermediary MAY omit the SOAP mustUnderstand attribute information item if its value is "false"

A SOAP sender generating a SOAP message SHOULD use the mustUnderstand attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

5.2.4 SOAP relay Attribute

The SOAP relay attribute information item is used to indicate whether a SOAP header block targetted at a SOAP receiver must be relayed if not processed (see 2.7.1 Relaying SOAP Header Blocks).

The relay attribute information item has the following Infoset properties:

  • A [local name] of relay .

  • A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".

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

The type of the relay attribute information item is "xs:boolean".

Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".

SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the SOAP relay attribute information item with a value of "false" or "0".

If generating a SOAP relay attribute information item, a SOAP sender SHOULD use the canonical representation "true" of the attribute value (see [XML Schema Part2]). 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".

A SOAP intermediary MAY omit the SOAP relay attribute information item if its value is "false".

A SOAP sender generating a SOAP message SHOULD use the relay attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents).

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/2002/06/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.

The Body element information item MAY have any number of character information item children whose character code is amongst the whitespace characters as defined by [XML 1.0]. These are considered significant.

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.

  • SHOULD have a [namespace name] property which has a value, that is the name of the element SHOULD be namespace qualified.

    NOTE: namespace qualified elements tend to produce messages whose interpretation is less ambiguous than those with unqualified elements. The use of unqualified elements is therefore discouraged.

  • MAY have an encodingStyle attribute information item in their [attributes] property.

  • MAY have any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

  • MAY have any number of element information item children. Such element information items MAY be namespace qualified.

  • MAY have zero or more attribute information items in its [attributes] property. Among these MAY be the following, which has special significance for SOAP processing:

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:

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 ; 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/2002/06/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/2002/06/soap-envelope .

The type of the Value element information item is

faultCodeEnum in the "http://www.w3.org/2002/06/soap-envelope" namespace.

env:faultCodeEnum.

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/2002/06/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/2002/06/soap-envelope .

The type of the Value element information item is

QName in the "http://www.w3.org/2001/XMLSchema" namespace.

xs:QName.

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/2002/06/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 [XML 1.0], Language Identification).

  • Any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

  • One or more Text element information item children (see 5.4.2.1 SOAP Text Element).

This element information item is similar to the 'Reason-Phrase' defined by HTTP [RFC 2616] and SHOULD provide 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/2002/06/soap-envelope" namespace.

env:faultReason.

5.4.2.1 SOAP Text Element

The Text element information item is intended to carry the text of a human readable explanation of the fault.

The Text element information item has:

  • A [local name] of Text .

  • A [namespace name] of http://www.w3.org/2002/06/soap-envelope .

  • A mandatory attribute information item with a [local name] of lang and [namespace name] of "http://www.w3.org/XML/1998/namespace" (see [XML 1.0], Language Identification).

  • Any number of character information item children. Child character information items whose character code is amongst the whitespace characters as defined by [XML 1.0] are considered significant.

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

The type of the Text element information item is env:reasontext

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/2002/06/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.

xs:anyURI.

5.4.4 SOAP Role Element

The Role element information item identifies the role the node was operating in 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/2002/06/soap-envelope .

The type of the Role element information item is

anyURI in the "http://www.w3.org/2001/XMLSchema" namespace.

xs:anyURI.

The value of the Role element information item MUST be one of the roles assumed by the node during processing of the message (see 2.2 SOAP Roles and SOAP Nodes).

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/2002/06/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 be present when the contents of the SOAP Body could not be processed successfully. It MUST NOT be used to carry error information about any SOAP header blocks. Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.

The 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.

The Detail element information item MAY be present in a SOAP fault in which case it carries additional information relative to the SOAP fault codes describing the fault (see 5.4.6 SOAP Fault Codes). For example, the Detail element information item might contain information about a message not containing the proper credentials, a timeout, etc. The presence of the Detail element information item has no significance as to which parts of the faulty SOAP message were processed.

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 [XML 1.0] are considered significant.

  • MAY have an encodingStyle attribute information item.

  • MAY have any number of other attribute information items from any namespace

If present, the SOAP encodingStyle attribute information item 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 4. Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item.

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

SOAP fault codes are XML qualified names, and are intended to provide a means by which faults are classified. A hierarchical list of SOAP codes and associated supporting information is included in every SOAP fault message, with each such code identifying the fault category at an increasing level of detail.

The values of the Value child element information item of the Code element information item are restricted to those defined by the env:faultCodeEnum type (see Table 4). Additional fault subcodes MAY be created for use by applications or features. Such subcodes are carried in the Value child element information item of the Subcode element information item.

SOAP fault codes are to be interpreted as modifiers of the contents of the Detail element information item in the sense that they provide the context for the Detail element information item. A SOAP node MUST understand all SOAP fault codes in a SOAP fault message in order to be able to interpret the Detail element information item in a SOAP fault.

Example 4: Sample SOAP fault where the Detail element information item is to be interpreted in the context of the "env:Sender" and "m:MessageTimeout" fault codes.
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"
              xmlns:m="http://www.example.org/timeouts">
 <env:Body>
  <env:Fault>
   <env:Code>
     <env:Value>env:Sender</env:Value>
     <env:Subcode>
      <env:Value>m:MessageTimeout</env:Value>
     </env:Subcode>
   </env:Code>
   <env:Reason>Sender Timeout</env:Reason>
   <env:Detail>
     <m:MaxTime>P5M</m:MaxTime>
   </env:Detail>    
  </env:Fault>
 </env:Body>
</env:Envelope>

This specification does not define a limit for how many Subcode element information items a SOAP fault might contain. However, while not a requirement of this specification, it is anticipated that most practical examples can be supported by relatively few Subcode element information items.

Table 4: SOAP Fault Codes
Local NameMeaning
VersionMismatchThe 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

targetted at the faulting node

that was

either

not understood

or not obeyed

by the faulting node contained a SOAP mustUnderstand attribute information item with a value of "true" (see 5.2.3 SOAP mustUnderstand Attribute and 5.4.8 SOAP mustUnderstand Faults)

DataEncodingUnknown

A header or body

A SOAP header block or SOAP body child element information item

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.

SenderThe 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 is not to be resent without change (see also 5.4 SOAP Fault for a description of the SOAP fault detail sub-element).
ReceiverThe message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself. For example, processing could include communicating with an upstream SOAP node, which did not respond. The message could succeed if resent 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 Code set to "env:VersionMismatch", it SHOULD provide an Upgrade SOAP header block in the generated fault message. The Upgrade SOAP header block, as described below, details the XML qualified names (per [XML Schema Part2]) of the supported SOAP envelopes that the SOAP node supports (see 2.8 SOAP Versioning Model).

The Upgrade SOAP 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/2002/06/soap-upgrade".

  • A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".

  • One or more

    envelope

    SupportedEnvelope

    element information items in its [children] property as described below:

The

envelope

Envelope

element information item has:

  • A [local name] of

    envelope

    SupportedEnvelope

    .

  • A [namespace name]

    which has no value.

    of "http://www.w3.org/2002/06/soap-envelope".

  • An unqualified attribute information item with a local name of qname whose type is

    QName in the "http://www.w3.org/2001/XMLSchema" namespace.

    xs:QName.

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 SOAP 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 5: 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/2002/06/soap-envelope">
 <env:Header>
  <env:Upgrade>
   <env:SupportedEnvelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2002/06/soap-envelope"/>
   <env:SupportedEnvelope qname="ns2:Envelope" 
             xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>
  </env: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 SOAP mustUnderstand Faults

When a SOAP node generates a fault with a Value of Code set to "env:MustUnderstand"

for,

it SHOULD provide Misunderstood SOAP header blocks in the generated fault message. The Misunderstood SOAP header blocks, as described below, detail the XML qualified names (per [XML Schema Part2]) of the particular SOAP header block(s) which were not understood.

it SHOULD provide NotUnderstood SOAP header blocks in the generated fault message. The NotUnderstood SOAP header blocks, as described below, detail the XML qualified names (per [XML Schema Part2]) of the particular SOAP 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 SOAP header blocks.

Each such header block element information item has:

  • A [local name] of Misunderstood .

    A [local name] of NotUnderstood .

  • A [namespace name] of "http://www.w3.org/2002/06/soap-faults".

  • A [namespace name] of "http://www.w3.org/2002/06/soap-envelope".

  • 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

QName in the "http://www.w3.org/2001/XMLSchema" namespace.

xs:QName.

Its value is the XML qualified name of a SOAP header block which the faulting node failed to understand.

Consider the following message:

Example 6: 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/2002/06/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 SOAP message does not understand the two SOAP header blocks abc:Extension1 and def:Extension2 .

Example 7: SOAP fault generated as a result of not understanding Extension1 and Extension2
<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2002/06/soap-envelope' >
 <env:Header>
  <env:NotUnderstood qname='abc:Extension1'
                   xmlns:abc='http://example.org/2001/06/ext' />
  <env:NotUnderstood 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 
                SOAP header blocks not understood</env:Reason>
  </env:Fault>
 </env:Body>
</env:Envelope>

Note:

When serializing the qname attribute information item there needs to be an in-scope namespace declaration for the namespace name of the SOAP header block that was not understood and the value of the attribute information item uses the prefix of such a namespace declaration. The prefix used need not be the same as the one used in the SOAP message that was not understood.

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/2002/06/soap-envelope" and "http://www.w3.org/2002/06/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] and [RFC 2396] 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 [SOAP Part2], 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]. 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]). However, when used, the literal format for IPv6 addresses in URIs as described by [RFC 2732] 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 be provided as SOAP extensions using the SOAP extensibility model (see 3. SOAP Extensibility Model). This section describes the security considerations that designers and implementers need to take into consideration when designing and using such mechanisms.

SOAP implementers need to anticipate rogue SOAP applications sending intentionally malicious data to a SOAP node (see 2. SOAP Processing Model). 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.

7.1 SOAP Nodes

SOAP can carry application-defined data as SOAP header blocks or as SOAP body contents. Processing a SOAP header block might 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 SOAP header blocks with well understood security implications of any side effects be processed by a SOAP node.

Similarly, processing the SOAP body might imply the occurrence of side

affects

effects

that could, if not properly understood, have severe consequences for the receiving SOAP node. 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 a SOAP header block and the SOAP body. Implementers need to 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 might be encoded as binary data or carried as parameters, for example URI query strings. Before accepting data of any type, an application ought to be aware of the particular security implications associated with that data within the context it is being used.

SOAP implementers need to 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 security context. For example, the SOAP body ought not to be processed without knowing the context in which it was received.

7.2 SOAP Intermediaries

SOAP inherently provides a distributed processing model that might 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 might 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 can be very subtle. Binding specification authors ought to describe, in detail, the security implications of not following recommendations or requirements as most implementers 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 might not address or provide countermeasures for all aspects of the inherent security risks. The binding specification authors ought to 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 need to be aware that SOAP extension modules expressed as SOAP header blocks could affect the underlying protocol in unforeseen ways. A SOAP message carried over a particular protocol binding might 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 describes any such interactions between the extensions and the underlying protocols.

7.3.1 Binding to Application-Specific Protocols

Some underlying protocols could 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

with

that protocol.

However, the use of well-known ports by SOAP might incur additional, unintended handling by intermediaries and underlying implementations. For example, HTTP is commonly thought of as a "Web browsing" protocol, and network administrators might place certain restrictions upon its use, or could 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

[SOAP Part2]
W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, @@@@@@ (See soap12-part2.html.)
[RFC 2616]
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.)
[RFC 2119]
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.)
[XML Schema Part1]
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/.)
[XML Schema Part2]
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/.)
[RFC 2396]
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.)
[Namespaces in XML]
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/.)
[XML 1.0]
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.)
[XML InfoSet]
W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)
[XML Base]
W3C Recommendation "XML Base", Johnathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/.)
[RFC 2732]
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.)
[SOAP MediaType]
IETF Internet Draft "The 'application/soap+xml' media type", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-01.txt" June 19, 2002. (Work in progress). (See http://www.w3.org/2000/xp/Group/2/06/18/draft-baker-soap-media-reg-01.txt.)

8.2 Informative References

[SOAP Part0]
W3C Working Draft "SOAP Version 1.2 Part 0: Primer", Nilo Mitra, @@@@@@ (See soap12-part0.html.)
[XMLP Comments]
XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)
[XMLP Dist-App]
XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)
[XMLP Charter]
XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)
[XMLP Requirements]
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, @@@@@@. This is work in progress. (See xmlp-reqs.html.)
[SOAP 1.1]
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/.)
[RFC 1900]
IETF "RFC 1900: Renumbering Needs Work", B. Carpenter, Y. Rekhter, February 1996. (See http://www.ietf.org/rfc/rfc1900.txt.)
[RFC 1123]
IETF "RFC 1123: Requirements for Internet Hosts -- Application and Support", R. Braden, October 1989. (See http://www.ietf.org/rfc/rfc1123.txt.)
[RFC 793]
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

This appendix describes the version management rules for a SOAP node. If a SOAP node supports versioning from SOAP 1.1 to SOAP 1.2, then the SOAP node MUST implement the rules described in this appendix.

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

  1. 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

    [local name]

    of Envelope and a

    namespace name

    [namespace name]

    of "http://schemas.xmlsoap.org/soap/envelope/".

  2. 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 using a SOAP/1.1 binding to the underlying protocol (see [SOAP 1.1]). The SOAP fault SHOULD include an Upgrade SOAP 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.

      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 SOAP 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 SOAP header block indicating support for SOAP Version 1.2.

Example 8: SOAP Version 1.2 node generating a SOAP/1.1 version mismatch fault message including an Upgrade SOAP 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>
  <env:Upgrade>
   <env:SupportedEnvelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2002/06/soap-envelope"/>
   </env: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.

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

Note:

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

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): Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly Allaire), Paul Denning (MITRE), Frank DeRose (Tibco), Colleen Evans (Progress Software), David Fallside (Chair, IBM), Dietmar Gaertner (Software AG), Martin Gudgin (Microsoft Corporation, formerly DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Mario Jeckle (DaimlerChrysler Research & Technology), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet), Yves Lafon (W3C), Michah Lerner (AT&T), Bob Lojek (Intalio), Brad Lund (Intel), Noah Mendelsohn (IBM, formerly Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Highland Mary Mountain (Intel), Don Mullen (Tibco), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), David Orchard (BEA Systems, formerly JamCracker), Andreas Riegg (DaimlerChrysler Research & Technology), Herve Ruellan (Canon), Marwan Sabbouh (MITRE), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia, formerly Allaire), Nick Smilonich (Unisys), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Asir Vedamuthu (webMethods), Pete Wenzel (SeeBeyond), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Amr Yassin (Philips Research), Jin Yu (Martsoft).

Previous members were: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Mark Baker (Idokorro Mobile, formerly Sun Microsystems), Philippe Bedu (Electricite de France), Olivier Boudeville (Electricite de France), Don Box (DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software Corp), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corp), Yin-Leng Husband (Hewlett Packard, formerly Compaq), Scott Isaacson (Novell), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Henry Lowe (OMG), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Mark Nottingham (Akamai Technologies), Conleth O'Connell (Vignette), David Orchard (Jamcracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera) Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Aaron Skonnard (Developmentor), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Jim Trezzo (Oracle), Randy Waldrop (webMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Susan Yee (Active Data Exchange).

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

DateAuthorDescription
20021108JJMIncorporated resolutions for issue 355 (intermediary and infoset).
20021107JJMIncorporated resolutions for issue 277 (property names are now URIs).
20021106JJMIncorporated amendments from Noah and Henrik to the role table.
20021105JJMAdded new table suggested by Henrik to list the roles defined by this spec.
20021105JJMIn the role/forwarding table, renamed "name" to "short-name".
20021103HFNDeleted refs to RFC 793 and 1123 as they are no longer used
20021031HFNUpdated ref to SOAP 1.2 part 2 in 8. References to include Noah.
20021031HFNIncorporated resolution to issue 359.
20021031HFNIncorporated editorial comment from issue 384 in 2.1 SOAP Nodes.
20021031HFNIncorporated resolution to issue 371 in 2.6 Processing SOAP Messages.
20021030MJGAmended description of MustUnderstand fault in 5.4.6 SOAP Fault Codes with Noah's changes as agreed at face-to-face
20021030MJGAmended description of processing role/none in 2.3 Targeting SOAP Header Blocks with Noah's changes as agreed at face-to-face
20021030MJGAmended description of SOAP Role in 2.1 SOAP Nodes with Noah's changes as agreed at face-to-face
20021030MJGAmended description of [namespace name] in 5.2.1 SOAP header block with Noah's changes as agreed at face-to-face
20021030MJGRemoved note from 4.2 Binding Framework per Noah's changes as agreed at face-to-face
20021030MJGAmended 1. Introduction with Noah's changes as agreed at face-to-face
20021030MJGAmended definitions of SOAP Feature 1.4.1 Protocol Concepts with Noah's changes as agreed at face-to-face
20021030MJGAmended last paragraph of 5. SOAP Message Construct as resolution of issue 262.
20021030MJGAdded xs prefix to namespace table in 1.1 Notational Conventions per Noah's changes
20021030MJGImplemented merge of soap-fault namespace into soap-envelope namespace
20021029MJGImplemented merge of soap-upgrade namespace into soap-envelope namespace, including change of local name from Envelope to SupportedEnvelope.
20021029MJGFixed Example 8 to match Section 5.4.7
20021028JJMAdded back: "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."
20020926MJHChanged a couple of dangling misunderstood to notunderstood.
20020923JJMAdded issue 280 resolution.
20020919MJHAdded issue 292 resolution.
20020916JJMConsistently use "SOAP header blocks" (and not, for example, "SOAP headers").
20020916JJMAdd the expression "SOAP module" where this is what was meant (two occurences).
20020915HFNAmended resolution to issue 320 with text
20020905MJHAmended 5. SOAP Message Construct to bring more closely in line with resolution of issue 221. Note that an initial resolution was entered by MJG on 20020822; this is a revision to that version.
20020904NRMAmended 2.2 SOAP Roles and SOAP Nodes to bring more closely in line with resolution of issue 250. Note that an initial resolution was entered by MJG on 20020814; this is a revision to that version.
20020904JJM Capitalized the 'R' in faultReason.
20020902HFN Incorporated resolution to issue 320.
20020826NRM Changed 3.1.1 Requirements on Features: now says "URI used to name a feature" (was refer to a feature). In 3.3 SOAP Message Exchange Patterns (MEPs) general rewording as requested in issue resolution and clarify that an MEP spec must conform to rules for feature spec. Closes issue 331.
20020826NRM Changed 4.2 Binding Framework to eliminate typos and clarify phrasing regarding interdependent features. (4th para.)
20020823NRM Changed 5.4.8 SOAP mustUnderstand Faults so the fault element is now NotUnderstood as opposed to misUnderstood. issue 357
20020823MJG Amended description of 5.2.1 SOAP header block and 5.3.1 SOAP Body child Element to allow element information item children per resolution of issue 307
20020823MJG Changed from 'local name' and 'namespace name' to '[local name]' and '[namespace name]' in 2.4 Understanding SOAP Header Blocks, 2.8 SOAP Versioning Model and A. Version Transition From SOAP/1.1 to SOAP Version 1.2 as per issue 352
20020823MJG Changed from "type 'localname' in the namespace 'namespaceuri'" to "type prefix:localname" in 5.1.1 SOAP encodingStyle Attribute, 5.2.2 SOAP role Attribute, 5.2.3 SOAP mustUnderstand Attribute, 5.4.1.1 SOAP Value element (with Code parent), 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.7 VersionMismatch Faults and 5.4.8 SOAP mustUnderstand Faults as per issue 352
20020822MJGRemoved XLink from 8.1 Normative References ( does not show up in diff ) per the resolution of issue 352
20020822MJGAmended 5. SOAP Message Construct per the resolution of issue 221
20020822MJGAmended 4.2 Binding Framework and 5.4.8 SOAP mustUnderstand Faults per the resolution of editorial issue 337
20020820MJGAmended 4.2 Binding Framework per the resolution of editorial issue 281
20020820MJGAmended 2.6 Processing SOAP Messages, 2.7.2 SOAP Forwarding Intermediaries, 5.2.3 SOAP mustUnderstand Attribute, 7.1 SOAP Nodes and 7.3.1 Binding to Application-Specific Protocols per the resolution of editorial issue 278
20020820MJGAmended member and previous member lists. There is no diff markup for this.
20020815MJGAmended 5.4.5 SOAP Detail Element per resolution of issue 322.
20020815MJGAmended 5.1.1 SOAP encodingStyle Attribute per resolution of issue 323. Also amended Example 2, although this does not show up in the diff
20020814MJGAmended 2.2 SOAP Roles and SOAP Nodes per resolution of issue 250
20020814MJGAmended 3.1.1 Requirements on Features per resolution of issue 230
20020814MJGAmended 3.1 SOAP Features and 3.2 SOAP Modules per resolution of issue 219
20020813MJGAmended 5.4.7 VersionMismatch Faults per resolution of issue 291. Also amended Example 4, although this does not show up in the diff
20020813MJGAmended the element declaration for the envelope element in the upgrade schema. per resolution of issue 291
20020813MJGAmended 5.2.2 SOAP role Attribute per resolution of issue 233
20020812MJGAmended 5.4.2 SOAP Reason Element to reflect new structure for Reason element per resolution of issue 263
20020812MJGModified last paragraph of 3.1 SOAP Features per resolution of issue 220
20020812MJGRemoved 1.2.2 Robustness Principle per resolution of issue 249
20020812MJGChanged faultReason type in envelope schema to have 'text' child elements which themselves allow xml:lang, per resolution of issue 263
20020812MJGRemoved DTDNotSupported entry from the faultCodeEnum type in the envelope schema, per resolution of issue 321
20020812MJGAdding change log :)
20020725MJHAdded clarification of whitespace handling to 5.3.1 SOAP Body child Element as per resolution of issue 208
20020722MJHAdded text concerning attributes to 5.2.1 SOAP header block and 5.3.1 SOAP Body child Element as per resolution of issue 210
20020718MJHModified text in 3.1 SOAP Features as per resolution of issue 211
20020718MJHMoved MEP specific rules from 3.1.1 Requirements on Features to 3.3 SOAP Message Exchange Patterns (MEPs) as per resolution of issue 213
20020718MJHAmended 5.2.3 SOAP mustUnderstand Attribute as per resolution of issue 214
20020718MJHAmended 5.4.4 SOAP Role Element as per resolution of issue 215
20020718MJHAmended 2.1 SOAP Nodes as per resolution of issue 217
20020718MJHAmended 2.6 Processing SOAP Messages as per resolution of issue 229
20020712MJHRemoved paragraph ( sent to Primer ) in 2.7.2 SOAP Forwarding Intermediaries as per resolution of issue 218
20020712MJHRemoved duplicate text in 1.2 Relation to Other Specifications as per resolution of issue 236
20020712MJHModified text in 3.1 SOAP Features as per resolution of issue 212
20020712JJMAdded text to 2. SOAP Processing Model as per resolution of issue 225