<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.2+Addr//EN" "xmlspec.dtd">
<!--
/*
 * Copyright © 2006 World Wide Web Consortium,
 *
 * (Massachusetts Institute of Technology, European Research Consortium for
 * Informatics and Mathematics, Keio University). All Rights Reserved. This
 * work is distributed under the W3C® Document License [1] in the hope that
 * it will be useful, but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
 */
    -->
<!-- $Id: ws-addr-soap.xml,v 1.4 2006/05/05 16:06:14 hugo Exp $ -->
<?xml-stylesheet type='text/xsl' href='xmlspec-addressing.xsl'?><spec xmlns:xlink="http://www.w3.org/1999/xlink" w3c-doctype="rec" role="public" shortname="ws-addr-soap">
  <header>
    <title>Web Services Addressing 1.0 - SOAP Binding</title>
    <w3c-designation>http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509</w3c-designation>
    <w3c-doctype>W3C Recommendation</w3c-doctype>
    <pubdate>
      <day>9</day>
      <month>May</month>
      <year>2006</year>
    </pubdate>
    <publoc>
      <loc href="http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509</loc>
    </publoc> <altlocs>
	<loc role="pdf" href="ws-addr-soap.pdf" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">PDF</loc>
	<loc role="postscript" href="ws-addr-soap.ps" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">PostScript</loc>
	<loc role="xml" href="ws-addr-soap.xml" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">XML</loc>
	<loc role="plain" href="ws-addr-soap.txt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">plain text</loc>
    </altlocs> <prevlocs>
      <loc href="http://www.w3.org/TR/2006/PR-ws-addr-soap-20060321" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://www.w3.org/TR/2006/PR-ws-addr-soap-20060321</loc>
    </prevlocs>
    <latestloc>
      <loc href="http://www.w3.org/TR/ws-addr-soap" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://www.w3.org/TR/ws-addr-soap</loc>
    </latestloc>
    <authlist>
      <author>
        <name>Martin Gudgin</name>
        <affiliation>Microsoft Corp</affiliation>
      </author>
      <author>
        <name>Marc Hadley</name>
        <affiliation>Sun Microsystems, Inc</affiliation>
      </author>
      <author>
        <name>Tony Rogers</name>
        <affiliation>Computer Associates International, Inc</affiliation>
      </author>
    </authlist>
    <errata>http://www.w3.org/2006/05/ws-addr-errata.html</errata>
    <abstract>
      <p>Web Services Addressing provides transport-neutral mechanisms to address Web services and
        messages. Web Services Addressing 1.0 - SOAP Binding (this document) defines the binding of the abstract
        properties defined in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
    </abstract> 
<status id="Status">

  <p><emph>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <loc href="http://www.w3.org/TR/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">W3C technical reports index</loc> at http://www.w3.org/TR/.</emph></p>

 <p>This is the <loc href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Recommendation</loc> of the Web Services Addressing 1.0 - SOAP Binding specification. It has been
 produced by the <loc href="http://www.w3.org/2002/ws/addr/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Web
 Services Addressing Working Group</loc> (WG), which is part of the
 <loc href="http://www.w3.org/2002/ws/Activity" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">W3C Web Services
 Activity</loc>.</p>

  <p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>

  <p>The Working Group made the following editorial changes to the
  Proposed Recommendation in response to comments: normative and
  informative references are now more clearly distinguished, and some
  typographical errors were fixed. An <loc href="http://www.w3.org/2002/ws/addr/5/08/impl-report/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">implementation
  report</loc> showing that the Candidate Recommendation exit criteria
  have been met and exceeded is available, along with a <loc href="http://www.w3.org/2002/ws/addr/testsuite/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">test suite</loc>. A
  <loc href="diff.html" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">diff-marked version against the previous
  version of this document</loc> is available.<!-- For a detailed list of
  changes since the last publication of this document, please refer to
  appendix <specref ref="changelog"/>.--></p>


 <p>Please report errors in this document to the public <loc href="mailto:public-ws-addressing-comments@w3.org" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public-ws-addressing-comments@w3.org</loc>
 mailing list (<loc href="http://lists.w3.org/Archives/Public/public-ws-addressing-comments/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public
 archive</loc>).</p>

  <p> This document was produced by a group operating under the <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">5
  February 2004 W3C Patent Policy</loc>. W3C maintains a <loc href="http://www.w3.org/2004/01/pp-impl/36696/status#specs" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">public
  list of any patent disclosures</loc> made in connection with the
  deliverables of the group; that page also includes instructions for
  disclosing a patent. An individual who has actual knowledge of a
  patent which the individual believes contains <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">Essential
  Claim(s)</loc> must disclose the information in accordance with <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">section
  6 of the W3C Patent Policy</loc>. </p>

</status>
 <langusage>
      <language id="en-US">English</language>
    </langusage>
    <revisiondesc>
      <p>Last Modified: $Date: 2006/05/05 16:06:14 $</p>
    </revisiondesc>
  </header>
  <body>
    <div1 id="intro">
      <head> Introduction</head>
      <p>Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>] defines a set of abstract properties and
        an XML Infoset [<bibref ref="XMLInfoSet"/>] representation thereof to reference Web service
        endpoints and to facilitate end-to-end addressing of endpoints in messages.
        Web Services Addressing 1.0 - SOAP Binding (this document) defines the binding of the abstract properties defined
        in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
      <p>The following example illustrates the use of these mechanisms in a SOAP 1.2 message being
        sent from http://example.com/business/client1 to http://example.com/fabrikam/Purchasing:</p>
      <example>
        <head>Use of message addressing properties in a SOAP 1.2 message.</head>
        <eg xml:space="preserve">
(01) &lt;S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"      
                xmlns:wsa="http://www.w3.org/2005/08/addressing"&gt;
