SOAP Version 1.2 Part 1: Messaging Framework

1.1 Design Goals

Two major design goals for SOAP are simplicity and extensibility. SOAP attempts to meet these goals by omitting features often found in messaging systems and distributed object systems such as:

• distributed garbage collection;

• boxcarring or batching of messages;

• objects-by-reference (which requires distributed garbage collection);

• activation (which requires objects-by-reference).

Note that it is possible to implement such features using SOAP but they are out of scope for this specification.

1.2 Notational Conventions

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

The namespace prefixes "env" and "enc" 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.

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

Note that the choice of any namespace prefix is arbitrary and not semantically significant.

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

1.3 Example of SOAP Message

The following example shows a simple notification message expressed in SOAP. The message contains a header block alertcontrol and the body alert both of which are application defined and not defined by SOAP. 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.

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

1.4 SOAP Terminology

1.4.2 Data Encapsulation Concepts

SOAP message

A SOAP message is the basic unit of communication between peer SOAP nodes.

SOAP envelope

The outermost syntactic construct or structure of a SOAP message defined by SOAP within which all other syntactic elements of the message are enclosed.

SOAP header block

A syntactic construct or structure 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 (4.2 SOAP Header) element information item. 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.

SOAP header

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

SOAP body

A collection of zero or more element information items targeted at the ultimate SOAP receiver in the SOAP message path.

SOAP fault

A special SOAP element information item which contains fault information generated by a SOAP node.

The following diagram illustrates how a SOAP message is composed.

2.1 SOAP Nodes

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. SOAP does not provide a routing mechanism, however SOAP does recognise that a SOAP sender originates a SOAP message which is sent to an ultimate SOAP receiver, via zero or more SOAP intermediaries.

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

2.2 SOAP Actors and SOAP Nodes

In processing a SOAP message, a SOAP node is said to act in the role of one or more SOAP actors, each of which is identified by a URI known as the SOAP actor name. Each SOAP node MUST act in the role of the special SOAP actor named "http://www.w3.org/2001/12/soap-envelope/actor/next", and can additionally assume the roles of zero or more other SOAP actors. A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor. The roles assumed 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.

SOAP nodes MUST NOT act in the role of the special SOAP actor named "http://www.w3.org/2001/12/soap-envelope/actor/none". Header blocks targeted to this special actor 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.

While the purpose of a SOAP actor name is to identify a SOAP node, there are no routing or message exchange semantics associated with the SOAP actor name. For example, SOAP Actors MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP actor 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/actor/next", "http://www.w3.org/2001/12/soap-envelope/actor/none" and the anonymous actor 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 transport binding (e.g. the URI to which the message was physically delivered), configuration information made by users during system installation, etc.

2.3 Targeting SOAP Header Blocks

SOAP header blocks carry optional actor attribute information items (see 4.2.2 SOAP actor Attribute) that are used to target them to the appropriate SOAP node(s). SOAP header blocks with no such attribute information item are implicitly targeted at the anonymous SOAP actor, implying that they are to be processed by the ultimate SOAP receiver. This specification refers to the (implicit or explicit) value of the SOAP actor attribute as the SOAP actor for the corresponding SOAP header block.

A SOAP header block is said to be targeted to a SOAP node if the SOAP actor (if present) on the block matches (see [7]) a role played by the SOAP node, or in the case of a SOAP header block with no actor attribute information item, if the SOAP node is acting in the role of the ultimate SOAP receiver.

A SOAP Node that acts in the role of the anonymous actor with respect to a particular SOAP message becomes the ultimate recipient of that SOAP message. Such a SOAP node is responsible for processing all parts of the message intended for the anonymous actor, including the body, according to the rules described in this section. The SOAP message path for that message ends at the ultimate recipient. However, the ultimate recipient may delegate all or part of its responsibility to other entities. The ultimate recipient may happen to use distinct SOAP message exchanges to interact with such entities. Nevertheless, responsibility for the processing of parts of a SOAP message targetted at the anonymous actor rests with the ultimate recipient of that message

2.4 Understanding SOAP Headers

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 mustUnderstand attribute information items (see 4.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true" or "1", the SOAP block is said to be mandatory.

For every mandatory SOAP header block targeted to a node, that node MUST either process the block according to the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block; or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 4.4 SOAP Fault).

Mandatory blocks MUST be presumed to somehow modify the semantics of other headers or body elements. Tagging SOAP blocks as mandatory thus assures that such changes in semantics will not be silently (and, presumably, erroneously) ignored.

The mustUnderstand attribute information item is not intended as a mechanism for detecting errors in routing, misidentification of nodes, failure of a node to serve in its intended role(s), etc., any of which may result in a failure to even attempt processing, and the subsequent removal, 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 that node without having been processed.

2.5 Structure and Interpretation of SOAP Bodies

A SOAP body consists of zero or more namespace qualified element information items, which are the immediate children of the Body element information item. The ultimate SOAP receiver MUST correctly process such body elements. However, Part 1 of this specification (this document) mandates no particular structure or interpretation of such elements, and provides no standard means for specifying the processing to be done.

When multiple body elements are present, such elements MAY represent a single unit of work to be performed, MAY represent multiple separate processing steps, possibly but not necessarily in order, MAY represent data or metadata, MAY convey a mixture of work units and data, etc. The ultimate SOAP recipient MAY use the local name(s) and namespace name(s), on any or all body elements, to determine the processing to be performed. Indeed, the SOAP RPC convention (see [1]Using SOAP for RPC) uses just such a method. Conversely, other information in the body and/or headers MAY be used to make such a determination.

