Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
SOAP version 1.2 is a lightweight protocol intended for exchange of structured information in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. The SOAP specification is split into two parts: Part 1 (this document) defines the SOAP messaging framework consisting of the SOAP message construct, the SOAP processing model, and the SOAP underlying protocol binding framework. Part 2 [1] defines a set of adjuncts that may be used with the SOAP messaging framework. Adjuncts include a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls and responses.
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 forth W3C 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.
For a detailed list of changes since the last publication of this document, refer to appendix C Part 1 Change Log. A list of open issues against this document can be found at http://www.w3.org/2000/xp/Group/xmlp-issues.
Comments on this document should be sent to xmlp-comments@w3.org (public archive[13]). It is inappropriate to send discussion emails to this address.
Discussion of this document takes place on the public xml-dist-app@w3.org mailing list[14] under the email communication rules in the XML Protocol Working Group Charter[15].
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 "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
1 Introduction
1.1 Notational Conventions
1.2 Relation to other XML Specifications
1.3 Example of SOAP Message
1.4 SOAP Terminology
1.4.1 Protocol Concepts
1.4.2 Data Encapsulation Concepts
1.4.3 Message Sender and Receiver Concepts
2 SOAP Processing Model
2.1 SOAP Nodes
2.2 SOAP Roles and SOAP Nodes
2.3 Targeting SOAP Header Blocks
2.4 Understanding SOAP Headers
2.5 Structure and Interpretation of SOAP Bodies
2.6 Processing SOAP Messages
2.7 Relaying SOAP Messages
2.7.1 SOAP Intermediaries
2.7.2 Forwarding Intermediaries
2.7.3 Active Intermediaries
2.8 SOAP Versioning Model
3 SOAP Message Construct
3.1 SOAP Envelope
3.1.1 SOAP encodingStyle Attribute
3.2 SOAP Header
3.2.1 Use of Header Attributes
3.2.2 SOAP role Attribute
3.2.3 SOAP mustUnderstand Attribute
3.3 SOAP Body
3.4 SOAP Fault
3.4.1 SOAP faultcode Element
3.4.2 SOAP faultstring Element
3.4.3 SOAP faultactor Element
3.4.4 SOAP faultrole Element
3.4.5 SOAP detail Element
3.4.6 SOAP Fault Codes
3.4.7 VersionMismatch Faults
3.4.8 MustUnderstand Faults
4 SOAP Extensibility Model
5 SOAP Protocol Binding Framework
5.1 Goals of the Binding Framework
5.2 Binding Framework
6 Security Considerations
6.1 SOAP Nodes
6.2 SOAP Intermediaries
6.3 Underlying Protocol
Bindings
6.3.1 Binding to Application-Specific Protocols
7 Use of URIs in SOAP
8 References
8.1 Normative References
8.2 Informative References
A Version Transition From SOAP/1.1 to SOAP Version 1.2
B Acknowledgements (Non-Normative)
C Part 1 Change Log (Non-Normative)
C.1 SOAP Specification Changes
C.2 XML Schema Changes
SOAP version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
Note:
In previous versions of this specification the SOAP name was an acronym. This is no longer the case.
Two major design goals for SOAP are simplicity and extensibility (see [16]). SOAP attempts to meet these goals by omitting features often found in distributed systems from the messaging framework and rather leave them to be defined as extensions. Such features include but are not limited to "reliability", "security", "correlation", "routing", and the concept of message exchange patterns. While it is anticipated that many such features will be defined, it is beyond the scope of this specification to do so.
The SOAP specification is divided into two parts. Part 1 of the SOAP specification (this document) defines the SOAP messaging framework consisting of:
The SOAP processing model defining the rules for processing a SOAP message (see 2 SOAP Processing Model).
The SOAP message construct defining the structure of a SOAP message (see 3 SOAP Message Construct).
The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes (see 5 SOAP Protocol Binding Framework).
Part 2[1] describes a set of adjuncts that may be used in connection with the SOAP messaging framework: a graph-based data model (SOAP Data Model) and corresponding encoding rules (SOAP Encoding) for exchanging instances of application-defined data; a convention for representing remote procedure calls and responses (Using SOAP for RPC); and a binding to HTTP (Default HTTP Binding) using the protocol binding framework.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
Namespace URIs of the general form "http://example.org/..." and "http://example.com/..." represent an application-dependent or context-dependent URI[6].
A SOAP message is specified as an XML Information Set[10]. While all SOAP message examples in this document are shown using XML 1.0[8] this is not a requirement of SOAP (see 5 SOAP Protocol Binding Framework).
All information items defined by this document are identified using XML namespaces[7] (see 3 SOAP Message Construct). In particular, this document defines the following namespaces:
The SOAP envelope has the namespace identifier "http://www.w3.org/2001/12/soap-envelope" (see 3 SOAP Message Construct).
The SOAP MustUnderstand Fault has the namespace identifier "http://www.w3.org/2001/12/soap-faults" (see 3.4 SOAP Fault).
The SOAP Upgrade element has the namespace
identifier "http://www.w3.org/2001/12/soap-upgrade" (see 2.8 SOAP Versioning Model).
Normative XML Schema[4],[5] documents for these namespaces can be found by dereferencing the namespace identifiers above.
SOAP does not require any XML schema processing (assessment or validation) in order to establish the values or correctness of element and attribute information items defined by this specification. These information items must, unless stated otherwise, be carried explicitly in the transmitted SOAP message (see 3 SOAP Message Construct).
Specifications for the processing of application-defined data carried in a SOAP message but not defined by this specification may but NEED NOT call for additional validation of the SOAP message in conjunction with application-level processing. In such cases, the choice of schema language and/or validation technology is at the discretion of the application.
SOAP uses XML Base[11] for determining a base URI for relative URI references used as values in information items defined by this specification (see 7 Use of URIs in SOAP).
The following example shows a sample notification message
expressed in SOAP. The message contains two pieces of
application-defined data not defined by this specification:
a header block with a local name of alertcontrol
and a body element with a local name of alert . In
general, the header contains information which may be of use
to intermediaries as well as the ultimate destination of the
message. The body contains the actual notification message
to be delivered.
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope>
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.
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.
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 5 SOAP Protocol Binding Framework). Example SOAP bindings include carrying a SOAP message within an HTTP entity-body, or over a TCP stream.
An abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes (see 4 SOAP Extensibility Model). Examples of features include "reliability", "security", "correlation", "routing", and the concept of message exchange patterns.
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).
The basic unit of communication between peer SOAP nodes.
The outermost element information item of a SOAP message within which all other message element information items are enclosed.
An
element information item used to delimit data that logically
constitutes a single computational unit within the SOAP
header. SOAP header blocks are direct children of the SOAP
Header element information
item (see 3.2 SOAP Header)
. The type of a SOAP header block is identified by
the fully qualified name of the outer element
information item of the
block, which consists of its namespace URI and local
name.
A collection of zero or more SOAP header blocks each of which may be targeted at any SOAP receiver within the SOAP message path.
A collection of zero
or more element information items targeted
at the ultimate SOAP
receiver in the SOAP message path and which are direct children of the
SOAP Body information item (see3.3 SOAP Body).
A special SOAP element information item which contains fault information generated by a SOAP node.
A SOAP node that transmits a SOAP message.
A SOAP node that accepts a SOAP message.
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.
The SOAP sender that originates a SOAP message as the starting point of a SOAP message path.
A SOAP intermediary is both a SOAP receiver and a SOAP sender and is target-able from within a SOAP message. It processes a defined set of SOAP header blocks in a SOAP message. It moves the message further along the message path by relaying it towards an ultimate SOAP receiver.
The SOAP receiver that is a final destination of a SOAP message within a SOAP message path. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message may not reach an ultimate receiver, for example because of the generation of a SOAP fault in a SOAP intermediary along the SOAP message path. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message (see 2 SOAP Processing Model).
SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries.
The SOAP distributed processing model can support many message exchange patterns including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations.
This section defines the SOAP distributed processing model. Section 5 SOAP Protocol Binding Framework defines a framework for describing how message exchange patterns as well as additional features such as routing, reliability and security interact with the distributed processing model.
A SOAP node can be the initial SOAP sender, the ultimate SOAP receiver, or a SOAP intermediary, in which case it 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 by the remainder of this specification.
A SOAP node MUST be identified by a URI
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; because this specification deals only with the processing of individual SOAP messages, no statement is made regarding the possibility that a given piece of software might or might not act in varying roles when processing more than one SOAP message.
The following roles are defined by this specification:
Each SOAP node MUST act in this role and MAY additionally assume zero or more other SOAP roles.
SOAP nodes MUST NOT act in this role.
To establish itself as the ultimate SOAP receiver a SOAP node MUST act in this role. SOAP intermediaries MUST NOT act in this role.
In addition to those described above, other roles MAY be defined as necessary to meet the needs of SOAP applications.
While the purpose of a SOAP role name is to identify a SOAP node or nodes, there are no routing or message exchange semantics associated with the SOAP role name. For example, SOAP roles MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP roles with names that are related more indirectly to message routing (e.g. "http://example.org/banking/anyAccountMgr") or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concerned software that the containing SOAP message is idempotent, and can safely be cached and replayed.)
Except for "http://www.w3.org/2001/12/soap-envelope/role/next", "http://www.w3.org/2001/12/soap-envelope/role/none" and "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver" this specification does not prescribe the criteria by which a given node determines the (possible 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: hardcoded choices in the implementation, information provided by the underlying protocol binding (e.g. the URI to which the message was physically delivered), configuration information made by users during system installation, etc.
SOAP header blocks carry optional roleattribute
information items (see
3.2.2 SOAP role Attribute) that are used to target the blocks to
the appropriate SOAP node(s). This specification refers to
the (implicit or
explicit) value of
the SOAP role attribute as the SOAP role for
the
corresponding SOAP header block.
A SOAP header block is said to be targeted to a SOAP node if the
SOAP role for the header block
is the name of a role played by the SOAP node.
Header blocks targeted to the special role "http://www.w3.org/2001/12/soap-envelope/role/none" are carried with the message to the ultimate receiver, but are never formally "processed". Such blocks MAY carry data that is required for processing of other blocks.
The ultimate SOAP receiver is additionally responsible for processing the message body. The SOAP message path for that message ends at its ultimate recipient.
It is likely that specifications for a wide variety of header functions will be developed over time, and that some SOAP nodes MAY include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.
SOAP header blocks carry optional
mustUnderstandattribute
information items (see
3.2.3 SOAP mustUnderstand Attribute). When the value of such an
attribute information item is logically
"True",
the SOAP block is said to be mandatory.
Mandatory blocks MUST be presumed to somehow modify the semantics of other headers or body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 3.4 SOAP Fault).
Tagging SOAP blocks as mandatory thus assures that such changes in semantics will not be silently (and, presumably, erroneously) ignored by a SOAP node to which the header block is targetted.
The mustUnderstandattribute 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 which may result in a failure to even
attempt processing of a given SOAP header block from a SOAP
envelope. This specification therefore does not require any fault to
be generated based on the presence or value of this attribute on a
SOAP header block not targeted at the current processing node, for
example when it is suspected that such a block has survived
erronously
due to a routing or targeting error at a preceeding intermediairy. In
particular, it is not an error for a mandatory header block targeted
to a role other than the ones assumed by the ultimate SOAP
receiver to
reach an ultimate receiver without having been processed.
An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 3.3 SOAP Body). However, 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.
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 should be taken to prevent the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below.
Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including header blocks and the body, MAY be inspected in making such determination.
Identify all header blocks targeted at the node that are mandatory.
If one or more of the header blocks identified in the preceding step are not understood by the node then generate a single SOAP MustUnderstand fault (see 3.4.8 MustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the body MUST NOT be generated in this step.
Process all header blocks targeted at the node and, in the case of the ultimate SOAP recipient, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the processing implied by non-mandatory SOAP header blocks targeted at it.
In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks.
In all cases where a SOAP header block is processed, the SOAP node must understand the SOAP block and must do such processing in a manner fully conformant with the specification for that block. The ultimate recipient 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 3.4 SOAP Fault). SOAP message processing MAY result in the generation of at-most one fault. Header-related faults other than mustUnderstand faults MUST conform to the specification for the corresponding SOAP header block.
SOAP nodes can make reference to any information in the SOAP envelope when processing a SOAP body and/or SOAP header block. For example, a caching function can cache the entire SOAP message, if desired.
The processing of particular SOAP header block MAY control or determine the order of processing for other SOAP header blocks and/or the SOAP body. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a controlling block, the order of header and body processing is at the discretion of the SOAP node; header blocks MAY be processed in arbitrary order, and such processing MAY precede, be interleaved with, or MAY follow processing of the body. For example, a "begin transaction" header block would typically precede, a "commit transaction" would likely follow, and a "logging" function might run concurrently with body processing.
Note:
The above rules apply to processing at a single node.
SOAP extensions may be designed to ensure that
mandatory (and other) headers are processed in an appropriate
order, as the message moves along the message path towards the
ultimate recipient. Specifically, such extensions might
specify that a (Sender) fault is generated if some SOAP header
blocks have inadvertently survied past some intended point in
the message path. Such extensions may depend on the presence or
value of the mustUnderstandattribute information item
in the surviving headers when determining whether an error has
occurred.
As mentioned earlier in this section, SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see 4 SOAP Extensibility Model and 5 SOAP Protocol Binding Framework). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.
The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request 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 intermediary.
SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two type of intermediary are described below.
Forwarding intermediaries process the message according to the SOAP processing model defined in 2.6 Processing SOAP Messages. SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding (such SOAP blocks are removed regardless of whether they were processed or ignored).
It is the responsibility of the feature defining the SOAP forwarding to describe the required semantics including rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)
In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. That is, they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: security services, annotation services, and content manipulation services.
The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encryped some or all of the blocks found in the inbound message. It is strongly recommended that features provided by active intermediaries be described in a manner that allows such modifications to be detected by affected SOAP nodes in the message path.
One mechanism by which an active intermediary can describe the modifications performed on a message is by inserting header blocks into the outbound SOAP message. These header blocks can inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. In this case, the semantics of such inserted header blocks should also call for either the same or other headers to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with header blocks removed for encryption passes through a second intermediary (without the original headers being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.
SOAP does not define a traditional versioning model based on major and minor version numbers. Rather, the SOAP processing model enables extensiblity of SOAP through the concept of features (see 2.6 Processing SOAP Messages).
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 the envelope
identified by the qualified name of the Envelope element information item (see 3.1 SOAP Envelope). The envelope versioning model is
directed only at the Envelope element
information item. It does NOT address versioning of
blocks, encodings, protocol bindings, or otherwise.
If the child element information item of the
document information item does NOT have a local
name of Envelope and a namespace name of
http://www.w3.org/2001/12/soap-envelope then
the receiving SOAP node MUST generate a VersionMismatch SOAP
fault (see 3.4 SOAP Fault). Any other
malformation of the message construct MUST be treated as a
Sender SOAP fault (see 3.4 SOAP Fault).
A SOAP node MAY provide support for multiple envelopes. However, when processing a message a SOAP node MUST use the semantics defined by the version of that message.
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
3.4.7 VersionMismatch Faults).
A SOAP message has an XML Infoset that consists of a
document information item with exactly one child,
which is the SOAP Envelope element information item (see 3 SOAP Message Construct).
A SOAP message infoset MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 3.4 SOAP Fault) with a fault code of "DTDNotSupported". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives.
The Envelope element information item has:
A local name of Envelope ;
A namespace name of http://www.w3.org/2001/12/soap-envelope;
Zero or more namespace qualified attribute information items;
One or two element information item children in order as follows:
An optional Header element information
item (see 3.2 SOAP Header);
A mandatory Body element information
item (see 3.3 SOAP Body);
SOAP defines an encodingStyleattribute
information item which can be used to indicate the
encoding rules used to serialize a SOAP message.
The encodingStyleattribute information
item has:
A local name of encodingStyle
A namespace name of http://www.w3.org/2001/12/soap-envelope
It may appear on any element information
item in the SOAP message except the Envelope
information item. Its scope is that of its
owner element information item and that
element information item's descendants, unless
a descendant itself carries such an attribute information
item.
The encodingStyleattribute information
item is of type anyURI
in the namespace
http://www.w3.org/2001/XMLSchema. Its value identifies a
set of serialization rules that can be used to
deserialize the SOAP message.
encodingStyleattribute information item."http://www.w3.org/2001/12/soap-encoding" "http://example.org/encoding/" ""
A value of the zero-length URI ("") explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.
A SOAP header provides a mechanism for extending a SOAP message in a decentralized and modular way (see 2.4 Understanding SOAP Headers).
The Header element information item has:
A local name of Header
A namespace name of http://www.w3.org/2001/12/soap-envelope
Zero or more namespace qualified attribute information items
Zero or more namespace qualified element information item children.
Each child element information item of the SOAP Header is called a SOAP header block.
Each SOAP header block element information item:
MUST be namespace qualified;
MAY have an encodingStyleattribute
information item
MAY have
an roleattribute information
item
MAY have a mustUnderstandattribute information item
The SOAP header block attribute information items defined in this section determine how a SOAP receiver should process an incoming SOAP message, as described in 2 SOAP Processing Model.
A SOAP sender
generating a SOAP message SHOULD only use the SOAP header block
attribute information items on
child element information items of the SOAP
Header element information item.
A SOAP
receiver MUST ignore all SOAP header block attribute
information items that are applied to other
descendant element information
items of the SOAP Header element information
item.
<env:Header xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
<t:Transaction xmlns:t="http://example.org/2001/06/tx"
env:mustUnderstand="1" >
5
</t:Transaction>
</env:Header>Except as specified below, SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 1.2 Relation to other XML Specifications).
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 roleattribute information
item has the following Infoset properties:
A local name of role;
A namespace name of http://www.w3.org/2001/12/soap-envelope;
A specified property with a value of true.
The type of the roleattribute
information item is anyURI in the
namespace http://www.w3.org/2001/XMLSchema
. The value of the roleattribute
information item is a URI that names a role that a
SOAP node may assume.
Omitting the SOAP roleattribute information
item or including it with a value of "" is equivalent to including it with a value of "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver". I.e.
targeting the block at the ultimate SOAP recipient.
The SOAP mustUnderstand attribute information item is used to indicate whether the processing of a SOAP header block is mandatory or optional (see 2.4 Understanding SOAP Headers)
The mustUnderstandattribute information
item has the following Infoset properties:
A local name of mustUnderstand;
A namespace name of http://www.w3.org/2001/12/soap-envelope;
A specified property with a value of true.
The type of the mustUnderstandattribute
information item is boolean in the namespace http://www.w3.org/2001/XMLSchema.
Omitting this attribute information item is defined as being
semantically equivalent to including it with a value of
"false".
A SOAP body provides a mechanism for transmitting information to an ultimate SOAP receiver (see 2.5 Structure and Interpretation of SOAP Bodies).
The Body element information item has:
A local name of Body
A namespace name of http://www.w3.org/2001/12/soap-envelope
Zero or more namespace qualified attribute
information items. These MAY include an
encodingStyleattribute information
item.
Zero or more namespace qualified element information item children.
All child element information items of the
SOAP Body element information item:
MUST be namespace qualified.
MAY
have an encodingStyleattribute information
item
SOAP defines one particular direct child of the SOAP body, the SOAP fault, which is used for reporting errors (see 3.4 SOAP Fault).
A SOAP Fault is used to carry error information within a SOAP message.
If present, a SOAP Fault
MUST appear as a direct child of the SOAP body and MUST NOT
appear more than
once within a SOAP Body.
The Fault element information item has:
A local name of Fault ;
A namespace name of http://www.w3.org/2001/12/soap-envelope;
Two or more child element information items in order as follows:
A mandatory faultcode element
information item (see 3.4.1 SOAP faultcode Element);
A mandatory faultstring element
information item (see 3.4.2 SOAP faultstring Element);
An optional faultactor element
information item (see 3.4.3 SOAP faultactor Element);
An optional faultrole element
information item (see 3.4.4 SOAP faultrole Element);
An optional detail element
information item (see 3.4.5 SOAP detail Element).
The faultcode element information item
has:
A local name of faultcode
A namespace name which is empty
One or two child element information items as follows:
A mandatory value element
information item of type faultCodeEnum in the
http://www.w3.org/2001/12/soap-envelope
namespace. This is
intended for use by software to provide an algorithmic
mechanism for identifying the fault. SOAP defines a small set
of SOAP fault codes covering high level SOAP faults (see
3.4.6 SOAP Fault Codes)
An optional subcode element
information item.
The subcode element information item
has:
A local name of subcode
A namespace name which is empty
One or two child element information items as follows:
A mandatory value element
information item of type QName in the
http://www.w3.org/2001/XMLSchema
namespace. The value of this element is an application defined subcategory of the fault code value specified in the subcode 's parent element information item.
An optional subcode element
information item.
The faultstring element information item
has:
A local name of faultstring ;
A namespace name which is empty.
The type of the faultstring element
information item is string in the
http://www.w3.org/2001/XMLSchema namespace. It is
intended to provide a human readable explanation of the fault
and is not intended for algorithmic processing. This
element information item is similar to the
'Reason-Phrase' defined by HTTP[2] and
SHOULD provide at least some information explaining the nature
of the fault.
The faultactor element information item
has:
A local name of faultactor
A namespace name which is empty
The type of the faultactor element information
item is anyURI in the
http://www.w3.org/2001/XMLSchema namespace. It 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 value of the faultactor element information item is the URI that
identifies the SOAP node that generated the fault (see
2.1 SOAP Nodes). SOAP nodes that do not act as the
ultimate SOAP receiver MUST include this element
information item The ultimate SOAP receiver MAY include
this element information item to indicate
explicitly that it generated the fault.
The faultrole element information item
has:
A local name of faultrole
A namespace name which is empty
The type of the faultrole element information
item isanyURI in the
http://www.w3.org/2001/XMLSchema namespace. It is
similar to the SOAP
roleattribute information item (see
3.2.2 SOAP role Attribute) except that the
value of the faultrole element information
item identifies the role the node was playing at the
point the fault occured.
The detail element information item
has:
A local name of detail ;
A namespace name which is empty;
Zero or more attribute information items;
Zero or more child element information items.
The detail element information item
is intended for carrying application specific error
information related to the SOAP Body . It 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 .
This can be used to find out whether the SOAP Body
was at least partially processed by the ultimate SOAP receiver
before the fault occurred, or not.
All child element information items of
the detail element Information Item are
called detail entries.
Each such element information item:
MAY be namespace qualified;
MAY have an encodingStyleattribute
information item.
The SOAP encodingStyleattribute information
item is used to indicate the encoding style used for
the detail entries (see 3.1.1 SOAP encodingStyle Attribute).
SOAP fault code (see 3.4.1 SOAP faultcode Element) values are XML qualified names [7] from the table below. The namespace identifier for these SOAP fault code values is "http://www.w3.org/2001/12/soap-envelope".
The values of the faultcode element are restricted
to those in the table below. Specifications that wish to implement their
own fault codes MUST do so by sub-categorizing an existing fault code
via the subcode element.
The fault code values defined by this specification are listed in the following table.
| Name | Meaning |
|---|---|
| VersionMismatch | The processing party found an invalid namespace
for the SOAP Envelope element
information item (see 2.8 SOAP Versioning Model and 3.4.7 VersionMismatch Faults) |
| MustUnderstand | An immediate child element information
item of the SOAP Header element
information item that was either not understood
or not obeyed by the processing party contained a SOAP
mustUnderstandattribute information
item with a value of "true" (see
3.2.3 SOAP mustUnderstand Attribute and 3.4.8 MustUnderstand Faults) |
| DTDNotSupported | The SOAP message contained a Document Type Definition (see 1.2 Relation to other XML Specifications). |
| DataEncodingUnknown | A header or body targetted at the current SOAP node is scoped (see 3.1.1 SOAP encodingStyle Attribute) with a data encoding that the current node does not support. |
| Sender | A Sender fault code
indicates that the message was incorrectly formed or
did not contain the appropriate information in order
to succeed. For example, the message could lack the
proper authentication or payment information. It is
generally an indication that the message should not be
resent without change (see also 3.4 SOAP Fault for a
description of the SOAP fault detail sub-element).
|
| Receiver | The Receiver fault code
indicates that the message could not be processed for
reasons not directly attributable to the contents of
the message itself but rather to the processing of the
message. For example, processing could include
communicating with an upstream SOAP node, which did
not respond. The message may succeed at a later point
in time (see also 3.4 SOAP Fault
for a description of the SOAP fault detail
sub-element). |
When a SOAP node generates a VersionMismatch fault, it
SHOULD provide, in the generated fault message, an
Upgrade header block as described below which
detail the qualified names (QNames, per the XML Schema
Datatypes specification[5]) of the
supported SOAP envelopes that the SOAP node supports (see
2.8 SOAP Versioning Model).
The Upgrade header block consists of an
Upgrade element information item
containing an ordered list of qualified names of SOAP
envelopes that the SOAP node supports in the order most to
least preferred.
The Upgrade element information
item has:
A local name of Upgrade ;
A namespace name of http://www.w3.org/2001/12/soap-upgrade;
One or more envelope child element
information items as described below:
The envelope element information
item has:
A local name of envelope ;
A namespace name which is empty;
An unqualified attribute information item with a
local name of qname and a type of QName in
the "http://www.w3.org/2001/XMLSchema" namespace.
Following is an example of a SOAP node that supports both
SOAP Version 1.2 and SOAP/1.1 but which prefers SOAP Version
1.2 (see appendix A Version Transition From SOAP/1.1 to SOAP Version 1.2 for a mechanism
for transitioning from SOAP/1.1 to SOAP Version 1.2). This
is indicated by including an Upgrade header block
with two envelope element information
items, the first containing the local name and
namespace name of the SOAP Version 1.2 Envelope element information item, the latter the local
name and namespace name of the SOAP/1.1 Envelope
element.
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/10/soap-envelope">
<env:Header>
<V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-upgrade">
<envelope qname="ns1:Envelope"
xmlns:ns1="http://www.w3.org/2002/10/soap-envelope"/>
<envelope qname="ns2:Envelope"
xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>
</V:Upgrade>
</env:Header>
<env:Body>
<env:Fault>
<faultcode><value>env:VersionMismatch</value></faultcode>
<faultstring>Version Mismatch</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>When a SOAP node generates a MustUnderstand fault, it SHOULD provide, in the generated fault message, header blocks as described below which detail the qualified names (QNames, per the XML Schema Datatypes specification[5]) of the particular header block(s) that were not understood.
It is NOT a requirement that a MustUnderstand fault contains the qualified names of ALL header blocks that were not understood in a SOAP message. A SOAP node MAY generate a fault after the first header block causing a MustUnderstand SOAP fault containing information about that single header block only. Alternatively SOAP nodes MAY generate a combined MustUnderstand SOAP fault containing information about all the header blocks that caused a MustUnderstand fault at once.
Each such header block element information item has:
A local name of Misunderstood ;
A namespace name of http://www.w3.org/2001/12/soap-faults;
A qnameattribute information
item as desribed below.
The qnameattribute information item
has the following Infoset properties:
A local name of qname;
A namespace name which is empty;
A specified property with a value of true.
The type of the qnameattribute information
item is QName in the
http://www.w3.org/2001/XMLSchema namespace. Its
value is the QName of a header block which the faulting node
failed to understand.
Consider the following message:
Extension1 or Extension2 are not
understood<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'>
<env:Header>
<abc:Extension1 xmlns:abc='http://example.org/2001/06/ext'
env:mustUnderstand='1' />
<def:Extension2 xmlns:def='http://example.com/stuff'
env:mustUnderstand='1' />
</env:Header>
<env:Body>
. . .
</env:Body>
</env:Envelope>The above message would result in the fault message shown
below if the recipient of the initial message does not
understand the two header elements abc:Extension1
and def:Extension2 .
Extension1 and
Extension2 <?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'
xmlns:f='http://www.w3.org/2001/12/soap-faults' >
<env:Header>
<f:Misunderstood qname='abc:Extension1'
xmlns:abc='http://example.org/2001/06/ext' />
<f:Misunderstood qname='def:Extension2'
xmlns:def='http://example.com/stuff' />
</env:Header>
<env:Body>
<env:Fault>
<faultcode><value>env:MustUnderstand</value></faultcode>
<faultstring>One or more mandatory
headers not understood</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>Note:
When serializing the qnameattribute
information item there must be an in-scope namespace
declaration for the namespace name of the misunderstood
header and the value of the attribute information
item must use the prefix of such a namespace
declaration. The prefix used need not be the same as the
one used in the message that was misunderstood.
As part of communicating in a distributed environment, it may be necessary to deploy a variety of features generally associated with the exchange of messages. For the purpose of this specification, the term "feature" is used to identify an abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes. Although SOAP poses no constraints on the potential scope of such features, examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require a varity of message exchange patterns (MEPs) like for example one-way messages, request/response interactions, and peer-to-peer conversations. MEPs are considered to be a type of feature; unless otherwise stated, references to the term "feature" apply also to MEPs.
SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. As a result, most features often found in distributed systems have been left out of the messaging framework. While it is anticipated that many such features will be defined for SOAP, it is beyond the scope of this specification to do so. Instead, they are expected to be defined as extensions to SOAP.
The SOAP extensibility model provides two mechanisms through which features may be expressed: the SOAP Processing Model and the SOAP Protocol Binding Framework (see 2 SOAP Processing Model and 5 SOAP Protocol Binding Framework). The former describes the behavior of a single SOAP node with respect to the processing of an individual message. The latter mediates the act of sending and receiving SOAP messages by a SOAP node via an underlying protocol.
The SOAP Processing Model enables SOAP nodes that include the mechanisms necessary to implement one or more features to express such features within the SOAP envelope as header blocks (see 2.4 Understanding SOAP Headers). Such header blocks can be intended for any SOAP node or nodes along a SOAP message path (see 2.3 Targeting SOAP Header Blocks).
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 5 SOAP Protocol Binding Framework).
The combination of the SOAP Processing Model and the SOAP Protocol Binding Framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as header blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions.
Certain features may require end-to-end as opposed to hop-to-hop processing semantics. While the SOAP Protocol Binding Framework provides for the possibility that such features may be expressed outside the SOAP envelope, it does not define a specific architecture for the processing or error handling of these externally expressed features by a SOAP intermediary. A binding specification that expresses such features external to the SOAP envelope should define its own processing rules to which a SOAP node is expected to conform (for example, describing what information must be passed along with the SOAP message as it leaves the intermediary). It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that the rules defined by the SOAP Processing Model can be employed.
SOAP enables exchange of SOAP messages using a variety of underlying protocols. The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of exchange is called a binding. The SOAP Protocol Binding Framework provides a scheme for describing bindings and how they relate to SOAP nodes through a binding specification. As an example of a binding specification, SOAP Part 2: Adjuncts[1] includes the specification for a binding to HTTP. Additional bindings can be created by specifications that conform to the binding framework introduced in this chapter.
A SOAP binding specification declares the features provided by a binding and describes how the services of the underlying protocol are used to honor the contract formed by the declaration of features supported by that binding. In addition, a binding specification defines the requirements for building a conformant implementation of the binding being specified.
A binding does not provide a separate processing model and does not constitute a SOAP node by itself. Rather a SOAP binding is an integral part of a SOAP node (see 2 SOAP Processing Model).
The goals of the binding framework are:
To set out the requirements and concepts that are common to all binding specifications.
To facilitate homogenous description of bindings that support common features.
To facilitate homogenous description of optional features.
Note, that the second and third goals above are related. Two or more bindings may offer a given optional feature, such as reliable delivery, with one binding exploiting an underlying protocol that directly facilitates the feature (the protocol is reliable), and the other providing the logic (logging and retransmission) in the binding. In such case, the feature can be made available to applications in a consistent manner, regardless of which binding is used.
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.
Thus, 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.
As described above, SOAP can be augmented with optional features, (such as reliable message delivery, request/response MEPs, multicast MEPs, etc.). The specification of each such feature MUST include the following:
The information (state) required at each node to implement the feature.
The processing required at each node in order to fulfill the obligations of the feature.
The information to be transmitted from node to node, and in the case of MEPs, any requirements to generate additional messages (such as responses to requests in a request/response MEP) and rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP.
A binding specification MUST enable one or more MEPs. A binding specification MAY state that it supports additional features, in which case the binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those 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; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.
The binding framework provides no fixed means of naming or typing the information comprising the state at a given node. Individual feature and binding specifications are free to adopt their own conventions for specifying state. Note, however, that consistency across bindings and features is likely to be enhanced in situations where multiple feature specifications adopt consistent conventions for representing state. For example, multiple features may benefit from a consistent specification for an authentication credential, a transaction ID, etc. The HTTP binding in SOAP Part 2[1] illustrates one such convention.
As described in 3 SOAP Message Construct, each SOAP message is modeled as an XML Infoset that consists of a document information item with exactly one child: the envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP XML Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol.
The binding framework does NOT require that every binding use the XML 1.0[8] serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate. A binding, if using XML 1.0 serialization of the infoset, MAY mandate that a particular character encoding or set of encodings be used.
Bindings MAY 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 URI) that is not
within the envelope; the HTTP binding in Part 2[1]
(see Using SOAP in HTTP)
transmits an HTTP field named SOAPAction that is not
contained within the SOAP XML Infoset.
The SOAP Framework does not directly provide any mechanisms for dealing with access control, confidentiality, integrity and non-repudiation. Such mechanisms can either be provided as SOAP extensions using the SOAP extensibility model (see 4 SOAP Extensibility Model) or through features expressed within the underlying protocol and made available to SOAP applications through the SOAP binding framework (see 5 SOAP Protocol Binding Framework). This section describes the security considerations that designers and implementers should take into consideration when designing and using such mechanisms.
SOAP implementers should anticipate rogue SOAP applications sending intentionally malicious data to a SOAP node (see 2 SOAP Processing Model). Similarly, SOAP nodes should be aware of the implications of sending data to other SOAP nodes in case those nodes are malicious. It is strongly recommended that a SOAP node receiving a SOAP message is capable of evaluating to what level it can trust the sender of that SOAP message and its contents. Likewise, any SOAP node sending a SOAP message to another SOAP node should be capable of evaluating to what level it can trust the receiving SOAP node to process the message responsibly. This applies not only to ultimate recipients but also SOAP intermediaries.
SOAP can carry application-defined data as SOAP header blocks or as SOAP body contents. Processing a SOAP header block may include dealing with side effects such as state changes, logging of information, or the generation of additional messages. It is strongly recommended that only well-defined header blocks with known security implications of any side effects be processed by a SOAP node.
As for SOAP header blocks, processing a SOAP body may imply the occurrence of side affects that may, if not properly understood, have severe consequences for the receiving SOAP node. As for SOAP header blocks, it is strongly recommended that only well-defined body contents with known security implications be processed.
Security considerations, however, are not just limited to recognizing the immediate child elements of the SOAP header and the SOAP body. Implementers should pay special attention to the security implications of all data carried within a SOAP message that can cause the remote execution of any actions in the recipient's environment. This includes not only data expressed in XML infoset but data that may be encoded as binary data or carried as parameters like for example URI query strings. Before accepting data of any type, an application should be aware of the particular security implications associated with that data within the context it is being used.
SOAP implementers should be careful to ensure that if processing of the various parts of a SOAP message is provided through modular software architecture, that each module is aware of the overall SOAP security context. For example, a SOAP body should not be processed without knowing the SOAP context in which it was received.
SOAP inherently provides a distributed processing model that may involve a SOAP message passing through multiple SOAP nodes (see 2 SOAP Processing Model). SOAP intermediaries are by definition men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Security breaches on systems that run SOAP intermediaries can result in serious security and privacy problems. A compromised SOAP intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
In analyzing the security implications of potential SOAP related security problems, it is important to realize that the scope of security mechanisms provided by the underlying protocol may not be the same scope as the whole message path of the SOAP message. There is no requirement in SOAP that all hops between participating SOAP nodes use the same underlying protocol and even if this was the case, the very use of SOAP intermediaries is likely to reach beyond the scope of transport-level security.
The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Binding specification authors should describe, in detail, the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification (see 5 SOAP Protocol Binding Framework).
In addition, a binding specification may not address or provide countermeasures for all aspects of the inherent security risks. The binding specification authors should identify any such risks as might remain and indicate where further countermeasures would be needed above and beyond those provided for in the binding specification.
Binding specification authors should be aware that SOAP extension modules expressed as SOAP header blocks may affect the underlying protocol in unforeseen ways. It is strongly recommended that a binding specification should describe any such interactions. For example, a SOAP message carried over a particular protocol binding may result in seemingly conflicting features such as might be the case with HTTP basic auth combined with a SOAP based authentication mechanism.
Some underlying protocols may be designed for a particular purpose or application profile. SOAP bindings to such protocols MAY use the same endpoint identification (e.g., TCP port number) as the underlying protocol, in order to reuse the existing infrastructure associated that protocol.
However, the use of well-known ports by SOAP may incur additional, unintended handling by intermediaries and underlying implementations. For example, HTTP is commonly thought of as a "Web browsing" protocol, and network administrators may place certain restrictions upon its use, or may interpose services such as filtering, content modification, routing, etc. Often, these services are interposed using port number as a heuristic.
As a result, binding definitions for underlying protocols with well-known default ports or application profiles SHOULD document potential (harmful?) 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.
SOAP uses URIs for some identifiers including, but not
limited to, values of the encodingStyle
(see 3.1.1 SOAP encodingStyle Attribute) and role
(see 3.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 via any other characteristics.
Although this section only applies to URIs directly used by information items defined by this specification, it is RECOMMENDED but NOT REQUIRED that application-defined data carried within a SOAP envelope use the same mechanisms and guidelines defined here for handling URIs.
URIs used as values in information items identified by the "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" XML namespaces can be either relative or absolute.
SOAP does not define a base URI but relies on the mechanisms defined in XML Base[11] and RFC 2396[6] for establishing a base URI against which relative URIs can be made absolute.
The underlying protocol binding MAY define a base URI which can act as the base URI for the SOAP envelope (see 5 SOAP Protocol Binding Framework and the HTTP binding[1]).
SOAP does not define any equivalence rules for URIs in general as these are defined by the individual URI schemes and by RFC 2396[6]. However, because of inconsistencies with respect to URI equivalence rules in many current URI parsers, it is RECOMMENDED that SOAP senders do NOT rely on any special equivalence rules in SOAP receivers in order to determine equivalence between URI values used in a SOAP message.
The use of IP addresses in URIs SHOULD be avoided whenever possible (see RFC 1900[18]). However, when used, the literal format for IPv6 addresses in URI's as described by RFC 2732[12] SHOULD be supported.
SOAP does not place any a priori limit on the length of a URI. Any SOAP node MUST be able to handle the length of any URI that it publishes and both SOAP senders and SOAP receivers SHOULD be able to deal with URIs of at least 2048 characters in length.
The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:
A SOAP/1.1 node receiving a SOAP Version 1.2 message will
according to SOAP/1.1 generate a VersionMismatch SOAP
fault based on a SOAP/1.1 message construct. That is, the
envelope will have a local name of Envelope and a
namespace name of
"http://schemas.xmlsoap.org/soap/envelope/".
A SOAP Version 1.2 node receiving a SOAP/1.1 message either
MAY process the message as a SOAP/1.1 message (if supported), or
MUST generate a VersionMismatch SOAP fault based on a
SOAP/1.1 message construct following SOAP/1.1
semantics. The SOAP fault SHOULD include an
Upgrade header block as defined in this
specification (see 3.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.
Below is an example of a VersionMismatch SOAP fault generated
by a SOAP Version 1.2 node as a result of receiving a SOAP/1.1
message. The fault message is a SOAP/1.1 message with an
Upgrade header block indicating support for SOAP
Version 1.2.
Upgrade
header block indicating support for SOAP Version 1.2.<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-upgrade">
<envelope qname="ns1:Envelope"
xmlns:ns1="http://www.w3.org/2001/12/soap-envelope"/>
</V:Upgrade>
</env:Header>
<env:Body>
<env:Fault>
<faultcode><value>env:VersionMismatch</value></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.
This document is the work of the W3C XML Protocol Working Group.
Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), Charles Campbell (Informix Software), Michael Champion (Software AG), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dietmar Gaertner (Software AG), Rich Greenfield (Library of Congress), Martin Gudgin (DevelopMentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Henry Lowe (OMG), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Highland Mary Mountain (Intel), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (BEA Systems), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Herve Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Asir Vedamuthu (webMethods) Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Jin Yu (Martsoft Corp.).
Previous members were: Eric Fedok (Active Data Exchange), Susan Yee (Active Data Exchange), Dan Frantz (BEA Systems), Alex Ceponkus (Bowstreet), James Tauber (Bowstreet), Rekha Nagarajan (Calico Commerce), Mary Holstege (Calico Commerce), Krishna Sankar (Cisco Systems), David Burdett (Commerce One), Murray Maloney (Commerce One), Jay Kasi (Commerce One), Yan Xu (DataChannel), Brian Eisenberg (DataChannel), Mike Dierken (DataChannel), Michael Freeman (Engenia Software), Bjoern Heckel (Epicentric), Dean Moses (Epicentric), Julian Kumar (Epicentric), Miles Chaston (Epicentric), Alan Kropp (Epicentric), Scott Golubock (Epicentric), Michael Freeman (Engenia Software), Jim Hughes (Fujitsu Limited), Dick Brooks (Group 8760), David Ezell (Hewlett Packard), Fransisco Cubera (IBM), David Orchard (Jamcracker), Alex Milowski (Lexica), Steve Hole (MessagingDirect Ltd.), John-Paul Sicotte (MessagingDirect Ltd.), Vilhelm Rosenqvist (NCR), Lew Shannon (NCR), Art Nevarez (Novell, Inc.), David Clay (Oracle), Jim Trezzo (Oracle), David Cleary (Progress Software), Andrew Eisenberg (Progress Software), Peter Lecuyer (Progress Software), Ed Mooney (Sun Microsystems), Mark Baker (Sun Microsystems), Anne Thomas Manes (Sun Microsystems), George Scott (Tradia Inc.), Erin Hoffmann (Tradia Inc.), Conleth O'Connell (Vignette), Waqar Sadiq (Vitria Technology Inc.), Randy Waldrop (WebMethods), Bill Anderson (Xerox), Tom Breuel (Xerox), Matthew MacKenzie (XMLGlobal Technologies), David Webber (XMLGlobal Technologies), John Evdemon (XMLSolutions) and Kevin Mitchell (XMLSolutions).
The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.
| Date | Author | Description |
|---|---|---|
| 20020311 | HFN | Say that versioning is determined based on the namespace name AND local name of the document information item. If the namespace name AND local name doesn't match then generate a VersionMismatch fault. |
| 20020311 | HFN | Say that ALL VersionMismatch faults SHOULD use the Upgrade header block for describing which revision they support. Editorially, this means moving the description of the Upgrade header block into section 3.4 rather than having it in appendix |
| 20020311 | HFN | Make it clear that SOAP/1.1 is ONLY used it VersionMismatch fault IF the sender is a SOAP/1.1 node. Otherwise, use SOAP 1.2 envelope. |
| 20020311 | HFN | Turned into a note: "Note that when serializing the
qnameattribute information
item there must be an in-scope namespace
declaration for the namespace name of the
misunderstood header and the value of the
attribute information item must use the
prefix of such a namespace declaration" |
| 20020311 | HFN | In section 3.4.8 MustUnderstand Faults moved last paragraph to beginning and made the requirements to a SOAP node clear (was written as a note) |
| 20020311 | HFN | Moved section on Upgrade fault element from appendix to section 3.4 in a manner similar to the MustUnderstand fault subsection in the same section. |
| 20020314 | HFN | Added reference to 3.4 SOAP Fault for issue 182 resolution. |
| 20020318 | HFN | The section on SOAP Extensibility (see 4 SOAP Extensibility Model) showed signs of originally being the introduction to the Protocol Binding Framework (see 5 SOAP Protocol Binding Framework) and needed some editorial work in order to stand on its own. This section was "promoted" to a top-level section by simply moving it out of section 5 SOAP Protocol Binding Framework. The text is now rebalanced. There should be no semantic changes, merely a rewrite to make it more clear what we mean by features. The involved sections are section 4 SOAP Extensibility Model, the introduction of 5 SOAP Protocol Binding Framework, and section 5.1 Goals of the Binding Framework. |
| 20020318 | JJM | Removed duplication between section "2.5 Structure and Interpretation of SOAP Bodies" and section "3.3 SOAP Body". |
| 20020318 | JJM | Trimmed down the introductions to the sub-sections of section 3, in a way Henrik and I both feel comfortable with. |
| 20020318 | JJM | Finsihed incorporating Noah's comments on Part1, albeit two issues raised separately. |
| 20020315 | HFN | Lower-cased MAY in the last paragraph in section 2.6 Processing SOAP Messages as these are not requirements on anything in our spec and the paragraph is a note in the first place. |
| 20020316 | HFN | In the introduction, changed the word "transmit" to "exchange" in places where transmit and receive is implied. |
| 20020316 | HFN | In the introduction, removed reference to header block and body before these are introduced. |
| 20020314 | HFN | Added reference to 3.4 SOAP Fault for issue 182 resolution. |
| 20020312 | HFN | In section 3.1 SOAP Envelope, changed:
"The document element information item
has:..." with "The Envelope element
information item has:..." |
| 20020314 | JJM | Added back comments from Noah |
| 20020314 | JJM | Added revised definition for ultimate receiver, after Henrik and Noah's approval. |
| 20020312 | MJH | Added issue 182 resolution. |
| 20020311 | HFN | Glossary: added "feature": "An abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes (see 4 SOAP Extensibility Model). Examples of features include "reliability", "security", "correlation", "routing", and the concept of message exchange patterns." |
| 20020311 | HFN | Glossary: moved "soap application" under "protocol concepts" (was in "Message Sender and Receiver Concepts") as it belongs better there. |
| 20020310 | HFN | Clarified example in section 1.3 |
| 20020310 | HFN | Made cross references consistent of the form (see X) |
| 20020310 | HFN | Made editorial changes to section Envelope Versioning Model and moved to section 2 as it is a part of the processing model |
| 20020310 | HFN | Added XML Protocol requirements document as a non-normative reference |
| 20020310 | HFN | Removed paragraph as it is no longer used: "The namespace prefixes "xs" and "xsi" used in the prose sections of this document are associated with the namespace names "http://www.w3.org/2001/XMLSchema" and "http://www.w3.org/2001/XMLSchema-instance" respectively, both of which are defined in the XML Schemas specification[4],[5]." |
| 20020310 | HFN | Removed paragraph as it is no longer used: "The namespace prefixes "env" used in the prose sections of this document are associated with the SOAP namespace names "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" respectively." |
| 20020310 | HFN | Updated example in section 3.1.2: the description of the encodingStyle attribute: it was written as if it is part of the encoding schema, it is not |
| 20020310 | HFN | Updated introduction to read better and removed section 1.1 Design Goals as this is now part of the general introduction |
| 20020310 | HFN | Changed "SOAP Message Structure" to "SOAP Message Construct" as a) I think it is more appropriate and b) It doesn't confuse the use of structure used elsewhere in the document. |
| 20020310 | HFN | Updated abstract to read better |
| 20020308 | HFN | Incorporated resolution to issue 137 |
| 20020305 | JJM | Started incorporating Noah's comments on the latest ed's copy. |
| 20020304 | HFN | Changed "It is based on XML..." to "It is based on XML Infoset..." |
| 20020304 | HFN | Restructured section 3 and moved to section 1 as 1.3 "Relation to other XML Specifications" |
| 20020304 | HFN | Removed the following paragraph from (new) 1.3 as it is duplicated in section 4: "A SOAP node MUST ensure that all element information items and attribute information items in messages that it generates are correctly namespace qualified. A SOAP node MUST be able to process SOAP namespace information in messages that it receives. It MUST treat messages with incorrect namespace information as described in 2.8 SOAP Versioning Model." |
| 20020304 | HFN | Moved the following paragraph to section 4 as it enables us to gather all strict requirements in one place. "People get confused if there are requirements spread out all over the place. A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 3.4 SOAP Fault) with a fault code of "DTDNotSupported". A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives." |
| 20020304 | HFN | Added text to (new) 1.3 to clarify relationship with XML namespaces, XML base, and XML schema. |
| 20020304 | HFN | Clarified relationship to schema based on Noah's formulation |
| 20020324 | HFN | Renamed "4 SOAP Envelope" to "4 SOAP Message Structure" and introduced a new section called 4.1 "SOAP Envelope" |
| 20020324 | HFN | Removed the heading in section 4.1 "Envelope Encoding and Versioning" and promoted section 4.1.1 and 4.1.2 to 4.1 and 4.2 respectively (I reordered them as I think the versioning model is more important). |
| 20020324 | HFN | In section "SOAP encodingStyle Attribute" modified the paragraph to say that encodingStyle can't appear on the Envelope information item |
| 20020324 | HFN | As per Gudge's suggestion, moved SOAP Extensibility Model to section 3 just after the processing model. |
| 20020228 | HFN | Updated abstract slightly |
| 20020228 | HFN | Incorporated resolution to issue 178 |
| 20020228 | HFN | Insert resolution to issue 179, replacing 'support' with 'enable' |
| 20020228 | HFN | Insert resolution of issue 103 with the following modifications; a) "Normally" with "in the absence of faults" b) "recipient" with "receiver" c) "the ultimate" with "an ultimate" |
| 20020228 | HFN | Move section 6.3 into 6.4 and add security considerations text. |
| 20020228 | HFN | Added first part of resolution of issue 59: "It is the responsibility of transport bindings to specify how the infoset is being transfered to and reconstituted by the binding at the receiving node. Such a binding, if using XML 1.0 serialization of the infoset, may mandate that a particular character encoding or set of encodings be used." |
| 20020221 | MJG | Edited examples so that no line is longer than 66 characters |
| 20020219 | HFN | Updated section 7: removed reference to href and clarified suggestion for length of URIs. |
| 20020219 | MJG | Qualified encoding attributes in examples. |
| 20020218 | HFN | Added resolution text for issue 102: "and rules for the delivery or other disposition of SOAP faults generated during the operation of the MEP" |
| 20020216 | MJG | Added text to Section 3 explaining where schema documents are located |
| 20020216 | MJG | Added hierarchical fault types to soap-envelope schema |
| 20020215 | MJH | Inserted section 2 rewrite and associated changes to section 4. |
| 20020215 | HFN | Promoted section 5.1 to top-level section 5 and moved the rest of the old section 5 to top-level section 6 |
| 20020131 | MJH | Removed the sentence that said that an encodingStyle value that was prefixed with the SOAP encoding style URI indicated a restricted version of the SOAP encoding. This change was agreed on the conf call of 20020130, but no issue existed for it. |
| 20020131 | MJH | Removed old ednote asking for feedback on the new requirement that direct children of the body be namespace qualified. |
| 20020131 | MJH | Fixed text on Body element to match schema. This change was agreed on the conf call of 20020130 but no issue existed for it. Body element allows zero or more unspecified attribute information items including encodingStyle. Removed ednotes that previously highlighted the removed contradiction. |
| 20020129 | MJH | Removed duplication in list of goals of binding framework (Sect 5.2). |
| 20020121 | MJH | Rolled in most of the suggested editorial changes from John Ibbotson. Section 2 not changed. |
| 20020117 | MJH | Added hierarchical fault codes (issue 173). |
| 20011213 | MJH | Updated namespace URIs, fixed spelling error. |
| 20011211 | MJH | Added section headings for faultcode, faultstring, faultactor and detail elements. |
| 20011211 | MJH | Fixed a number of spelling errors and grammatical problems throughout the document. Applied some limited rewording to improve readability. |
| 20011211 | MJH | Removed duplicate description of "must happen" extension from section 2. |
| 20011206 | MJH | Removed more mentions of body blocks. |
| 20011206 | MJH | Limited rewording and removal of duplication from section 2. In particular, removed namespace definition for mU and actor (this is in section 4) and massaged text in processing model to remove duplication and improve readability. |
| 20011206 | MJH | Incorporated Chris Ferris suggested changes to glossary and section 2. |
| 20011206 | MJH | General editorial work on new sections. Added references and other tagging as required. |
| 20011206 | MJH | Incorporated agreed changes to URIs in SOAP section (remove duplication with XML base and cite XML base more strongly). |
| 20011206 | MJH | Incorporated issue 155 resolution. |
| 20011205 | JJM | Elevated the header removal step to a processing model step. |
| 20011204 | MJH | Added bibref to Use of URIs section and tidied up the language in that section. |
| 20011204 | MJH | Modified soapEncoding descriptive text - Issues 159 and 166. |
| 20011204 | JJM | Added text to section 2.2, second paragraph, to indicate none blocks may carry data for processing of other blocks. |
| 20011204 | JJM | Section 2.2, four paragraph, added "anonymous actor" to the list. |
| 20011204 | JJM | Section 2.3, remove text for SOAP body blocks. |
| 20011204 | JJM | Section 2.3, replace "has assumed the role of the anonymous actor" by "is the ultimate receiver". |
| 20011204 | JJM | Section 2.4, incorporated 2 paragraph previously in section 2. |
| 20011204 | JJM | Added section 2.5 (text from Noah). |
| 20011204 | JJM | Added an extra step to the processing model (now section 2.6). |
| 20011204 | JJM | Simplified step 3, and moved the previous text further below in the same section (2.6). |
| 20011204 | JJM | Section 2.6, incorporated text from section 4. |
| 20011204 | JJM | Section 4.2.2, removed explanation of next and none roles. |
| 20011204 | JJM | Section 4.2.2, added text to indicate the meaning of an empty actor attribute. |
| 20011204 | JJM | Trimmed section 4.2.3, as the text is now in section 2. |
| 20011204 | JJM | Removed section 4.3.1, since body processing is now in section 2.6. |
| 20011204 | JJM | Added ednote to flag the definition for SOAP block is out of date. |
| 20011204 | JJM | Reformated section 5 (Binding Framework). |
| 20011204 | JJM | Reformated section 6 (Use of URIs in SOAP). Removed non ASCII characters. |
| 20011204 | JJM | Added missing "att" and "attval" around elements and attributes in section 6. |
| 20011204 | JJM | Fixed a number of lax references in section 6. |
| 20011201 | HFN | Added SOAP Protocol Binding Framework |
| 20011201 | HFN | Added section on URIs and XML Base |
| 2001129 | MJG | Incorporated resolution text for Issue 146 into Section 2.3 |
| 2001129 | MJG | Changed "Client" and "Server" fault codes to be "Sender" and "Receiver" respectively as resolution of Issue 143 |
| 2001129 | MJG | Removed dot notation from spec. Added "DTDNotSupported" fault code to fault code table. |
| 20011122 | MJH | Incorporated resolution to issue 172 (criteria for generating version mismatch fault into 2.8 SOAP Versioning Model. Removed duplication of versioning error text and associated ednote from 1.2 Relation to other XML Specifications |
| 20011029 | MJH | Changed "default actor" to "anonymous actor". |
| 20011029 | MJH | Amended relation to XML section (Issue 135). |
| 20011029 | MJH | Amended section 2.5 (Issue 157). |
| 20011029 | MJH | Removed citation of ABNF - not used in part 1. |
| 20011029 | MJH | Amended section 1.3 (Issue 150) |
| 20011029 | MJH | Amended section 1.1 (Issue 149) |
| 20011029 | MJH | Amended introductory text (Issue 148) |
| 20011029 | MJH | Amended introductory text (Issue 147) |
| 20011029 | MJH | Amended abstract (Issue 147) |
| 20011026 | MJG | Amended text in Section 2.5 bullet 2 ( Issue 158 ) |
| 20011026 | MJG | Amended text in Section 2.4 para 2 ( Issue 156 ) |
| 20011026 | MJG | Amended text in Section 2.1 para 2 ( Issue 152 ) |
| 20011026 | MJG | Amended prose related to DTDs and PIs ( Issue 4 ) |
| 20011026 | MJG | Added text to state that SOAP is no longer an acronym ( Issue 125 ) |
| 20011026 | MJG | Amended description of Upgrade extension in Appendix A to be Infoset based. |
| 20011026 | MJG | Added an example of returning multiple versions in the VersionMismatch header to Appendix A ( Issue 119 ) |
| 20011026 | MJG | Added definition of SOAP Application to glossary ( Issue 139 ) |
| 20011026 | MJG | Added xml declaration to all XML examples with a root of env:Envelope or xs:schema ( Issue 10 ) |
| 20011025 | MJG | Changed MAY to MUST regarding namespace qualification of SOAP body blocks ( Issue 141 ) |
| 20011011 | MJG | Added para to section 2.2 on criteria ( or lack thereof ) for determining whether a SOAP node acts as a particular actor |
| 20010926 | MJG | Updated member list |
| 20010926 | MJG | Removed extra double quotes around certain URLs |
| 20010921 | MJG | Changed targetNamespace attribute of faults schema to http://www.w3.org/2001/09/soap-faults |
| 20010921 | MJG | Changed targetNamespace attribute of upgrade schema to http://www.w3.org/2001/09/soap-upgrade |
| 20010921 | MJG | Changed targetNamespace attribute of envelope schema to http://www.w3.org/2001/09/soap-envelope |
| 20010921 | MJG | Modified content model of Envelope complex type in envelope schema to disallow content after the Body element. |
| 20010920 | JJM | Included MarkN's text regarding issue 11 and 13 as amended by Stuart in the specification and expand the ednote appropriately. |
| 20010920 | JJM | Change the namespace of the envelope to http://www.w3.org/2001/09/... |
| 20010918 | JJM | Incorporated several editorial comments from Stuart Williams. |
| 20010918 | JJM | Removed reference to trailer from the "SOAP Envelope" section. |
| 20010914 | JJM | Fixed issues 124, 126, 127, 128 and 132. |
| 20010914 | JJM | Used the rewrite from Mark Nottingham for section "SOAPAction attribute". |
| 20010914 | JJM | Incoporated text from Mark Nottingham clarifying the role of none blocks. |
| 20010914 | JJM | Reference the XML InfoSet Proposed Recommandation instead of the Candidate Recommandation. |
| 20010911 | JJM | Changed XML Information Set into a normative reference. Changed XML Protocol Comments Archive, Discussion Archive and Charter into non-normative references. Removed "as illustrated above" from section 2. Added missing parantheses in sections 2.5 and 4.1.1. |
| 20010905 | MJH | Wordsmithed abstract and introduction to better reflect split into parts 1 and 2. Rationalised list of references so only cited works appear. Removed encoding schema changes. Added bibref entries for cross references to Part 2, fixed links so they target the HTML instead of XML version of the doc. |
| 20010831 | JJM | Added a close paragraph tag before starting a new olist or ulist. |
| 20010831 | JJM | Properly declared the language for the spec, so that we can generate valid HTML. |
| 20010830 | MJG | Added an element declaration for a Fault element of type Fault to the envelope schema |
| 20010830 | JJM | Removed terminology not relevant for part1. |
| 20010830 | JJM | Moved some introductory examples to part2. |
| 20010830 | JJM | Moved SOAP example appendix to part2. |
| 20010830 | JJM | Added a paragraph to section 1 pointing to part2 for encoding, rpc and http binding. |
| 20010829 | JJM | Added a placeholder for the forthcoming Transport Binding Framework section. |
| 20010829 | JJM | Updated the spec's title. |
| 20010829 | JJM | Replaced specref with xspecref for references to Part2 items. |
| 20010829 | JJM | Added bibliography entry for SOAP 1.2 Part 2. |
| 20010829 | JJM | Removed former sections 5, 6, 7 and 8. |
| 20010829 | JJM | Did split the spec into two parts. |
| 20010829 | JJM | Refered to the proper DTD and stylesheet. |
| 20010829 | JJM | Updated the list of WG members: one person per line in the XML file, for easier updating. |
| 20010816 | MJH | Replaced a mustUnderstand="1" with mustUnderstand="true". Slight rewording in mu description. |
| 20010810 | MJH | Merged in RPC fault rules text from Jacek. Added new DataEncodingUnknown fault code to SOAP Fault Codes section. Added editorial notes about introduction of new fault code namespace for RPC. |
| 20010809 | MJH | Merged in "mustHappen" descriptive text from Glen and Noah. |
| 20010809 | MJH | Fixed language around "default" values of attributes. |
| 20010809 | MJH | Removed HTTP extension framework, added editorial note to describe why. |
| 20010808 | MJH | Added Infoset "specified" property text from Chris. |
| 20010808 | MJH | Removed assumption 4 from version transition appendix. |
| 20010808 | MJH | Added reference to SOAP 1.1 specification to references section, removed SOAP 1.1 author list from acknowledgments section. |
| 20010807 | MJH | Converted specification from HTML to XML conforming to W3C XMLSpec DTD. Numerous resulting formatting changes. |
| 20010720 | MJG | Applied Infoset terminology to sections 1, 2, 3 and 4. |
| 20010629 | MJG | Amended description of routing and intermediaries in Section 2.1 |
| 20010629 | JJM | Changed "latest version" URI to end with soap12 |
| 20010629 | JJM | Remove "previous version" URI |
| 20010629 | JJM | Removed "Editor copy" in <title> |
| 20010629 | JJM | Removed "Editor copy" in the title. |
| 20010629 | JJM | Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft. |
| 20010629 | JJM | Pre-filed publication URIs. |
| 20010629 | JJM | Incorporated David's suggested changes for the examples in section 4.1.1 to 4.4.2 |
| 20010629 | JJM | Fixed some remaining typos. |
| 20010629 | MJH | Fixed a couple of typos. |
| 20010628 | MJG | Made various formatting, spelling and grammatical fixes. |
| 20010628 | MJG | Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50 |
| 20010628 | MJG | Changed text in Section 2.1 from 'it is both a SOAP sender or a SOAP receiver' to 'it is both a SOAP sender and a SOAP receiver' |
| 20010628 | MJG | Fixed caption on Example 24 |
| 20010628 | MJH | Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence. |
| 20010628 | MJH | Updated figure 1, removed ednote to do so. |
| 20010622 | HFN | Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model. |
| 20010622 | HFN | Moved the definition of block to encapsulation section in terminology |
| 20010622 | HFN | Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and doesn't belong in a terminology section |
| 20010622 | HFN | Removed reference to "Web Characterization Terminology & Definitions Sheet" in terminology section as this is not an active WD |
| 20010622 | HFN | Added revised glossary |
| 20010622 | HFN | Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding |
| 20010622 | MJG | Added http://example.com/... to list of application/context specific URIs in section 1.2 |
| 20010622 | MJG | Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes |
| 20010622 | MJG | Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1 |
| 20010622 | MJG | In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match. |
| 20010622 | MJG | Moved MisunderstoodHeader from envelope schema into seperate faults schema. Removed entry in envelope schema change table in Appendix D.2 that refered to additon of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2 |
| 20010622 | MJH | Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions. |
| 20010622 | MJG | Made BNF in section 6.1.1 into a table. |
| 20010622 | MJG | Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet |
| 20010622 | MJG | Amended text regarding namespace prefix mappings in section 1.2 |
| 20010622 | MJG | Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote. |
| 20010622 | MJG | Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document |
| 20010622 | MJG | Reordered entries in schema change classification table in Appendix D.2 |
| 20010622 | MJG | Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly |
| 20010622 | JJM | Manually numbered all the examples (53 in total!) |
| 20010622 | JJM | Added caption text to all the examples |
| 20010622 | JJM | Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>) |
| 20010621 | HFN | Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2 |
| 20010621 | HFN | Added version transition appendix C |
| 20010621 | HFN | Applied new styles to examples |
| 20010621 | HFN | Changed term "transport" to "underlying protocol |
| 20010621 | HFN | Changed example URNs to URLs of the style http://example.org/... |
| 20010621 | MJH | Updated the Acknowledgements section. |
| 20010621 | JJM | Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2. |
| 20010621 | JJM | Incorporated David Fallside's comments on section Status and Intro sections. |
| 20010620 | HFN | Changed the status section |
| 20010620 | HFN | Changed title to SOAP Version 1.2 and used that first time in abstract and in body |
| 20010620 | HFN | Removed question from section 2.4 as this is an issue and is to be listed in the issues list |
| 20010620 | HFN | Moved change log to appendix |
| 20010615 | JJM | Renamed default actor to anonymous actor for now (to be consistent) |
| 20010615 | JJM | Fixed typos in section 2 |
| 20010614 | JJM | Updated section 2 to adopt the terminology used elsewhere in the spec. |
| 20010613 | MJH | Updated mustUnderstand fault text with additions from Martin Gudgin. |
| 20010613 | MJH | Added schema changes appendix from Martin Gudgin. |
| 20010613 | MJH | Added mustUnderstand fault text from Glen Daniels. |
| 20010612 | MJH | Fixed document <title>. |
| 20010612 | MJH | Moved terminology subsection from message exchange model section to introduction section. |
| 20010612 | MJH | Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate. |
| 20010612 | MJH | Removed trailing "/" from encoding namespace URI. |
| 20010612 | MJH | Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org. |
| 20010612 | MJH | Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places. |
| 20010611 | MJH | Incorporated new text for section 2. |
| 20010611 | JJM | Changed remaining namespaces, in particular next. |
| 20010609 | JJM | Changed the spec name from XMLP/SOAP to SOAP. |
| 20010609 | JJM | Changed the version number from 1.1 to 1.2. |
| 20010609 | JJM | Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-. |
| 20010609 | JJM | Replaced the remaining XS and XE prefixes to env and enc, respectively. |
| 20010601 | MJH | Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation. |
| 20010601 | JJM | Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation. |
| 20010531 | HFN | Removed appendices C and D and added links to live issues list and separate schema files. |
| 20010531 | MJH | Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation. |
The envelope schema has been updated to be compliant with the XML Schema Recomendation[4][5]. The table below shows the categories of change.
| Class | Meaning |
|---|---|
| Addition | New constructs have been added to the schema |
| Clarification | The meaning of the schema has been changed to more accurately match the specification |
| Deletion | Constructs have been removed from the schema |
| Name | The schema has been changed due to a datatype name change in the XML Schema specification |
| Namespace | A namespace name has been changed |
| Semantic | The meaning of the schema has been changed |
| Style | Style changes have been made to the schema |
| Syntax | The syntax of the schema has been updated due to changes in the XML Schema specification |
The table below lists the changes to the envelope schema.
| Class | Description |
|---|---|
| Namespace | Updated to use the http://www.w3.org/2001/XMLSchema namespace |
| Namespace | Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-envelope |
| Clarification | Changed element and attribute wildcards in Envelope complex type to namespace="##other" |
| Clarification | Changed element and attribute wildcards in Header complex type to namespace="##other" |
| Clarification | Added explicit namespace="##any" to element and attribute wildcards in Body complex type |
| Clarification | Added explicit namespace="##any" to element and attribute wildcards in detail complex type |
| Clarification | Added an element wildcard with namespace="##other" to the Fault complex type |
| Name | Changed item type of encodingStyle from uri-reference to anyURI |
| Name | Changed type of actor attribute from uri-reference to anyURI |
| Name | Changed type of faultactor attribute from uri-reference to anyURI |
| Semantic | Added processContents="lax" to all element and attribute wildcards |
| Semantic | Changed type of the mustUnderstand attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed. |
| Style | Where possible comments have been changed into annotations |
| Syntax | Changed all occurences of maxOccurs="*" to maxOccurs="unbounded" |
| Syntax | Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type |
| Syntax | Added <xs:sequence> to all named model group definitions |
In addition several changes occured in the names of datatypes in the XML Schema specification and some datatypes were removed. The following table lists those changes.
| Datatype | Class | Description |
|---|---|---|
| timeDuration | Renamed | New name is duration |
| timeInstant | Renamed | New name is dateTime |
| recurringDuration | Removed | The recurringDuration datatype no longer exists. |
| recurringInstant | Removed | The recurringInstant datatype no longer exists. |
| binary | Removed | The binary datatype has been replaced by the hexBinary and base64Binary datatypes. |
| month | Renamed | New name is gYearMonth |
| timePeriod | Removed | The timePeriod datatype no longer exists |
| year | Renamed | New name is gYear |
| century | Removed | The century datatype no longer exists |
| recurringDate | Renamed | New name is gMonthDay |
| recurringDay | Renamed | New name is gDay |