(02)   &lt;S:Header&gt;
(03)    &lt;wsa:MessageID&gt;http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA&lt;/wsa:MessageID&gt;
(04)    &lt;wsa:ReplyTo&gt;
(05)      &lt;wsa:Address&gt;http://example.com/business/client1&lt;/wsa:Address&gt;
(06)    &lt;/wsa:ReplyTo&gt;
(07)    &lt;wsa:To&gt;http://example.com/fabrikam/Purchasing&lt;/wsa:To&gt;
(08)    &lt;wsa:Action&gt;http://example.com/fabrikam/SubmitPO&lt;/wsa:Action&gt;
(09)   &lt;/S:Header&gt;
(10)   &lt;S:Body&gt;
(11)     ...
(12)   &lt;/S:Body&gt;
(13) &lt;/S:Envelope&gt;
</eg>
        <p>Lines (02) to (09) represent the header of the SOAP message where the mechanisms defined
          in the specification are used. The body is represented by lines (10) to (12).</p>
        <p>Lines (03) to (08) contain the message addressing properties serialized as SOAP header
          blocks. Specifically, line (03) specifies the identifier for this message and lines (04)
          to (06) specify the endpoint to which replies to this message should be sent as an
          Endpoint Reference. Line (07) specifies the address URI of the ultimate receiver of this
          message. Line (08) specifies an action URI identifying expected semantics.</p>
      </example>
      <div2 id="notation">
        <head> Notational Conventions</head>
        <p>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 [<bibref ref="RFC2119"/>].</p>
        <p>When describing abstract data models, this specification uses the notational convention
          used by XML Infoset [<bibref ref="XMLInfoSet"/>]. Specifically, abstract property names
          always appear in square brackets (e.g., [some property]).</p>
        <p>When describing concrete XML schemas [<bibref ref="XMLSchemaP1"/>, <bibref ref="XMLSchemaP2"/>], this specification uses the notational convention of WS-Security
            [<bibref ref="WS-Security"/>]. Specifically, each member of an element's [children] or
          [attributes] property is described using an XPath-like notation (e.g.,
          /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates the presence of an element
          wildcard (&lt;xs:any/&gt;). The use of @{any} indicates the presence of an
          attribute wildcard (&lt;xs:anyAttribute/&gt;).</p>
      </div2>
      <div2 id="namespaces">
        <head> Namespaces</head>
        <p> This specification uses a number of namespace prefixes throughout; they are listed in
            <specref ref="nsrefs"/>. Note that the choice of any namespace prefix is arbitrary and
          not semantically significant (see [<bibref ref="XMLNS"/>]).</p>
        <table id="nsrefs" border="1" summary="Namespace prefixes usage in this specification">
          <caption>Prefixes and Namespaces used in this specification</caption>
          <tbody>
            <tr>
              <th align="left" rowspan="1" colspan="1">Prefix</th>
              <th align="left" rowspan="1" colspan="1">Namespace</th>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">S</td>
              <td rowspan="1" colspan="1">http://www.w3.org/2003/05/soap-envelope</td>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">S11</td>
              <td rowspan="1" colspan="1">http://schemas.xmlsoap.org/soap/envelope</td>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">wsa</td>
              <td rowspan="1" colspan="1"> http://www.w3.org/2005/08/addressing </td>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">wsaw</td>
              <td rowspan="1" colspan="1"> http://www.w3.org/2006/02/addressing/wsdl </td>
            </tr>
            <tr>
              <td rowspan="1" colspan="1">xs</td>
              <td rowspan="1" colspan="1">http://www.w3.org/2001/XMLSchema</td>
            </tr>
          </tbody>
        </table>
        <p>WS-Addressing is defined in terms of the XML Information Set [<bibref ref="XMLInfoSet"/>]. WS-Addressing is conformant to the SOAP 1.2 [<bibref ref="SOAP12-PART1"/>] processing
          model and is also compatible with SOAP 1.1[<bibref ref="SOAP11"/>] for backwards
          compatibility. WS-Addressing may be used with WSDL [<bibref ref="WSDL20"/>] described
          services as described in Web Services Addressing 1.0 - WSDL Binding[<bibref ref="WSADDR-WSDL"/>]. The examples
          in this specification use an XML 1.0 [<bibref ref="XML10"/>] representation but this is
          not a requirement.</p>
        <p>All information items defined by this specification are identified by the XML namespace
          URI [<bibref ref="XMLNS"/>] <xspecref href="http://www.w3.org/2005/08/addressing" xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">http://www.w3.org/2005/08/addressing</xspecref>. A
          normative XML Schema [<bibref ref="XMLSchemaP1"/>, <bibref ref="XMLSchemaP2"/>] document
          can be obtained by dereferencing the XML namespace URI.</p>
      </div2>
    </div1>
    <div1 id="s12feature">
      <head>SOAP 1.2 Addressing 1.0 Feature</head>
      <p>This section defines the SOAP 1.2 Addressing 1.0 Feature.</p>
      <div2 id="s12featurename">
        <head>Feature Name</head>
        <p>The SOAP 1.2 Addressing 1.0 Feature is named using the following URI:</p>
        <ulist>
          <item>
            <p>http://www.w3.org/2005/08/addressing/feature</p>
          </item>
        </ulist>
      </div2>
      <div2 id="s12featuredesc">
        <head>Description</head>
        <p>The SOAP 1.2 Addressing 1.0 Feature provides a SOAP-specific expression of the abstract
          message addressing properties defined by Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>].</p>
        <p>This feature may be used with any SOAP MEP. A binding that supports this feature MUST
          provide a means to transmit the properties listed below with a message and to reconstitute
          their values on receipt of a message.</p>
      </div2>
      <div2 id="s12featureprops">
        <head>Properties</head>
        <p>The SOAP 1.2 Addressing 1.0 Feature defines the following properties:</p>
        <glist>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/Destination</label>
            <def>
              <p>Corresponds to the abstract [destination] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/SourceEndpoint</label>
            <def>
              <p>Corresponds to the abstract [source endpoint] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/ReplyEndpoint</label>
            <def>
              <p>Corresponds to the abstract [reply endpoint] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/FaultEndpoint</label>
            <def>
              <p>Corresponds to the abstract [fault endpoint] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/Action</label>
            <def>
              <p>Corresponds to the abstract [action] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/MessageID</label>
            <def>
              <p>Corresponds to the abstract [message id] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/Relationship</label>
            <def>
              <p>Corresponds to the abstract [relationship] property.</p>
            </def>
          </gitem>
          <gitem>
            <label>http://www.w3.org/2005/08/addressing/feature/ReferenceParameters</label>
            <def>
              <p>Corresponds to the abstract [reference parameters] property.</p>
            </def>
          </gitem>
        </glist>
      </div2>
      <div2 id="s12featureinteractions">
        <head>Interactions with Other SOAP Features</head>
        <p>If the http://www.w3.org/2003/05/soap/features/action/Action property of the SOAP Action
            feature[<bibref ref="SOAP12-PART2"/>] has a value, then the value of the
          http://www.w3.org/2005/08/addressing/feature/Action property of the SOAP 1.2 Addressing 1.0 feature MUST be
          identical to it. Failure to have an identical value results in an Invalid Addressing
          Header fault (see <specref ref="invalidmapfault"/>).</p>
      </div2>
    </div1>
    <div1 id="s12module">
      <head>SOAP 1.2 Addressing 1.0 Module</head>
      <p>The SOAP 1.2 Addressing 1.0 Module defines a set of SOAP header blocks to support the SOAP
        1.2 Addressing 1.0 Feature described in <specref ref="s12feature"/>.</p>
      <div2 id="s12modulename">
        <head>Module Name</head>
        <p>The SOAP 1.2 Addressing 1.0 Module is identified using the following URI:</p>
        <ulist>
          <item>
            <p>http://www.w3.org/2005/08/addressing/module</p>
          </item>
        </ulist>
      </div2>
      <div2 id="s12moduledesc">
        <head>Description</head>
        <p>The SOAP 1.2 Addressing 1.0 Feature (see <specref ref="s12feature"/>) defines a set of
          SOAP properties and their correspondence to the abstract message addressing properties
          defined by Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>]. The SOAP 1.2 Addressing 1.0
          Module defines SOAP headers corresponding to the XML Infoset representation of the
          abstract message addressing properties defined in Web Services Addressing 1.0 - Core.</p>
        <div3>
          <head>Sending Messages</head>
          <p>When sending a message each property is represented using the appropriate element
            information item as a SOAP header block. By default, the resulting header blocks are
            targeted at the ultimate recipient in the SOAP message path (note that extensions to
            WS-Addressing could be written to specify different targetting). <specref ref="bindrefp"/>
            describes additional processing required when binding message addressing properties to
            SOAP header blocks.</p>
        </div3>
        <div3>
          <head>Receiving Messages</head>
          <p>When receiving a message, the abstract properties are populated from their corresponding
            element information items in the message. A message MUST NOT contain more than one wsa:To,
            wsa:ReplyTo, wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted at a recipient;
            headers with an incorrect cardinality MUST NOT be used to populate the corresponding
            abstract properties. A
            recipient MUST generate a wsa:InvalidAddressingHeader (see <specref ref="invalidmapfault"/>) fault if such a message is received.</p>
          <note>
            <p>The SOAP processing model dictates that message addressing properties targeted at an
              intermediary do not normally get relayed as message addressing properties when the
              message is forwarded along the message path. The specification for a SOAP header used as
              a reference parameter or use of the soap:relay attribute can override this default
              behavior.</p>
          </note>
        </div3>
        

      </div2>
      <div2 id="additionalinfoset">
        <head>Additional Infoset Items</head>
        <p>The SOAP 1.2 Addressing 1.0 Module defines the following additional XML Infoset items:</p>
        <glist>
          <gitem>
            <label>/[reference parameters]/@wsa:IsReferenceParameter</label>
            <def>
              <p>This REQUIRED attribute (of type xs:boolean) signifies whether the message
                addressing header is a reference parameter, see section <specref ref="bindrefp"/>
                for more details on its use.</p>
            </def>
          </gitem>
        </glist>
      </div2>
      <div2 id="bindrefp">
        <head>Binding Message Addressing Properties</head>
        <p>When a message is to be addressed to an endpoint, the XML Infoset representation of each
          message addressing property that has been assigned a value is inserted into the message as
          a SOAP header block subject to the following additional constraints:</p>
        <ulist>
          <item>
            <p>The value, if any, of the [reference parameters] property is added to the SOAP
              message header: the element information item of each of the [reference parameters]
              (including all of its [children], [attributes] and [in-scope namespaces]) is added as
              a SOAP header block in the new message.</p>
            <note>
              <p>The insertion of SOAP headers into a message implies particular semantics. Since
                the reference parameter mechanism does not restrict the content of the generated
                headers, EPR suppliers should exercise appropriate caution to ensure their reference
                parameters do not cause unintended or erroneous semantics in the resultant SOAP
                message. For example, using a reference parameter to send a WS-Security[<bibref ref="WS-Security"/>] header would be ill-advised (since other parts of the SOAP
                infrastructure will often control this header, and there must be at most one of them
                per message).</p>
            </note>
          </item>
          <item>
            <p>Each header block added as a result of the above rule is annotated with a
              wsa:IsReferenceParameter attribute (see <specref ref="additionalinfoset"/>) whose
              value is a valid xs:boolean representation of <attval>true</attval>. Any existing
              wsa:IsReferenceParameter attribute on the header block is replaced.</p>
            <note>
              <p>Integrity validation of [reference parameters] needs to take into account the
                addition of wsa:IsReferenceParameter attributes and the corresponding introduction
                of the WS-Addressing namespace to the [in-scope namespaces]</p>
            </note>
          </item>
          <item>
            <p>The value of each message addressing property that is of type IRI MUST be serialized
              as an absolute IRI in the corresponding SOAP header block. No additional %-escaping is
              performed.</p>
          </item>
          <item>
            <p>Each optional element or attribute that has a value equal to the defined default
              value for that element or attribute MAY be omitted.</p>
          </item>
        </ulist>
        <p>The following example shows how the SOAP 1.2 Addressing 1.0 Module is used to construct a
          message addressed to the endpoint:</p>
        <example>
          <head>Example endpoint reference.</head>
          <eg xml:space="preserve">