2.6 Processing SOAP Messages

This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing must be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification 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.

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

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

3. 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 4.4.6 MustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the existence or contents of the body MUST NOT be generated in this step.

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

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

If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults (see 4.4 SOAP Fault) MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes) and MUST conform to the specification for the corresponding SOAP header block. Faults relating to the body MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes).

SOAP nodes can make reference to any information in the SOAP envelope when processing a SOAP 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.

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

4.1 Envelope Encoding and Versioning

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

4.2 SOAP Header

SOAP provides a flexible mechanism for extending a SOAP message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as SOAP header blocks are authentication, transaction management, payment, etc.

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 item children.

• Zero or more namespace qualified element information item children.

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

Each SOAP header block element information item:

• MUST be namespace qualified;

• MAY have an encodingStyle attribute information item

• MAY have an actor attribute information item

• MAY have a mustUnderstand attribute information item

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

4.3 SOAP Body

The SOAP Body element information item provides a simple mechanism for exchanging mandatory information intended for the ultimate SOAP receiver of a SOAP message. Example uses of SOAP Body include marshalling RPC calls and error reporting.

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 element information item children.

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

• MUST be namespace qualified.

• MAY have an encodingStyle attribute information item

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

4.4 SOAP Fault

The SOAP Fault element information item is used to carry error and/or status information within a SOAP message. If present, the 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:

  1. A mandatory faultcode element information item, see 4.4.1 SOAP faultcode Element;

  2. A mandatory faultstring element information item, see 4.4.2 SOAP faultstring Element;

  3. An optional faultactor element information item, see 4.4.3 SOAP faultactor Element;

  4. An optional detail element information item, see 4.4.4 SOAP detail Element.

<?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>

<?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>env:MustUnderstand</faultcode>
      <faultstring>One or more mandatory headers not understood</faultstring>
    </env:Fault>
  </env:Body>
</env:Envelope>

5.1 Introduction

SOAP provides a simple messaging framework with a core set of functionality which is primarily concerned with providing extensibility. The SOAP processing model (2 SOAP Message Exchange Model) describes the behavior of a single SOAP node with respect to the processing of an individual message.

The sending and receiving of SOAP messages by a SOAP node is mediated by a binding to an underlying protocol. A SOAP underlying protocol binding operates between adjacent SOAP nodes along a SOAP message path. 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. There is no requirement that the same underlying protocol is used for all hops along a SOAP message path.

As part of communicating between SOAP nodes it may be necessary to introduce a variety of abstract features generally associated with the exchange of messages in a protocol environment. Although SOAP poses no constraints on the potential scope of such features, typical examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require message exchange patterns (MEPs) beyond the one-way MEP that SOAP provides. MEPs are considered to be a type of feature; unless otherwise stated, references to the term "feature" apply also to MEPs.

In some cases, underlying protocols are equipped, either directly or through extension, with mechanisms for providing certain features, in whole or in part. Features are the modular components from which the contract between SOAP nodes and the bindings they support are formed. The SOAP binding framework provides a framework for describing these features and how they relate to SOAP nodes. 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.

The combination of the SOAP extensibility model and the SOAP binding framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions. It is up to the communicating nodes to decide how best to express particular features; often when a binding-level implementation for a particular feature is available, utilizing it when appropriate will provide for optimized processing.

5.2 Goals of the Binding Framework

As described above, SOAP messages can be transported using a variety of underlying protocols. 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. The goals of the binding framework are:

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

2. To facilitate homogenous description of bindings that support common features.

3. To facilitate homogenous description of bindings that support common 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 operating using an underlying protocol that directly facilitates the feature (the protocol is reliable), and the other providing the logic (logging and retransmission) in the binding. The feature can be made available to applications in a consistent manner, regardless of which binding is used.

5.3 Binding Framework

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

Section 2 SOAP Message Exchange 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 any additional processing that may be 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 Message Exchange 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:

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

2. The processing required at each node in order to fulfill the obligations of the feature.

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

Every binding specification MUST support the transmission and processing of one-way messages as described in this specification. 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, the transaction ID, etc. The HTTP binding in SOAP Part 2[1] illustrates one such convention.

As described in 4 SOAP Envelope, 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.

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.

5.4 Binding to Application-Specific Protocols

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

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

As a result, binding definitions for underlying protocols with well-known default ports or application profiles SHOULD document potential (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.

5.5 Security Considerations

7.1 Normative References

1

W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 10 2001 (See http://www.w3.org/TR/2001/WD-soap12-part2-20011217/.)

2

IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt.)

3

IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

4

W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)

5

W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)

6

IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)

7

W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

8

W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)

9

W3C Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xlink-20010627/.)

10

W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)

11

W3C Recommendation "XML Base", Johnathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/.)

12

IETF "RFC 2732: Format for Literal IPv6 Addresses in URL's", R. Hinden, B. Carpenter, L. Masinter, December 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)

7.2 Informative References

13

XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)

14

XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)

15

XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)

15

W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/SOAP/.)

16

IETF "RFC 1900: Renumbering Needs Work", B. Carpenter, Y. Rekhter, February 1996. (See http://www.ietf.org/rfc/rfc1900.txt.)