&lt;wsa:EndpointReference
     xmlns:wsa="http://www.w3.org/2005/08/addressing"
     xmlns:wsaw="http://www.w3.org/2006/02/addressing/wsdl"
     xmlns:fabrikam="http://example.com/fabrikam"
     xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance"
     wsdli:wsdlLocation="http://example.com/fabrikam
       http://example.com/fabrikam/fabrikam.wsdl"&gt;
   &lt;wsa:Address&gt;http://example.com/fabrikam/acct&lt;/wsa:Address&gt;
   &lt;wsa:Metadata&gt;
       &lt;wsaw:InterfaceName&gt;fabrikam:Inventory&lt;/wsaw:InterfaceName&gt;
   &lt;/wsa:Metadata&gt;
   &lt;wsa:ReferenceParameters&gt;
       &lt;fabrikam:CustomerKey&gt;123456789&lt;/fabrikam:CustomerKey&gt;
       &lt;fabrikam:ShoppingCart&gt;ABCDEFG&lt;/fabrikam:ShoppingCart&gt;
   &lt;/wsa:ReferenceParameters&gt;
&lt;/wsa:EndpointReference&gt;</eg>
        </example>
        <p>The address value is copied in the "To" header block and the "CustomerKey" and
          "ShoppingCart" elements are copied literally as a header blocks in a SOAP message
          addressed to this endpoint. The resulting SOAP message would look as follows:</p>
        <example>
          <head>Example endpoint reference mapped to SOAP message header blocks.</head>
          <eg xml:space="preserve">
&lt;S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
         xmlns:wsa="http://www.w3.org/2005/08/addressing"
         xmlns:fabrikam="http://example.com/fabrikam"&gt;
   &lt;S:Header&gt;
     ...
    &lt;wsa:To&gt;http://example.com/fabrikam/acct&lt;/wsa:To&gt;
    &lt;wsa:Action&gt;...&lt;/wsa:Action&gt;
    &lt;fabrikam:CustomerKey wsa:IsReferenceParameter='true'&gt;123456789&lt;/fabrikam:CustomerKey&gt;
    &lt;fabrikam:ShoppingCart wsa:IsReferenceParameter='true'&gt;ABCDEFG&lt;/fabrikam:ShoppingCart&gt;
     ...
   &lt;/S:Header&gt;
   &lt;S:Body&gt;
     ...
   &lt;/S:Body&gt;
&lt;/S:Envelope&gt;</eg>
        </example>
      </div2>
      <div2 id="soaphdrvtransport">
        <head>Relationship between SOAP Headers and transport-level properties</head>
        <p>Some underlying protocols may support native properties similar to the Message Addressing
          Properties. For example, the reply-to: email header is similar to the [reply endpoint]
          Message Addressing Property. Authors and implementors of bindings should not assume any
          particular correspondence between native properties and Message Addressing Properties. For
          example, if an email message represents only one hop in a multi-hop path, then the
          reply-to: header is likely to differ from the [reply endpoint] address.</p>
      </div2>
    </div1>
    <div1 id="s11ext">
      <head>SOAP 1.1 Addressing 1.0 Extension</head>
      <p>The SOAP 1.1 Addressing 1.0 Extension defines a set of SOAP header blocks to support the
        SOAP 1.2 Addressing 1.0 Feature described in <specref ref="s12feature"/>. This SOAP 1.1
        extension is provided for backwards compatibility only.</p>
      <div2 id="s11extname">
        <head>Extension Name</head>
        <p>The SOAP 1.1 Addressing 1.0 Extension is identified using the following URI:</p>
        <ulist>
          <item>
            <p>http://www.w3.org/2005/08/addressing/module</p>
          </item>
        </ulist>
      </div2>
      <div2 id="s11extdesc">
        <head>Description</head>
        <p>The SOAP 1.2 Addressing 1.0 Feature (see <specref ref="s12feature"/>) defines a set of
          SOAP properties and their correspondence to the abstract message addressing properties
          defined by Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>]. The SOAP 1.1 Addressing 1.0
          Extension uses the XML Infoset representation of the abstract message addressing
          properties defined in Web Services Addressing 1.0 - Core and binds each element information item to a
          SOAP header block. The SOAP 1.1 Addressing 1.0 Extension operates as described in <specref ref="s12module"/> with the following exceptions:</p>
        <glist>
          <gitem>
            <label>SOAP Action</label>
            <def>
              <p>Use of the SOAPAction HTTP request header field is required when using the SOAP 1.1
                HTTP binding. The field-value of the SOAPAction HTTP request header MUST either be
                the value of the [action] property enclosed in quotation marks, or the empty value
                "". The latter case supports the ability to obscure the [action] property through
                SOAP-level security mechanisms, without requiring otherwise unnecessary
                transport-level security. Any other value for SOAPAction results in an Invalid
                Message Addressing Property fault (see <specref ref="invalidmapfault"/>).</p>
            </def>
          </gitem>
        </glist>
      </div2>
    </div1>
    <div1 id="addressesinsoap">
      <head>Addresses in SOAP</head>
      <p> In the following text, the term 'response endpoint' refers to the [reply endpoint]
        and [fault endpoint] message addressing properties collectively.</p>
      <div2 id="anonaddress">
        <head>Use of Anonymous Address in SOAP Response Endpoints</head>
        <p>A value of "http://www.w3.org/2005/08/addressing/anonymous" for 
          the [destination] property implies no additional semantics beyond those resulting from the
          rules defined below and as described
          in Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>]. In particular, note that
          Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>], section 3.4 requires such a value in
          messages sent to a response endpoint whose [address] is "http://www.w3.org/2005/08/addressing/anonymous".</p>
        <div3>
          <head>SOAP 1.1/HTTP</head>
          <p>When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the response
            endpoint then there is no change to the SOAP 1.1/ HTTP binding. </p>
        </div3>
        <div3>
          <head>SOAP 1.2</head>
          <p>When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the response
            endpoint and the message is the http://www.w3.org/2003/05/soap/mep/InboundMessage
            property of a SOAP request-response MEP [<bibref ref="SOAP12-PART2"/>], then any response MUST be the
            http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same instance of the SOAP
            request-response MEP [<bibref ref="SOAP12-PART2"/>].</p>
        </div3>
      </div2>
      <div2 id="nonanonaddress">
        <head>Use of Non-Anonymous Addresses in SOAP Response Endpoints</head>
        <div3>
          <head>SOAP 1.1/HTTP</head>
          <p>When "http://www.w3.org/2005/08/addressing/anonymous" is not specified for the response
            endpoint, then the message SHOULD be part of a binding that supports not returning a
            SOAP envelope in the HTTP response (e.g. see [<bibref ref="SOAP11-ROR"/>]). Any
            response message SHOULD be sent using a separate connection and using the address value
            specified by response endpoint. Note that other specifications MAY define special URIs
            that have other behaviors (similar to the anonymous URI).</p>
        </div3>
        <div3>
          <head>SOAP 1.2</head>
          <p>When "http://www.w3.org/2005/08/addressing/anonymous" is not specified for the response
            endpoint, then any response SHOULD NOT be the
            http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same instance of the SOAP
            request-response MEP [<bibref ref="SOAP12-PART2"/>]. For instance, a SOAP 1.2 HTTP
            binding that supports a one-way MEP could put the reply message in a separate one-way
            MEP and a separate HTTP request. As in SOAP 1.1/HTTP, note that other specifications MAY
            define special URIs that have other behaviors (similar to the anonymous URI).</p>
        </div3>
      </div2>
    </div1>
    <div1 id="faults">
      <head>Faults</head>
      <p>The faults defined in this section are generated if the condition stated in the preamble in
        each subsection is met.</p>
      <p>Endpoints compliant with this specification MUST include the required message addressing
        properties serialized as SOAP headers in generated fault messages. Fault messages are
        correlated as replies using the [relationship] property as defined in
          Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>]. Note that omission of the [message id]
        property in an input message may impact the ability of a fault message receiver to correlate
        the fault message to the message that caused the fault message to be generated. Omission of
        the [fault endpoint] or [reply endpoint] properties in input messages may impact the
        delivery of a generated fault message</p>
      <p>The [action] property below designates WS-Addressing fault messages:</p>
      <eg xml:space="preserve">
http://www.w3.org/2005/08/addressing/fault
      </eg>
      <p>This action SHOULD NOT be used as an action value in messages other 
        than those carrying WS-Addressing faults.</p>
      <p>SOAP modules, extensions and applications SHOULD define custom [action] values for the faults they describe
        but MAY designate use of the following [action] value instead:</p>
      <eg xml:space="preserve">
http://www.w3.org/2005/08/addressing/soap/fault
</eg>
      <p>The above [action] value SHOULD be used for SOAP defined faults including version mismatch,
        must understand, and data encoding unknown.</p>
      <p>Each of the predefined faults listed below is defined by specifying values for the
        following abstract properties:</p>
      <p> [Code] The fault code, use of the specified fault code is REQUIRED.</p>
      <p> [Subcode] The fault subcode, use of the specified fault subcode is REQUIRED.</p>
      <p> [Subsubcode] A more specific fault subcode that may be used to further qualify the value
        of the [Subcode] property, use of a specified fault subcode is OPTIONAL.</p>
      <p> [Reason] The English language reason element, use of the specified fault code is
        RECOMMENDED but alternate text MAY be used.</p>
      <p> [Details] The detail elements, use of the specified detail elements is REQUIRED. If
        absent, no detail elements are defined for the fault.</p>
      <div2>
        <head>SOAP 1.2 Fault Binding</head>
        <p>The fault properties bind to a SOAP 1.2 fault as follows:</p>
        <glist>
          <gitem>
            <label>[Code]</label>
            <def>
              <p>The value of the [Code] property is bound as the value of the SOAP faults
                S:Fault/S:Code/S:Value element information item.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Subcode]</label>
            <def>
              <p>The value of the [Subcode] property is bound as the value of the SOAP faults
                S:Fault/S:Code/S:Subcode/S:Value element information item.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Subsubcode]</label>
            <def>
              <p>The value of the [Subsubcode] property is bound as the value of the SOAP faults
                S:Fault/S:Code/S:Subcode/S:/Subcode/S:Value element information item.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Reason]</label>
            <def>
              <p>The value of the [Reason] property is bound as the value of the SOAP faults
                S:Fault/S:Reason/S:Text element information item.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Details]</label>
            <def>
              <p>The value of the [Details] property is bound as child elements of the SOAP faults
                S:Fault/S:Detail element information item.</p>
            </def>
          </gitem>
        </glist>
        <example>
          <head>Binding of fault properties to SOAP 1.2 messages.</head>
          <eg xml:space="preserve">
&lt;S:Envelope&gt;
  &lt;S:Header&gt;
    &lt;wsa:Action&gt;http://www.w3.org/2005/08/addressing/fault&lt;/wsa:Action&gt;
    &lt;!-- Headers elided for brevity.  --&gt;
  &lt;/S:Header&gt;
  &lt;S:Body&gt;
    &lt;S:Fault&gt;
      &lt;S:Code&gt;
        &lt;S:Value&gt;[Code]&lt;/S:Value&gt;
        &lt;S:Subcode&gt;
          &lt;S:Value&gt;[Subcode]&lt;/S:Value&gt;
          &lt;S:Subcode&gt;
            &lt;S:Value&gt;[Subsubcode]&lt;/S:Value&gt;
          &lt;/S:Subcode&gt;
        &lt;/S:Subcode&gt;
      &lt;/S:Code&gt;
      &lt;S:Reason&gt;
        &lt;S:Text xml:lang="en"&gt;[Reason]&lt;/S:Text&gt;
      &lt;/S:Reason&gt;
      &lt;S:Detail&gt;
        [Detail]
      &lt;/S:Detail&gt;   
    &lt;/S:Fault&gt;
  &lt;/S:Body&gt;
&lt;/S:Envelope&gt;
      </eg>
        </example>
      </div2>
      <div2>
        <head>SOAP 1.1 Fault Binding</head>
        <p>The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only
          [Subcode], [Reason] and [Detail]. These the properties bind to a SOAP 1.1 fault as
          follows:</p>
        <glist>
          <gitem>
            <label>[Subcode] or [Subsubcode]</label>
            <def>
              <p>The value of the [Subsubcode] or, if that is not specified, the value of the
                [Subcode] property is bound as the value of the SOAP faults S11:Fault/faultcode
                element.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Reason]</label>
            <def>
              <p>The value of the [Reason] property is bound as the value of the SOAP faults
                S11:Fault/faultstring element.</p>
            </def>
          </gitem>
          <gitem>
            <label>[Details]</label>
            <def>
              <p>The SOAP 1.1 fault detail is only for use with faults related to the body of a
                message and is therefore not used for SOAP 1.1 faults related to processing of
                addressing headers. Instead the value of the [Details] property is bound as the
                value of a new wsa:FaultDetail SOAP header block. The following describes the
                wsa:FaultDetail element:</p>
              <glist>
                <gitem>
                  <label>/wsa:FaultDetail</label>
                  <def>
                    <p>Zero or more of the elements defined in <specref ref="faultdetailelements"/>.</p>
                  </def>
                </gitem>
                <gitem>
                  <label>/wsa:FaultDetail/@{any}</label>
                  <def>
                    <p>Optional extensibility attributes including SOAP role and mustUnderstand.</p>
                  </def>
                </gitem>
              </glist>
            </def>
          </gitem>
        </glist>
        <example>
          <head>Binding of fault properties to SOAP 1.1 messages.</head>
          <eg xml:space="preserve">
&lt;S11:Envelope&gt;
  &lt;S11:Header&gt;
    &lt;wsa:Action&gt;http://www.w3.org/2005/08/addressing/fault&lt;/wsa:Action&gt;
    &lt;wsa:FaultDetail&gt;[Details]&lt;/wsa:FaultDetail&gt;
    &lt;!-- Other headers elided for brevity.  --&gt;
  &lt;/S11:Header&gt;
  &lt;S11:Body&gt;
    &lt;S11:Fault&gt;
      &lt;faultcode&gt;[Subcode] or [Subsubcode]&lt;/faultcode&gt;
      &lt;faultstring xml:lang="en"&gt;[Reason]&lt;/faultstring&gt;
    &lt;/S11:Fault&gt;
  &lt;/S11:Body&gt;
&lt;/S11:Envelope&gt;
      </eg>
        </example>
      </div2>
      <div2 id="faultdetailelements">
        <head>Fault Detail Elements</head>
        <p>The following subsections define a set of elements used to convey additional information
          in the faults described in <specref ref="soapfaults"/>.</p>
        <div3>
          <head>Problem Header QName</head>
          <p> The following describes the &lt;wsa:ProblemHeaderQName&gt; element:</p>
          <glist>
            <gitem>
              <label>/wsa:ProblemHeaderQName</label>
              <def>
                <p>A QName representing the name of the root element of the problem header
                block.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:ProblemHeaderQName/@{any}</label>
              <def>
                <p>Optional extensibility attributes that do not affect processing.</p>
              </def>
            </gitem>
          </glist>
        </div3>
        <div3>
          <head>Problem IRI</head>
          <p> The following describes the &lt;wsa:ProblemIRI&gt; element:</p>
          <glist>
            <gitem>
              <label>/wsa:ProblemIRI</label>
              <def>
                <p>The IRI that caused the problem.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:ProblemIRI/@{any}</label>
              <def>
                <p>Optional extensibility attributes that do not affect processing.</p>
              </def>
            </gitem>
          </glist>
        </div3>
        <div3>
          <head>Problem Action</head>
          <p> The following describes the &lt;wsa:ProblemAction&gt; element:</p>
          <glist>
            <gitem>
              <label>/wsa:ProblemAction/wsa:Action</label>
              <def>
                <p>An optional element that provides the [action] that caused the problem.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:ProblemAction/wsa:SoapAction</label>
              <def>
                <p>An optional element that provides the SOAPAction IRI that caused the problem.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:ProblemAction/{any}</label>
              <def>
                <p>Optional extensibility elements that do not affect processing.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:ProblemAction/@{any}</label>
              <def>
                <p>Optional extensibility attributes that do not affect processing.</p>
              </def>
            </gitem>
          </glist>
        </div3>
        <div3>
          <head>Retry After</head>
          <p> The following describes the &lt;wsa:RetryAfter&gt; element:</p>
          <glist>
            <gitem>
              <label>/wsa:RetryAfter</label>
              <def>
                <p>This element (whose content is of type xs:unsignedLong) is a suggested minimum
                  duration in milliseconds to wait before retransmitting the message. Omission of
                  this element indicates that a retry is never likely to succeed.</p>
              </def>
            </gitem>
            <gitem>
              <label>/wsa:RetryAfter/@{any}</label>
              <def>
                <p>Optional extensibility attributes that do not affect processing.</p>
              </def>
            </gitem>
          </glist>
        </div3>
      </div2>
      <div2 id="soapfaults">
        <head>Predefined Faults</head>
        <div3 id="invalidmapfault">
          <head> Invalid Addressing Header</head>
          <p>A header representing a WS-Addressing 1.0 Message Addressing Property is invalid and
            cannot be processed. The validity failure can be either structural or semantic, e.g. a
            [destination] that is not an IRI or a [relationship] to a [message id] that was never
            issued.</p>
          <p> [Code] a QName representing the value S:Sender</p>
          <p> [Subcode] a QName representing the value wsa:InvalidAddressingHeader</p>
          <p> [Reason] the string: "A header representing a Message Addressing Property is not valid
            and the message cannot be processed" </p>
          <p> [Details] either a &lt;wsa:ProblemHeader&gt; element that conveys a copy of
            the offending header or a &lt;wsa:ProblemHeaderQName&gt; element that conveys
            the QName of the root element of the offending header.</p>
          <p>The invalid addressing header fault can be further narrowed in scope by use of the
            additional [Subsubcode]s specified in the following subsections. Use of these
            [Subsubcode] values is OPTIONAL.</p>
          <div4>
            <head>wsa:InvalidAddress</head>
            <p>Specifies that an [address] was invalid.</p>
          </div4>
          <div4>
            <head>wsa:InvalidEPR</head>
            <p>Specifies that the invalid header was expected to be an EPR but was not valid.</p>
          </div4>
          <div4>
            <head>wsa:InvalidCardinality</head>
            <p>Specifies that there was a greater than expected number of the specified header.</p>
          </div4>
          <div4>
            <head>wsa:MissingAddressInEPR</head>
            <p>Specifies that the invalid header was expected to be an EPR but did not contain an
              [address].</p>
          </div4>
          <div4>
            <head>wsa:DuplicateMessageID</head>
            <p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
              already received.</p>
          </div4>
          <div4>
            <head>wsa:ActionMismatch</head>
            <p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
              MAY contain a &lt;wsa:ProblemAction&gt; element in addition to the
              &lt;wsa:ProblemHeader&gt; element or &lt;wsa:ProblemHeaderQName&gt;
              element.</p>
          </div4>
          <div4>
            <head>wsa:OnlyAnonymousAddressSupported</head>
            <p>Specifies that the only address supported is the anonymous address.</p>
          </div4>
          <div4>
            <head>wsa:OnlyNonAnonymousAddressSupported</head>
            <p>Specifies that the anonymous address is not supported, and that only a non-anonymous
              address will be accepted.</p>
          </div4>
        </div3>
        <div3 id="missingmapfault">
          <head> Message Addressing Header Required</head>
          <p>A required header representing a Message Addressing Property is absent.</p>
          <p> [Code] a QName representing the value S:Sender</p>
          <p> [Subcode] a QName representing the value wsa:MessageAddressingHeaderRequired</p>
          <p> [Reason] the string: "A required header representing a Message Addressing Property is
            not present"</p>
          <p> [Details] a &lt;wsa:ProblemHeaderQName&gt; element that conveys the QName of
            the message addressing header that was missing.</p>
        </div3>
        <div3 id="destinationfault">
          <head> Destination Unreachable</head>
          <p>The endpoint identified by the value of [destination] property cannot be reached.</p>
          <p> [Code] a QName representing the value S:Sender</p>
          <p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
          <p> [Reason] the string: "No route can be determined to reach [destination]"</p>
          <p> [Details] an optional &lt;wsa:ProblemIRI&gt; element that conveys the
            [address] of the [destination].</p>
          <p>Implementation of this fault is optional.</p>
        </div3>
        <div3 id="actionfault">
          <head> Action Not Supported</head>
          <p>The [action] property in the message is not supported at this endpoint.</p>
          <p> [Code] a QName representing the value S:Sender</p>
          <p> [Subcode] a QName representing the value wsa:ActionNotSupported</p>
          <p> [Reason] the string: "The [action] cannot be processed at the receiver"</p>
          <p> [Details] a &lt;wsa:ProblemAction&gt; element with a REQUIRED
            &lt;wsa:Action&gt; child element</p>
          <p>Implementation of this fault is optional.</p>
        </div3>
        <div3 id="unavailablefault">
          <head> Endpoint Unavailable</head>
          <p>The endpoint is unable to process the message at this time either due to some transient
            issue or a permanent failure. </p>
          <p>The endpoint may optionally include a RetryAfter parameter in the detail. The source
            SHOULD NOT retransmit the message until this duration has passed.</p>
          <p> [Code] a QName representing the value S:Receiver</p>
          <p> [Subcode] a QName representing the value wsa:EndpointUnavailable</p>
          <p> [Reason] the string "The endpoint is unable to process the message at this time"</p>
          <p> [Details] an optional &lt;wsa:RetryAfter&gt; element and an optional
            &lt;wsa:ProblemIRI&gt; element that conveys the [address] of the
          [destination].</p>
          <p>Implementation of this fault is optional.</p>
        </div3>
      </div2>
    </div1>
    <div1 id="securityconsiderations">
      <head>Security Considerations</head>
      <note>
        <p>No assumptions are made herein of the application level security requirement, the
          organization of the application, implementation of senders or receivers, or of the ways
          that other protocols may make use of WS-Addressing, and what security mechanisms they may
          employ. A holistic approach to security which considers all components of the application,
          other protocols utilized, the way that these protocols compose with WS-Security, and the
          use of other methods or additional techniques is highly recommended.</p>
      </note>
      <p>As discussed in Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>], WS-Addressing supports
        capabilities that allow a message sender to instruct a message receiver to send additional
        unsolicited messages to other receivers of their choice and to control the contents of those
        messages to an extent using reference parameters. The SOAP binding of WS-Addressing
        transforms EPR reference parameters into SOAP headers and this allows a message sender to
        request a message receiver to send additional unsolicited SOAP messages to other receivers
        of their choice and to specify a set of SOAP headers that must be included in such messages.</p>
      <p>SOAP headers are a powerful extension mechanism and therefore great care should be taken
        before honoring a [reply endpoint] or [fault endpoint] to avoid inadvertent participation in
        the activities of malicious SOAP message senders.</p>
      <p>WS-Addressing message addressing properties serialized as SOAP headers (wsa:To, wsa:Action
        et al.) including those headers present as a result of the [reference parameters] property
        should be integrity protected as explained in Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>].</p>
      <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is not the predefined
        anonymous URI should include claims that allow a receiver to confirm that the EPR was issued
        by a principle with authority to represent the [address] of the EPR.</p>
      <p>When receiving a SOAP message, certain SOAP headers may have resulted from the
        serialization of an EPR's [reference parameters] property. A SOAP message receiver should
        perform additional security and sanity checks to prevent unintended actions.</p>
      <div2>
        <head>Establishing EPR Trust</head>
        <p>There are many mechanisms that could be used to supply proof that a message sender has
          authority to represent the [address] of EPRs supplied within the message. Typically such
          mechanisms require the inclusion of a WS-Security[<bibref ref="WS-Security"/>] header that
          contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to the
          SOAP message using a security token issued by an authority trusted by the receiver of the
          message for the domain of the [address] of the EPR. Possession of a security token issued
          by a trusted authority for the domain of the [address] of the EPR provides a level of
          confidence that the message sender has authority to represent the [address].</p>
        <p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
          that contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to
          the SOAP message using an X.509 certificate for the domain addressed by the [address] of
          the EPR. If the certificate is issued by a certificate authority trusted by the receiver
          of the message then the receiver can have some level of confidence that the message
          sender has authority to represent the [address] of the EPR.</p>
      </div2>
      <div2>
        <head>Additional Security Considerations</head>
        <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP headers. Message
          processors should consider its appearance elsewhere in a SOAP message as a possible
          attack.</p>
        <p>Message processors should consider elements from the soap11, soap12 and wsa namespaces
          appearing as reference parameters in an EPR as a possible attack.</p>
        <p>There are known XML ID and re-structuring attacks which should be considered by message
          processors, see [<bibref ref="WS-Security"/>] - Security Considerations: Removal and
          modification of XML elements.</p>
      </div2>
      <div2>
        <head>Additional Considerations for SOAP Intermediaries</head>
        <p>To avoid breaking signatures, intermediaries MUST NOT change the XML representation of
          WS-Addressing headers when relaying those headers. Specifically, intermediaries MUST NOT
          remove XML content that explicitly indicates otherwise-implied content, and intermediaries
          MUST NOT insert XML content to make implied values explicit. For instance, if a
          RelationshipType attribute is present with a value of <attval>http://www.w3.org/2005/08/addressing/reply</attval>,
          an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute,
          an intermediary MUST NOT add one.</p>
      </div2>
    </div1>
    <div1 id="conformance">
      <head>Conformance</head>
      <p>A SOAP 1.2 message conforms to the SOAP 1.2 Addressing 1.0 Module when it contains headers
        from the wsa namespace, and follows all the constraints on message addressing properties
        defined by Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>] and by the SOAP 1.2 Addressing
        1.0 Module.</p>
      <p>A SOAP 1.1 message conforms to the SOAP 1.1 Addressing 1.0 Extension when it contains
        headers from the wsa namespace, and follows all the constraints on message addressing
        properties defined by Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>] and by the SOAP 1.1
        Addressing 1.0 Extension.</p>
      <p>An endpoint which conforms to this specification understands and accepts SOAP messages
        containing headers in the wsa namespace targeted to it, generates reply or fault messages it
        may send in response according to the rules outlined in this specification and in
          Web Services Addressing 1.0 - Core[<bibref ref="WSADDR-CORE"/>].</p>
      <note>
        <p>Web Services Addressing 1.0 - WSDL Binding[<bibref ref="WSADDR-WSDL"/>] defines additional conformance
          requirements for the description of an endpoint.</p>
      </note>
      <note>
        <p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p>
      </note>
      <p>If a receiver processes a message containing a wsa:Action header, this SOAP binding is
        engaged, and the rules of this specification are in force.</p>
    </div1>
    <div1 id="references">
      <head> References</head>
    <div2 id="Normative-References">
        <head>Normative References</head>
      <blist>
	<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Key words for use in RFCs to Indicate Requirement
	  Levels</titleref>, S. Bradner, Author. Internet Engineering
	  Task Force, June 1999. Available at
	  http://www.ietf.org/rfc/rfc2119.txt.
	</bibl>
	<bibl id="RFC3987" key="IETF RFC 3987" href="http://www.ietf.org/rfc/rfc3987.txt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Internationalized Resource Identifiers
	  (IRIs)</titleref> M. Duerst, and M.  Suignard, Authors. Internet
	  Engineering Task Force, January 2005. Available at
	  http://www.ietf.org/rfc/rfc3987.txt.
	</bibl>
	<bibl id="SOAP11" key="SOAP 1.1" href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Simple Object Access Protocol (SOAP)
	  1.1</titleref>, D. Box, et al, Editors. World Wide Web
	  Consortium, 8 May 2000. Available at
	  http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
	</bibl>
	<bibl id="SOAP12-PART1" key="SOAP 1.2 Messaging Framework" href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">SOAP Version 1.2 Part 1: Messaging
	  Framework</titleref>, M. Gudgin, M.  Hadley, N. Mendelsohn,
	  J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web
	  Consortium, 24 June 2003. This version of the SOAP Version
	  1.2 Part 1: Messaging Framework Recommendation is
	  http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. The
	  <loc href="http://www.w3.org/TR/soap12-part1/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
	  version of SOAP Version 1.2 Part 1: Messaging
	  Framework</loc> is available at
	  http://www.w3.org/TR/soap12-part1/.
	</bibl>
	<bibl id="SOAP12-PART2" key="SOAP 1.2 Adjuncts" href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
          <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">SOAP Version 1.2 Part 2: Adjuncts</titleref>,
          M. Gudgin, M. Hadley, N.  Mendelsohn, J-J. Moreau,
          H. Frystyk Nielsen, Editors. World Wide Web Consortium, 24
          June 2003. This version of the SOAP Version 1.2 Part 2:
          Adjuncts Recommendation is
          http://www.w3.org/TR/2003/REC-soap12-part2-20030624/. The
          <loc href="http://www.w3.org/TR/soap12-part1/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
          version of SOAP Version 1.2 Part 2: Adjuncts</loc> is
          available at http://www.w3.org/TR/soap12-part2/.
	</bibl>
	<bibl key="WS-Addressing Core" id="WSADDR-CORE" href="http://www.w3.org/TR/2006/REC-ws-addr-core-20060509" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Addressing 1.0 - Core</titleref>, M. Gudgin, M. Hadley,
	  and T. Rogers, Editors. World Wide Web Consortium,
	  9 May 2006. This version of the
	  WS-Addressing Core Recommendation is
	  http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. The <loc href="http://www.w3.org/TR/ws-addr-core" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  WS-Addressing Core</loc> is available at
	  http://www.w3.org/TR/ws-addr-core.
	</bibl>
	<bibl id="XML10" key="XML 1.0" href="http://www.w3.org/TR/2004/REC-xml-20040204" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Extensible Markup Language (XML) 1.0 (Third
	  Edition)</titleref>, T.  Bray, J. Paoli,
	  C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 4 February
	  2004. This version of the XML 1.0 Recommendation is
	  http://www.w3.org/TR/2004/REC-xml-20040204. The <loc href="http://www.w3.org/TR/REC-xml" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of XML
	  1.0</loc> is available at http://www.w3.org/TR/REC-xml.
	</bibl>
	<bibl id="XMLNS" key="XML Namespaces" href="http://www.w3.org/TR/1999/REC-xml-names-19990114" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Namespaces in XML</titleref>, T. Bray,
	  D. Hollander, and A. Layman, Editors.
	  World Wide Web Consortium, 14 January 1999. This version of
	  the XML Information Set Recommendation is
	  http://www.w3.org/TR/1999/REC-xml-names-19990114. The <loc href="http://www.w3.org/TR/REC-xml-names" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  Namespaces in XML</loc> is available at
	  http://www.w3.org/TR/REC-xml-names.
	</bibl>
	<bibl id="XMLInfoSet" key="XML Information Set" href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Information Set (Second Edition)</titleref>,
	  J. Cowan and R. Tobin, Editors. World
	  Wide Web Consortium, 4 February 2004. This version of the
	  XML Information Set Recommendation is
	  http://www.w3.org/TR/2004/REC-xml-infoset-20040204. The <loc href="http://www.w3.org/TR/xml-infoset" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  XML Information Set</loc> is available at
	  http://www.w3.org/TR/xml-infoset.
	</bibl>
	<bibl id="XMLSchemaP1" key="XML Schema Structures" href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Schema Part 1: Structures Second
	  Edition</titleref>, H. Thompson, D. Beech, M. Maloney, and
	  N. Mendelsohn, Editors. World Wide Web Consortium, 28
	  October 2004. This version of the XML Schema Part 1
	  Recommendation is
	  http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <loc href="http://www.w3.org/TR/xmlschema-1/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  XML Schema Part 1</loc> is available at
	  http://www.w3.org/TR/xmlschema-1.
	</bibl>
	<bibl key="XML Schema Datatypes" id="XMLSchemaP2" href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">XML Schema Part 2: Datatypes Second
	  Edition</titleref>, P. Byron and A. Malhotra, Editors. World
	  Wide Web Consortium, 28 October 2004. This version of the
	  XML Schema Part 2 Recommendation is
	  http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <loc href="http://www.w3.org/TR/xmlschema-2/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  XML Schema Part 2</loc> is available at
	  http://www.w3.org/TR/xmlschema-2.
	</bibl>
      </blist>
    </div2>
    <div2 id="Informative-References">
      <head>Other References</head>
      <blist>
	<bibl id="SOAP11-ROR" key="SOAP 1.1 Request Optional Response HTTP Binding" href="http://www.w3.org/TR/2006/NOTE-soap11-ror-httpbinding-20060321/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">SOAP 1.1 Request Optional Response HTTP
	  Binding</titleref>, D. Orchard, Editor.  World Wide Web
	  Consortium, 21 March 2006. This version of the SOAP 1.1 Request Optional Response HTTP
	  Binding specification is http://www.w3.org/TR/2006/NOTE-soap11-ror-httpbinding-20060321/. The <loc href="http://www.w3.org/TR/soap11-ror-httpbinding" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest
	  version of SOAP 1.1 Request Optional Response HTTP
	  Binding</loc> is available
	  http://www.w3.org/TR/soap11-ror-httpbinding.
        </bibl>
	<bibl key="WS-Addressing WSDL Binding" id="WSADDR-WSDL" href="http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Addressing 1.0 - WSDL Binding</titleref>, M. Gudgin, M. Hadley,
	  T. Rogers, Ü.  Yalçinalp, Editors. World Wide Web
	  Consortium, 16 February 2006. This version of the
	  WS-Addressing WSDL Binding specification is
	  http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216. The <loc href="http://www.w3.org/TR/ws-addr-wsdl" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of
	  WS-Addressing WSDL Binding</loc> is available at
	  http://www.w3.org/TR/ws-addr-wsdl.
	</bibl>
	<bibl key="WSDL 2.0 Core Language" id="WSDL20" href="http://www.w3.org/TR/2006/CR-wsdl20-20060327" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Description Language (WSDL) Version
	  2.0 Part 1: Core Language</titleref>, R. Chinnici,
	  J. J. Moreau, A. Ryman, and S. Weerawarana, Editors. World
	  Wide Web Consortium, 27 March 2006. This version of the WSDL
	  2.0 specification is
	  http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <loc href="http://www.w3.org/TR/wsdl20" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">latest version of WSDL
	  2.0</loc> is available at http://www.w3.org/TR/wsdl20.
	</bibl>
	<bibl id="WS-Security" key="WS-Security" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">
	  <titleref xlink:type="simple" xlink:show="new" xlink:actuate="onRequest">Web Services Security: SOAP Message Security 1.0
	  (WS-Security 2004)</titleref>, A. Nadalin, C. Kaler,
	  P. Hallam-Baker, R. Monzillo, Editors.
	  Organization for the Advancement of Structured Information Standards, March 2004.
	</bibl>
      </blist>
    </div2>
    </div1>
  </body>
  <back>
    
<inform-div1 id="acknowledgments">
  <head>Acknowledgements</head>
  <p>This document is the work of the <loc href="http://www.w3.org/2002/ws/addr/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">W3C Web Service
      Addressing Working Group</loc>.</p>
  <p>Members of the Working Group are (at the time of writing, and by
      alphabetical order):
      Abbie Barbir (Nortel Networks), Andreas Bjärlestam (ERICSSON), Dave Chappell (Sonic Software), Eran Chinthaka (WSO2), Francisco Curbera (IBM Corporation), Glen Daniels (Sonic Software), Vikas Deolaliker (Sonoa Systems, Inc.), Paul Downey (BT), Jacques Durand (Fujitsu Limited), Robert Freund (Hitachi, Ltd.), Marc Goodner (Microsoft Corporation), Arun Gupta (Sun Microsystems, Inc.), Hugo Haas (W3C/ERCIM), Marc Hadley (Sun Microsystems, Inc.), David Hull (TIBCO Software, Inc.), Yin-Leng Husband (HP), David Illsley (IBM Corporation), Anish Karmarkar (Oracle Corporation), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Amelia Lewis (TIBCO Software, Inc.), Bozhong Lin (IONA Technologies, Inc.), Mark Little (JBoss Inc.), Jonathan Marsh (Microsoft Corporation), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (ERICSSON), Eisaku Nishiyama (Hitachi, Ltd.), Ales Novy (Systinet Inc.), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA Systems, Inc.), Alain Regnier (Ricoh Company, Ltd.), Tony Rogers (Computer Associates), Tom Rutt (Fujitsu Limited), Davanum Srinivas (WSO2), Jiri Tejkl (Systinet Inc.), Mike Vernal (Microsoft Corporation), Steve Vinoski (IONA Technologies, Inc.), Katy Warr (IBM Corporation), Pete Wenzel (Sun Microsystems, Inc.), Steve Winkler (SAP AG), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
  </p>
  <p>Previous members of the Working Group were:
      Lisa Bahler (SAIC - Telcordia Technologies), Rebecca Bergersen (IONA Technologies, Inc.), Ugo Corda (Sun Microsystems, Inc.), Michael Eder (Nokia), Yaron Goland (BEA Systems, Inc.), Marc Goodner (SAP AG), Martin Gudgin (Microsoft Corporation), Mark Nottingham (BEA Systems, Inc.), Mark Peel (Novell, Inc.), Harris Reynolds (webMethods, Inc.), Rich Salz (IBM Corporation), Davanum Srinivas (Computer Associates), Greg Truty (IBM Corporation).
  </p>
  <p>The people who have contributed to <loc href="http://lists.w3.org/Archives/Public/public-ws-addressing/" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">discussions
      on public-ws-addressing@w3.org</loc> are also gratefully
      acknowledged.</p>
</inform-div1>

  </back>
</spec>