2004/ws/addressing ws-addr-core.html,1.27,1.28 ws-addr-soap.html,1.32,1.33

Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv5349

Modified Files:
	ws-addr-core.html ws-addr-soap.html 
Log Message:
Updated following chnages to XML

Index: ws-addr-core.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.html,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -d -r1.27 -r1.28
*** ws-addr-core.html	25 May 2005 21:40:40 -0000	1.27
--- ws-addr-core.html	2 Jun 2005 20:04:19 -0000	1.28
***************
*** 71,75 ****
      <hr><div class="toc">
  <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#tocRange">Introduction</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#notation">Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#namespaces">Namespaces</a><br>2. <a href="#eprs">Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#eprinfomodel">Information Model for Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#eprinfoset">Endpoint Reference XML Infoset Representation</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#eprcomp">Endpoint Reference Comparison</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.5 <a href="#eprextensibility">Endpoint Reference Extensibility</a><br>3. <a href="#msgaddrprops">Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#abstractmaps">Abstract Property Definitions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#msgaddrpropsinfoset">XML Infoset Representation of MessageAddressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.1 <a href="#compiri">Comparing IRIs</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#formreplymsg">Formulating a Reply Message</a><br>4. <a href="#securityconsiderations">Security Considerations</a><br>5. <a href="#references">References</a><br></p>
! <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N67090">Changes Since Last Call Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N67100">Changes Since Second Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#N67110">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#N67120">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
--- 71,75 ----
      <hr><div class="toc">
  <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#tocRange">Introduction</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#notation">Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#namespaces">Namespaces</a><br>2. <a href="#eprs">Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#eprinfomodel">Information Model for Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#eprinfoset">Endpoint Reference XML Infoset Representation</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#eprcomp">Endpoint Reference Comparison</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.5 <a href="#eprextensibility">Endpoint Reference Extensibility</a><br>3. <a href="#msgaddrprops">Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#abstractmaps">Abstract Property Definitions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#msgaddrpropsinfoset">XML Infoset Representation of MessageAddressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.1 <a href="#compiri">Comparing IRIs</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#formreplymsg">Formulating a Reply Message</a><br>4. <a href="#securityconsiderations">Security Considerations</a><br>5. <a href="#references">References</a><br></p>
! <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N67121">Changes Since Last Call Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N67131">Changes Since Second Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#N67141">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#N67151">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
***************
*** 87,92 ****
                  independent of the underlying transport.</p>
              <p>Both of these constructs are designed to be extensible and re-usable so that other
!                 specifications can build on and leverage endpoint references and message information
!                 headers.</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
--- 87,92 ----
                  independent of the underlying transport.</p>
              <p>Both of these constructs are designed to be extensible and re-usable so that other
!                 specifications can build on and leverage endpoint references and message addressing
!                 properties.</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
***************
*** 114,118 ****
                      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 information header blocks. Specifically,
                      line (02) 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
--- 114,118 ----
                      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 header blocks. Specifically,
                      line (02) 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
***************
*** 138,141 ****
--- 138,148 ----
                      indicates the presence of an attribute wildcard
                      (&lt;xs:anyAttribute/&gt;).</p>
+                 <p>When defining the cardinality of endpoint reference properties and 
+                     message addressing properties, this
+                     specification uses the following notation: (<i>n</i>..<i>m</i>), where <i>n</i>
+                     is the minimum allowed number of ocurrances of the property and <i>m</i> is the maximum
+                     allowed number of occurances. When <i>n</i> has the same value as <i>m</i> then exactly
+                     that number of ocurrances of the property must be present in the associated
+                     endpoint reference or message.</p>
              </div>
              <div class="div2">
***************
*** 223,227 ****
                                  items that are required to properly interact with the endpoint.
                                  Reference parameters are provided by the issuer of the endpoint
!                                 reference and are assumed to be opaque to consuming applications.
                                  The binding of reference parameters to messages depends upon the
                                  protocol binding used to interact with the endpoint -
--- 230,235 ----
                                  items that are required to properly interact with the endpoint.
                                  Reference parameters are provided by the issuer of the endpoint
!                                 reference and are assumed to be opaque to other users of an
!                                 endpoint refernce.
                                  The binding of reference parameters to messages depends upon the
                                  protocol binding used to interact with the endpoint -
***************
*** 235,240 ****
                              <p>A reference may contain metadata that describes the behavior,
                                  policies and capabilities of the endpoint. Metadata may be included
!                                 in an endpoint reference to facilitate easier processing by the
!                                 consuming application, or because the metadata was dynamically
                                  generated.</p>
                              <p>The metadata embedded in an EPR is not necessarily a complete
--- 243,248 ----
                              <p>A reference may contain metadata that describes the behavior,
                                  policies and capabilities of the endpoint. Metadata may be included
!                                 in an endpoint reference to facilitate easier processing by
!                                 a user of an endpoint reference, or because the metadata was dynamically
                                  generated.</p>
                              <p>The metadata embedded in an EPR is not necessarily a complete
***************
*** 416,421 ****
              <div class="note"><p class="prefix"><b>Note:</b></p>
                  <p> The Working Group requests feedback regarding the mechanism for and description
!                     of Message Addressing Property extensibility /beyond the MEPs currently
!                     described in the WSDL specifications/, along with use cases that illustrate how
                      referencing specifications and other users of Addressing intend to extend them.
                      Although the Working Group has resolved upon a <a href="http://www.w3.org/2002/ws/addr/wd-issues/#i054">particular
--- 424,429 ----
              <div class="note"><p class="prefix"><b>Note:</b></p>
                  <p> The Working Group requests feedback regarding the mechanism for and description
!                     of Message Addressing Property extensibility beyond the MEPs currently
!                     described in the WSDL specifications, along with use cases that illustrate how
                      referencing specifications and other users of Addressing intend to extend them.
                      Although the Working Group has resolved upon a <a href="http://www.w3.org/2002/ws/addr/wd-issues/#i054">particular
***************
*** 433,447 ****
              <p> The basic interaction pattern from which all others are composed is "one way". In
                  this pattern a source sends a message to a destination without any further
!                 definition of the interaction. "Request/Reply" is a common interaction pattern that
                  consists of an initial message sent by a source endpoint (the request) and a
                  subsequent message sent from the destination of the request back to the source (the
!                 reply). A reply in this case can be either an application message, a fault, or any
                  other message. Note, however, that reply messages may be sent as part of other
                  message exchanges as well, and are not restricted to the usual single Request,
!                 single Reply pattern, or to a particular WSDL MEP. The contract between the
                  interacting parties may specify that multiple or even a variable number of replies
                  be delivered. </p>
              <p> The set of message addressing properties defined in this specification is sufficient
!                 for many simple variations of one-way and request-reply MEPs. More advanced MEPs may
                  require additional message addressing properties to augment the facilities provided
                  here. </p>
--- 441,455 ----
              <p> The basic interaction pattern from which all others are composed is "one way". In
                  this pattern a source sends a message to a destination without any further
!                 definition of the interaction. "Request-response" is a common interaction pattern that
                  consists of an initial message sent by a source endpoint (the request) and a
                  subsequent message sent from the destination of the request back to the source (the
!                 response). A response in this case can be either an application message, a fault, or any
                  other message. Note, however, that reply messages may be sent as part of other
                  message exchanges as well, and are not restricted to the usual single Request,
!                 single Response pattern, or to a particular WSDL MEP. The contract between the
                  interacting parties may specify that multiple or even a variable number of replies
                  be delivered. </p>
              <p> The set of message addressing properties defined in this specification is sufficient
!                 for many simple variations of one-way and request-response MEPs. More advanced MEPs may
                  require additional message addressing properties to augment the facilities provided
                  here. </p>
***************
*** 452,457 ****
              
              <p>Message addressing properties collectively augment a message with the following
!                 abstract properties to support one way, request reply, and other interaction
!                 pattern:</p>
              <dl>
                  
--- 460,465 ----
              
              <p>Message addressing properties collectively augment a message with the following
!                 abstract properties to support one-way, request-response, and other interaction
!                 patterns:</p>
              <dl>
                  
***************
*** 472,479 ****
                      <dd>
                          <p>An endpoint reference for the intended receiver for replies to this
!                             message. If a reply is expected, a message MUST contain a [reply
!                             endpoint]. The sender MUST use the contents of the [reply endpoint] to
!                             formulate the reply message as defined in <a href="#formreplymsg"><b>3.3 Formulating a Reply Message</b></a>.
!                             If this property is present, the [message id] property is REQUIRED.</p>
                      </dd>
                  
--- 480,484 ----
                      <dd>
                          <p>An endpoint reference for the intended receiver for replies to this
!                             message.</p>
                      </dd>
                  
***************
*** 482,489 ****
                      <dd>
                          <p>An endpoint reference for the intended receiver for faults related to
!                             this message. When formulating a fault message as defined in <a href="#formreplymsg"><b>3.3 Formulating a Reply Message</b></a>, the sender MUST use the contents of the [fault
!                             endpoint], when present, of the message being replied to formulate the
!                             fault message. If this property is present, the [message id] property is
!                             REQUIRED.</p>
                      </dd>
                  
--- 487,491 ----
                      <dd>
                          <p>An endpoint reference for the intended receiver for faults related to
!                             this message.</p>
                      </dd>
                  
***************
*** 506,512 ****
                              id] property. A message MAY be retransmitted for any reason including
                              communications failure and MAY use the same [message id] property. The
!                             value of this property is an opaque IRI whose interpretation beyond
!                             equivalence is not defined in this specification. If a reply is
!                             expected, this property MUST be present. </p>
                      </dd>
                  
--- 508,513 ----
                              id] property. A message MAY be retransmitted for any reason including
                              communications failure and MAY use the same [message id] property. The
!                             value of this property is an IRI whose interpretation beyond
!                             equivalence is not defined in this specification.</p>
                      </dd>
                  
***************
*** 518,523 ****
                              The related message is identified by an absolute IRI that corresponds to
                              the related message's [message id] property. The message identifier IRI
!                             may refer to a specific message, or be the following well-known URI that
!                             means "unspecified message": "http://www.w3.org/@@@@/@@/addressing/id/unspecified"
                          </p>
                          <p>This specification has one predefined relationship type as shown in
--- 519,524 ----
                              The related message is identified by an absolute IRI that corresponds to
                              the related message's [message id] property. The message identifier IRI
!                             may refer to a specific message, or be the following pre-defined URI that
!                             means "unspecified message": "http://www.w3.org/@@@@/@@/addressing/unspecified"
                          </p>
                          <p>This specification has one predefined relationship type as shown in
***************
*** 539,546 ****
                              </tbody>
                          </table><br>
-                         <p>A reply message MUST contain a [relationship] property consisting of the
-                             predefined reply URI and the [message id] property of the request
-                             message. A reply message MUST NOT contain more than one [relationship]
-                             property using the predefined reply URI</p>
                      </dd>
                  
--- 540,543 ----
***************
*** 553,568 ****
                  
              </dl>
!             <p>The mandatory [destination] and [action] properties indicate the target processing
                  location and the verb or intent of the message respectively. The values of these
!                 properties can be used to facilitate the dispatch of incoming messages.</p>
              <p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
                  DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
                  endpoint. To allow these "anonymous" endpoints to send and receive messages,
!                 WS-Addressing defines the following well-known URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: "http://www.w3.org/@@@@/@@/addressing/address/anonymous"
!             </p>
!             <p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
!                 address MUST provide some out-of-band mechanism for delivering replies or faults
                  (e.g. returning the reply on the same transport connection).</p>
              </div>
              
--- 550,568 ----
                  
              </dl>
!             <p>The [destination] and [action] properties indicate the target processing
                  location and the verb or intent of the message respectively. The values of these
!                 properties can be used to facilitate the dispatch of messages.</p>
              <p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
                  DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
                  endpoint. To allow these "anonymous" endpoints to send and receive messages,
!                 WS-Addressing defines the following pre-defined URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: "http://www.w3.org/@@@@/@@/addressing/anonymous". Messages 
!                 whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
!                 address MUST rely on some out-of-band mechanism for delivering replies or faults
                  (e.g. returning the reply on the same transport connection).</p>
+                 <p>A binding of WS_Addressing message addressing properties MUST reflect the
+                     property cardinality shown above. Web Services Addressing 1.0 - SOAP Binding[<cite><a href="#WSADDR-SOAP">WS-Addressing-SOAP</a></cite>]
+                     defines such a binding for the SOAP 
+                     [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1: Messaging Framework</a></cite>, <cite><a href="#SOAP11">SOAP 1.1</a></cite>] protocol.</p>
              </div>
              
***************
*** 594,598 ****
                                  [destination] property. If this element is NOT present then the
                                  value of the [destination] property is
!                                 "http://www.w3.org/@@@@/@@/addressing/address/anonymous".</p>
                          </dd>
                      
--- 594,598 ----
                                  [destination] property. If this element is NOT present then the
                                  value of the [destination] property is
!                                 "http://www.w3.org/@@@@/@@/addressing/anonymous".</p>
                          </dd>
                      
***************
*** 608,614 ****
                          <dd>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [reply endpoint] property. This element MUST be
!                                 present if a reply is expected. If this element is present,
!                                 wsa:MessageID MUST be present.</p>
                          </dd>
                      
--- 608,612 ----
                          <dd>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [reply endpoint] property.</p>
                          </dd>
                      
***************
*** 617,622 ****
                          <dd>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [fault endpoint] property. If this element is
!                                 present, wsa:MessageID MUST be present.</p>
                          </dd>
                      
--- 615,619 ----
                          <dd>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [fault endpoint] property.</p>
                          </dd>
                      
***************
*** 632,637 ****
                          <dd>
                              <p>This OPTIONAL element (whose content is of type xs:anyURI) conveys the [message id]
!                                 property. This element MUST be present if wsa:ReplyTo or wsa:FaultTo
!                                 is present.</p>
                          </dd>
                      
--- 629,633 ----
                          <dd>
                              <p>This OPTIONAL element (whose content is of type xs:anyURI) conveys the [message id]
!                                 property.</p>
                          </dd>
                      
***************
*** 642,647 ****
                                  abstract [relationship] property value, in the form of an (IRI, IRI)
                                  pair. The content of this element (of type
!                                 xs:anyURI) conveys the [message id] of the related message. This
!                                 element MUST be present if the message is a reply.</p>
                          </dd>
                      
--- 638,642 ----
                                  abstract [relationship] property value, in the form of an (IRI, IRI)
                                  pair. The content of this element (of type
!                                 xs:anyURI) conveys the [message id] of the related message.</p>
                          </dd>
                      
***************
*** 676,680 ****
                      <p>Comparison of [destination] property values is out of scope, other than using
                          simple string comparison to detect whether the value is anonymous, that is,
!                         where [destination] has the value "http://www.w3.org/@@@@/@@/addressing/address/anonymous".</p>
                  </div>
              </div>
--- 671,675 ----
                      <p>Comparison of [destination] property values is out of scope, other than using
                          simple string comparison to detect whether the value is anonymous, that is,
!                         where [destination] has the value "http://www.w3.org/@@@@/@@/addressing/anonymous".</p>
                  </div>
              </div>
***************
*** 682,687 ****
                  
  <h3><a name="formreplymsg"></a>3.3 Formulating a Reply Message</h3>
!                 <p>The reply to a WS-Addressing compliant request message MUST be compliant to
!                     WS-Addressing and is constructed according to the following rules:</p>
                  <ol>
                      <li>
--- 677,682 ----
                  
  <h3><a name="formreplymsg"></a>3.3 Formulating a Reply Message</h3>
!                 <p>This section specifies the WS-Addressing-specific rules for creating a reply or
!                     fault message related to another message.</p>
                  <ol>
                      <li>
***************
*** 690,706 ****
                              <li>
                                  <p>If the reply is a normal message, select the EPR from the
!                                     incoming message's [reply endpoint] message addressing property.
                                      If none is present, the processor MUST fault.</p>
                              </li>
                              <li>
!                                 <p>Otherwise, if the reply is a fault message and the incoming
                                      message's [fault endpoint] message addressing property is not
                                      empty, select the EPR from that property. If the [fault
!                                     endpoint] property is empty, select the EPR from the incoming
                                      message's [reply endpoint] message addressing property.
                                      Otherwise, if the [reply endpoint] property is empty, the
!                                     behavior of the recipient of the incoming message is
                                      unconstrained by this specification.</p>
                              </li>
                          </ul>
                      </li>
--- 685,703 ----
                              <li>
                                  <p>If the reply is a normal message, select the EPR from the
!                                     related message's [reply endpoint] message addressing property.
                                      If none is present, the processor MUST fault.</p>
                              </li>
                              <li>
!                                 <p>Otherwise, if the reply is a fault message and the related
                                      message's [fault endpoint] message addressing property is not
                                      empty, select the EPR from that property. If the [fault
!                                     endpoint] property is empty, select the EPR from the related
                                      message's [reply endpoint] message addressing property.
                                      Otherwise, if the [reply endpoint] property is empty, the
!                                     behavior of the recipient of the related message is
                                      unconstrained by this specification.</p>
                              </li>
+                             <li><p>In either of the above cases, if the related message lacks a [message id] property,
+                                 the processor MUST fault.</p></li>
                          </ul>
                      </li>
***************
*** 713,717 ****
                              </li>
                              <li>
!                                 <p>[relationship]: a new pair of IRIs is added to this value as
                                      follows; the relationship type is the predefined reply URI
                                          "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's
--- 710,715 ----
                              </li>
                              <li>
!                                 <p>[relationship]: this property MUST include a 
!                                     pair of IRIs as
                                      follows; the relationship type is the predefined reply URI
                                          "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's
***************
*** 727,734 ****
                      </li>
                  </ol>
!                 <p>The following example illustrates a request message containing message addressing
                      properties serialized as header blocks in a SOAP 1.2 message:</p>
                  <div class="exampleOuter">
!                     <p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Example request message.</i></p>
                      <div class="exampleInner"><pre>
  &lt;S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
--- 725,732 ----
                      </li>
                  </ol>
!                 <p>The following example illustrates a message containing message addressing
                      properties serialized as header blocks in a SOAP 1.2 message:</p>
                  <div class="exampleOuter">
!                     <p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Example message.</i></p>
                      <div class="exampleInner"><pre>
  &lt;S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
***************
*** 772,776 ****
                  <p>The following example illustrates a reply to the above message:</p>
                  <div class="exampleOuter">
!                     <p style="text-align: left" class="exampleHead"><i><span>Example 3-2. </span>Example response message.</i></p>
                      <div class="exampleInner"><pre>
  &lt;S:Envelope
--- 770,774 ----
                  <p>The following example illustrates a reply to the above message:</p>
                  <div class="exampleOuter">
!                     <p style="text-align: left" class="exampleHead"><i><span>Example 3-2. </span>Example reply message.</i></p>
                      <div class="exampleInner"><pre>
  &lt;S:Envelope
***************
*** 813,817 ****
              
  <h2><a name="securityconsiderations"></a>4. Security Considerations</h2>
!             <p>Users of WS-Addressing and EPRs (i.e., entities creating, consuming or receiving
                  Message Addressing Properties and EPRs) SHOULD only use EPRs from sources they
                  trust. For example, such users might rely on the presence of a verifiable
--- 811,815 ----
              
  <h2><a name="securityconsiderations"></a>4. Security Considerations</h2>
!             <p>Users of WS-Addressing and EPRs (i.e., entities creating and receiving
                  Message Addressing Properties and EPRs) SHOULD only use EPRs from sources they
                  trust. For example, such users might rely on the presence of a verifiable
***************
*** 830,835 ****
                  confused with a replay attack. It is also advisable to use message identifiers that are not
                  predictable, to prevent attackers from constructing and sending
!                 an unsolicited reply to an outstanding request without having to 
!                 see the actual request message.</p>
          </div>
          <div class="div1">
--- 828,841 ----
                  confused with a replay attack. It is also advisable to use message identifiers that are not
                  predictable, to prevent attackers from constructing and sending
!                 an unsolicited reply to a message without having to 
!                 see the actual message.</p>
!             <p>When [reply endpoint] and/or [fault endpoint] do not contain the
!                 anonymous URI, the processor of such an EPR should take care to avoid
!                 a denial of service attack caused by opening an excessive number
!                 network connections, which are typically a scarce resource.</p>
!             <p>Care should be taken to avoid participating in a denial of service
!                 attack in which an attacker sends messages to many receivers
!                 and includes a [reply endpoint] or [fault endpoint] for the target
!                 of the attack.</p>
          </div>
          <div class="div1">
***************
*** 922,931 ****
          <div class="div2">
          
! <h3><a name="N67090"></a>B.1 Changes Since Last Call Working Draft</h3>
!       <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-05-25 @ 20:25</td><td>mhadley</td><td>Added resolution to issue lc39 - changed mandatory to 1..1</td></tr><tr><td>2005-05-25 @ 20:20</td><td>mhadley</td><td>Added resolution to issue lc66 - made it clear that type often refers to the content of elements rather than the element as a whole which can often also include attributes</td></tr><tr><td>2005-05-18 @ 19:49</td><td>mhadley</td><td>Added lc81 resolution - remove mustUnderstand attributes from examples</td></tr><tr><td>2005-05-18 @ 19:35</td><td>mhadley</td><td>Added lc51 resolution - reordered property list to match order in core</td></tr><tr><td>2005-05-18 @ 19:22</td><td>mhadley</td><td>Added lc47 resolution - fixed URL in WSDL 2.0 biblio entry</td></tr><tr><td>2005-05-18 @ 18:58</td><td>mhadley</td><td>Added lc97 resolution - Endpoint Reference to endpoint reference</td></tr><tr><td>2005-05-18 @ 18:56</td><td>mhadley</td><td>Added lc95 resolution - added WDL 1.1 citation to introduction</td></tr><tr><td>2005-05-18 @ 18:51</td><td>mhadley</td><td>Added lc94 resolution - changed element to Element Information Item</td></tr><tr><td>2005-05-18 @ 18:48</td><td>mhadley</td><td>Added lc93 resolution - added ref to soap binding document prior to soap example in introduction</td></tr><tr><td>2005-05-18 @ 18:44</td><td>mhadley</td><td>Added lc92 resolution - clarified document being referenced in introduction</td></tr><tr><td>2005-05-18 @ 18:40</td><td>mhadley</td><td>Added lc80 resolution - made abstract properties into a separate list</td></tr><tr><td>2005-05-18 @ 18:34</td><td>mhadley</td><td>Added lc74 resolution - added suggested security consideration</td></tr><tr><td>2005-05-18 @ 18:24</td><td>mhadley</td><td>Added lc63 resolution - editorial fixes to security section</td></tr><tr><td>2005-05-18 @ 18:19</td><td>mhadley</td><td>Added lc44 resolution - changed and to or in security section</td></tr><tr><td>2005-05-18 @ 18:17</td><td>mhadley</td><td>Added lc43 reslution - added ref to SOAP 1.1</td></tr><tr><td>2005-05-18 @ 18:12</td><td>mhadley</td><td>Added lc42 resolution - reordered infoset representation to match order of abstract properties</td></tr><tr><td>2005-05-18 @ 18:03</td><td>mhadley</td><td>Added lc67 resolution - made namespace uri a link</td></tr><tr><td>2005-05-18 @ 17:58</td><td>mhadley</td><td>Added lc64 resolution - numerous editorial fixes</td></tr><tr><td>2005-05-16 @ 20:28</td><td>mgudgin</td><td>Fixed mismatched endtag in Section 3.1</td></tr><tr><td>2005-05-16 @ 20:16</td><td>mgudgin</td><td>Fixed reference to RFC3987 to match format of other biblio entries</td></tr><tr><td>2005-04-22 @ 18:26</td><td>mhadley</td><td>Added resolution to lc22 - clarified ignore rule for extension attributes.</td></tr><tr><td>2005-04-22 @ 18:24</td><td>mhadley</td><td>Added resolution to lc21 - removed HTTP specific restriction on use of anonymous URI in [destination] for replies only.</td></tr><tr><td>2005-04-22 @ 18:18</td><td>mhadley</td><td>Added resolutionto lc19 - clarified that [destination] value comparison is out of scope except for using simple string comparison to determine whether the anonymous destination is being used.</td></tr><tr><td>2005-04-22 @ 18:12</td><td>mhadley</td><td>Added resolution to lc18 - simplified description of wsa:To and wsa:Action elements</td></tr><tr><td>2005-04-22 @ 18:04</td><td>mhadley</td><td>Added resolution to lc17 - clarified that anonymous destination URI is not just for use in replies</td></tr><tr><td>2005-04-22 @ 18:01</td><td>mhadley</td><td>Added resolution to lc16 and lc54 - removed suggestion that required was required to use [destination] and [action] properties for dispatch</td></tr><tr><td>2005-04-22 @ 17:55</td><td>mhadley</td><td>Added resolution to lc15 - clarified cardinality of [relationship] properties using predefined reply URI</td></tr><tr><td>2005-04-22 @ 17:50</td><td>mhadley</td><td>Added resolution to lc14 - clarified reply IRI targetting</td></tr><tr><td>2005-04-22 @ 17:41</td><td>mhadley</td><td>dded resolution to lc13 - clarified wording in  description of metadata</td></tr><tr><td>2005-04-22 @ 17:38</td><td>mhadley</td><td>Added resolution to lc12 - removed data encoding from description of reference parameters</td></tr><tr><td>2005-04-22 @ 17:30</td><td>mhadley</td><td>Added resolution to lc10 and lc11 - clarified types and opacity of reference parameters</td></tr><tr><td>2005-04-22 @ 17:25</td><td>mhadley</td><td>Added resolution to lc9 - changed IRI to absolute IRI where appropriate</td></tr><tr><td>2005-04-22 @ 16:16</td><td>mhadley</td><td>Added resolution to lc8 - changed IRI to URI where used to refer to IRIs in the specification that are actually URIs</td></tr><tr><td>2005-04-22 @ 15:49</td><td>mhadley</td><td>Added resolution to lc7 - fixed editorial nits</td></tr><tr><td>2005-04-22 @ 15:32</td><td>mhadley</td><td>Added resolution to lc3 - removed single extensibility point from infoset representation to avoid impression that other extenisibility points are not also valid</td></tr><tr><t>2005-04-22 @ 15:06</td><td>mhadley</td><td>Added resolution to lc2 - assorted editorial changes</td></tr></table>
      </div>
      <div class="div2">
          
! <h3><a name="N67100"></a>B.2 Changes Since Second Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-03-30 @ 21:02</td><td>plehegar</td><td>Removed some extra blanks
  Added the note from David Hull at
--- 928,937 ----
          <div class="div2">
          
! <h3><a name="N67121"></a>B.1 Changes Since Last Call Working Draft</h3>
!       <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-06-02 @ 19:48</td><td>mhadley</td><td>Added resolution to issue lc78 - reworked formulating reply message text related to [relationship] to make it clear that the reply relationsship is not added top the relationships specified in the message being replied to</td></tr><tr><td>2005-06-02 @ 19:39</td><td>mhadley</td><td>Added resolution to issue lc84 - removed redundant co-occurrence requirements and concentrated conformance requirements in section 3.3</td></tr><tr><td>2005-06-02 @ 18:47</td><td>mhadley</td><td>Added resolution to issue lc89 - assorted editorial fixes</td></tr><tr><td>2005-06-02 @ 18:15</td><td>mhadley</td><td>Added resolution to issue lc37 - added DOS attack security considerations</td></tr><tr><td>2005-06-02 @ 18:07</td><td>mhadley</td><td>Added explanation of cardinality notation</td></tr><tr><td>2005-05-25 @ 21:40</td><td>mhadley</td><td>Added new section in changelog to account for previous drft publication</td></tr><tr><td>2005-05-25 @ 20:25</td><td>mhadley</td><td>Added resolution to issue lc39 - changed mandatory to 1..1</td></tr><tr><td>2005-05-25 @ 20:20</td><td>mhadley</td><td>Added resolution to issue lc66 - made it clear that type often refers to the content of elements rather than the element as a whole which can often also include attributes</td></tr><tr><td>2005-05-18 @ 19:49</td><td>mhadley</td><td>Added lc81 resolution - remove mustUnderstand attributes from examples</td></tr><tr><td>2005-05-18 @ 19:35</td><td>mhadley</td><td>Added lc51 resolution - reordered property list to match order in core</td></tr><tr><td>2005-05-18 @ 19:22</td><td>mhadley</td><td>Added lc47 resolution - fixed URL in WSDL 2.0 biblio entry</td></tr><tr><td>2005-05-18 @ 18:58</td><td>mhadley</td><td>Added lc97 resolution - Endpoint Reference to endpoint reference</td></tr><tr><td>2005-05-18 @ 18:56</td><td>mhadley</td><td>Added lc95 resolution - added WSDL 1.1 citation to introduction</td></tr><tr><td>2005-05-1 @ 18:51</td><td>mhadley</td><td>Added lc94 resolution - changed element to Element Information Item</td></tr><tr><td>2005-05-18 @ 18:48</td><td>mhadley</td><td>Added lc93 resolution - added ref to soap binding document prior to soap example in introduction</td></tr><tr><td>2005-05-18 @ 18:44</td><td>mhadley</td><td>Added lc92 resolution - clarified document being referenced in introduction</td></tr><tr><td>2005-05-18 @ 18:40</td><td>mhadley</td><td>Added lc80 resolution - made abstract properties into a separate list</td></tr><tr><td>2005-05-18 @ 18:34</td><td>mhadley</td><td>Added lc74 resolution - added suggested security consideration</td></tr><tr><td>2005-05-18 @ 18:24</td><td>mhadley</td><td>Added lc63 resolution - editorial fixes to security section</td></tr><tr><td>2005-05-18 @ 18:19</td><td>mhadley</td><td>Added lc44 resolution - changed and to or in security section</td></tr><tr><td>2005-05-18 @ 18:17</td><td>mhadley</td><td>Added lc43 resolution - added ref to SOAP 1.1</td></tr><tr><td>2005-05-18@ 18:12</td><td>mhadley</td><td>Added lc42 resolution - reordered infoset representation to match order of abstract properties</td></tr><tr><td>2005-05-18 @ 18:03</td><td>mhadley</td><td>Added lc67 resolution - made namespace uri a link</td></tr><tr><td>2005-05-18 @ 17:58</td><td>mhadley</td><td>Added lc64 resolution - numerous editorial fixes</td></tr><tr><td>2005-05-16 @ 20:28</td><td>mgudgin</td><td>Fixed mismatched endtag in Section 3.1</td></tr><tr><td>2005-05-16 @ 20:16</td><td>mgudgin</td><td>Fixed reference to RFC3987 to match format of other biblio entries</td></tr><tr><td>2005-04-22 @ 18:26</td><td>mhadley</td><td>Added resolution to lc22 - clarified ignore rule for extension attributes.</td></tr><tr><td>2005-04-22 @ 18:24</td><td>mhadley</td><td>Added resolution to lc21 - removed HTTP specific restriction on use of anonymous URI in [destination] for replies only.</td></tr><tr><td>2005-04-22 @ 18:18</td><td>mhadley</td><td>Added resolution to lc19 - clarified that [destination] value comparison isout of scope except for using simple string comparison to determine whether the anonymous destination is being used.</td></tr><tr><td>2005-04-22 @ 18:12</td><td>mhadley</td><td>Added resolution to lc18 - simplified description of wsa:To and wsa:Action elements</td></tr><tr><td>2005-04-22 @ 18:04</td><td>mhadley</td><td>Added resolution to lc17 - clarified that anonymous destination URI is not just for use in replies</td></tr><tr><td>2005-04-22 @ 18:01</td><td>mhadley</td><td>Added resolution to lc16 and lc54 - removed suggestion that required was required to use [destination] and [action] properties for dispatch</td></tr><tr><td>2005-04-22 @ 17:55</td><td>mhadley</td><td>Added resolution to lc15 - clarified cardinality of [relationship] properties using predefined reply URI</td></tr><tr><td>2005-04-22 @ 17:50</td><td>mhadley</td><td>Added resolution to lc14 - clarified reply IRI targetting</td></tr><tr><td>2005-04-22 @ 17:41</td><td>mhadley</td><td>Added resolution to lc13 - clarified wording in  descriptio of metadata</td></tr><tr><td>2005-04-22 @ 17:38</td><td>mhadley</td><td>Added resolution to lc12 - removed data encoding from description of reference parameters</td></tr><tr><td>2005-04-22 @ 17:30</td><td>mhadley</td><td>Added resolution to lc10 and lc11 - clarified types and opacity of reference parameters</td></tr><tr><td>2005-04-22 @ 17:25</td><td>mhadley</td><td>Added resolution to lc9 - changed IRI to absolute IRI where appropriate</td></tr><tr><td>2005-04-22 @ 16:16</td><td>mhadley</td><td>Added resolution to lc8 - changed IRI to URI where used to refer to IRIs in the specification that are actually URIs</td></tr><tr><td>2005-04-22 @ 15:49</td><td>mhadley</td><td>Added resolution to lc7 - fixed editorial nits</td></tr><tr><td>2005-04-22 @ 15:32</td><td>mhadley</td><td>Added resolution to lc3 - removed single extensibility point from infoset representation to avoid impression that other extenisibility points are not also valid</td></tr><tr><td>2005-04-22 @ 15:06</td><td>mhadley</td><td>Added resolutin to lc2 - assorted editorial changes</td></tr></table>
      </div>
      <div class="div2">
          
! <h3><a name="N67131"></a>B.2 Changes Since Second Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-03-30 @ 21:02</td><td>plehegar</td><td>Removed some extra blanks
  Added the note from David Hull at
***************
*** 936,945 ****
          <div class="div2">
                  
! <h3><a name="N67110"></a>B.3 Changes Since First Working Draft</h3>
                  <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-23 @ 21:13</td><td>mgudgin</td><td>Incorporated resolution of issue i014; edits to Section 2.3</td></tr><tr><td>2005-01-23 @ 20:52</td><td>mgudgin</td><td>Incorporated resolution of issue i006; made wsa:To optional</td></tr><tr><td>2005-01-23 @ 19:32</td><td>mgudgin</td><td>Incorporated resolution of Issue i001 by removing Reference Properties</td></tr><tr><td>2005-01-17 @ 02:13</td><td>mgudgin</td><td>Incorporated Paco's proposal for resolving Issue 038</td></tr><tr><td>2005-01-16 @ 22:40</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-17 @ 16:08</td><td>mhadley</td><td>Improved readability of introduction</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley/td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
              </div>
              <div class="div2">
                  
! <h3><a name="N67120"></a>B.4 Changes Since Submission</h3>
                  <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2004-11-23 @ 21:38</td><td>mhadley</td><td>Updated titles of examples. Fixed table formatting and references. Replaced uuid URIs with http URIs in examples. Added document status.</td></tr><tr><td>2004-11-22 @ 15:40</td><td>mhadley</td><td>Removed reference to WS-Policy</td></tr><tr><td>2004-11-15 @ 19:43</td><td>mhadley</td><td>Fixed some inter and intra spec references.</td></tr><tr><td>2004-11-12 @ 21:19</td><td>mgudgin</td><td>Removed TBD sections</td></tr><tr><td>2004-11-11 @ 18:31</td><td>mgudgin</td><td>
  Added some TBD sections</td></tr><tr><td>2004-11-07 @ 02:03</td><td>mhadley</td><td>Second more detailed run through to separate core, SOAP and WSDL document contents. Removed dependency on WS-Policy. Removed references to WS-Trust and WS-SecurityPolicy</td></tr><tr><td>2004-11-02 @ 22:25</td><td>mhadley</td><td>Removed static change log and added dynamically generated change log from cvs.</td></tr><tr><td>2004-10-28 @ 17:05</td><td>mhadley</td><td>Initial cut of separating specification into core, soap and wsdl</td></tr></table>
--- 942,951 ----
          <div class="div2">
                  
! <h3><a name="N67141"></a>B.3 Changes Since First Working Draft</h3>
                  <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-23 @ 21:13</td><td>mgudgin</td><td>Incorporated resolution of issue i014; edits to Section 2.3</td></tr><tr><td>2005-01-23 @ 20:52</td><td>mgudgin</td><td>Incorporated resolution of issue i006; made wsa:To optional</td></tr><tr><td>2005-01-23 @ 19:32</td><td>mgudgin</td><td>Incorporated resolution of Issue i001 by removing Reference Properties</td></tr><tr><td>2005-01-17 @ 02:13</td><td>mgudgin</td><td>Incorporated Paco's proposal for resolving Issue 038</td></tr><tr><td>2005-01-16 @ 22:40</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-17 @ 16:08</td><td>mhadley</td><td>Improved readability of introduction</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley/td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
              </div>
              <div class="div2">
                  
! <h3><a name="N67151"></a>B.4 Changes Since Submission</h3>
                  <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2004-11-23 @ 21:38</td><td>mhadley</td><td>Updated titles of examples. Fixed table formatting and references. Replaced uuid URIs with http URIs in examples. Added document status.</td></tr><tr><td>2004-11-22 @ 15:40</td><td>mhadley</td><td>Removed reference to WS-Policy</td></tr><tr><td>2004-11-15 @ 19:43</td><td>mhadley</td><td>Fixed some inter and intra spec references.</td></tr><tr><td>2004-11-12 @ 21:19</td><td>mgudgin</td><td>Removed TBD sections</td></tr><tr><td>2004-11-11 @ 18:31</td><td>mgudgin</td><td>
  Added some TBD sections</td></tr><tr><td>2004-11-07 @ 02:03</td><td>mhadley</td><td>Second more detailed run through to separate core, SOAP and WSDL document contents. Removed dependency on WS-Policy. Removed references to WS-Trust and WS-SecurityPolicy</td></tr><tr><td>2004-11-02 @ 22:25</td><td>mhadley</td><td>Removed static change log and added dynamically generated change log from cvs.</td></tr><tr><td>2004-10-28 @ 17:05</td><td>mhadley</td><td>Initial cut of separating specification into core, soap and wsdl</td></tr></table>

Index: ws-addr-soap.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.html,v
retrieving revision 1.32
retrieving revision 1.33
diff -C2 -d -r1.32 -r1.33
*** ws-addr-soap.html	25 May 2005 21:40:40 -0000	1.32
--- ws-addr-soap.html	2 Jun 2005 20:04:19 -0000	1.33
***************
*** 67,72 ****
          no official standing.</strong></p><p></p></div>
    <hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#intro"> Introduction</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#notation"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#namespaces"> Namespaces</a><br>2. <a href="#s12feature">SOAP 1.2 Addressing 1.0 Feature</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#s12featurename">Feature Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#s12featuredesc">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#s12featureprops">Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#s12featureinteractions">Interactions with Other SOAP Features</a><br>3. <a href="#s12module">SOAP 1.2 Addressing 1.0 Module</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#s12modulename">Module Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#s12moduledesc">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#additionalinfoset">Additional Infoset Items</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#bindrefp">Binding Message Addressing Properies</a><br>4. <a href="#s11ext">SOAP 1.1 Addressing 1.0 Extension</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#s11extname">Extension Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#s11extdesc">Description</a><br>5. <a href="#faults">Faults</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#invalidmapfault"> Invalid Addressing Header</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#missingmapfault"> Message Addressing Header Required</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#destinationfault"> Destination Unreachable</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#actionfault"> Action Not Supported</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#unavailablefault"> Endpoint Unavailable</a><br>6. <a href="#securityconsiderations">Security Considerations</a><br>&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#intseccons">Additional Considerations for SOAP Intermediaries</a><br>7. <a href="#references"> References</a><br></p>
! <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N66932">Changes Since Last Call Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N66942">Changes Since Second Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#N66952">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#N66962">Changes Since Submission</a><br></p></div><hr><div class="body">
      <div class="div1">
        
--- 67,72 ----
          no official standing.</strong></p><p></p></div>
    <hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#intro"> Introduction</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#notation"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#namespaces"> Namespaces</a><br>2. <a href="#s12feature">SOAP 1.2 Addressing 1.0 Feature</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#s12featurename">Feature Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#s12featuredesc">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#s12featureprops">Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#s12featureinteractions">Interactions with Other SOAP Features</a><br>3. <a href="#s12module">SOAP 1.2 Addressing 1.0 Module</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#s12modulename">Module Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#s12moduledesc">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#additionalinfoset">Additional Infoset Items</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#bindrefp">Binding Message Addressing Properies</a><br>4. <a href="#s11ext">SOAP 1.1 Addressing 1.0 Extension</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#s11extname">Extension Name</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#s11extdesc">Description</a><br>5. <a href="#faults">Faults</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#invalidmapfault"> Invalid Addressing Header</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#missingmapfault"> Message Addressing Header Required</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#destinationfault"> Destination Unreachable</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#actionfault"> Action Not Supported</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#unavailablefault"> Endpoint Unavailable</a><br>6. <a href="#securityconsiderations">Security Considerations</a><br>&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#intseccons">Additional Considerations for SOAP Intermediaries</a><br>7. <a href="#conformance">Conformance</a><br>8. <a href="#references"> References</a><br></p>
! <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N66972">Changes Since Last Call Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N66982">Changes Since Second Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#N66992">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#N67002">Changes Since Submission</a><br></p></div><hr><div class="body">
      <div class="div1">
        
***************
*** 287,294 ****
        <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 <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>. To ensure interoperability with
!         a broad range of devices, all conformant implementations that
!         include support for SOAP 1.2 MUST support the SOAP 1.2
!         Addressing 1.0 Module.</p>
        <div class="div2">
          
--- 287,291 ----
        <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 <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>.</p>
        <div class="div2">
          
***************
*** 341,345 ****
              <dd>
                <p>This REQUIRED attribute (of type xs:boolean) signifies
!                 whether the message information header is a reference
                  parameter, see section <a href="#bindrefp"><b>3.4 Binding Message Addressing Properties</b></a> for
                  more details on its use.</p>
--- 338,342 ----
              <dd>
                <p>This REQUIRED attribute (of type xs:boolean) signifies
!                 whether the message addressing header is a reference
                  parameter, see section <a href="#bindrefp"><b>3.4 Binding Message Addressing Properties</b></a> for
                  more details on its use.</p>
***************
*** 364,367 ****
--- 361,372 ----
                [in-scope namespaces]) is added as a SOAP header block in
                the new message.</p>
+             <div class="note"><p class="prefix"><b>Note:</b></p><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<cite><a href="#WS-Security">WS-Security</a></cite> 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></div>
            </li>
            <li>
***************
*** 445,452 ****
        <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 <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>. To ensure
!         interoperability with a broad range of devices, all conformant
!         implementations that include support for SOAP 1.1 MUST support
!         the SOAP 1.1 Addressing 1.0 Extension. This SOAP 1.1 extension
          is provided for backwards compatibility only.</p>
        <div class="div2">
--- 450,454 ----
        <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 <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>. This SOAP 1.1 extension
          is provided for backwards compatibility only.</p>
        <div class="div2">
***************
*** 610,623 ****
          
  <h3><a name="invalidmapfault"></a>5.1  Invalid Addressing Header</h3>
!         <p>A header representing a WS-Addressing 1.0 Message Addressing Property
! cannot be processed.</p>
!         <p> [Code] S:Sender</p>
!         <p> [Subcode] wsa:InvalidAddressingHeader</p>
!         <p> [Reason] A header representing a Message Addressing Property is not valid and the
!           message 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> [Detail] [Invalid header QName]</p>
        </div>
        
--- 612,625 ----
          
  <h3><a name="invalidmapfault"></a>5.1  Invalid Addressing Header</h3>
!         <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> [Detail] a QName representing the name of the root element of the invalid header block</p>
        </div>
        
***************
*** 626,634 ****
  <h3><a name="missingmapfault"></a>5.2  Message Addressing Header Required</h3>
          <p>A required header representing a Message Addressing Property is absent.</p>
!         <p> [Code] S:Sender</p>
!         <p> [Subcode] wsa:MessageAddressingHeaderRequired</p>
!         <p> [Reason] A required header  representing a Message Addressing Property is not
!           present.</p>
!         <p> [Detail] [Missing header QName]</p>
        </div>
  
--- 628,636 ----
  <h3><a name="missingmapfault"></a>5.2  Message Addressing Header Required</h3>
          <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> [Detail] a QName representing the name of the missing header element</p>
        </div>
  
***************
*** 638,645 ****
          <p>No endpoint can be found capable of acting in the role of the
            [destination] property.</p>
!         <p> [Code] S:Sender</p>
!         <p> [Subcode] wsa:DestinationUnreachable</p>
!         <p> [Reason] No route can be determined to reach [destination].</p>
!         <p> [Detail] empty</p>
        </div>
        <div class="div2">
--- 640,647 ----
          <p>No endpoint can be found capable of acting in the role of the
            [destination] property.</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> [Detail] (empty)</p>
        </div>
        <div class="div2">
***************
*** 648,656 ****
          <p>The [action] property in the message is not supported at this
            endpoint.</p>
!         <p>The contents of this fault are as follows:</p>
!         <p> [Code] S:Sender</p>
!         <p> [Subcode] wsa:ActionNotSupported</p>
!         <p> [Reason] The [action] cannot be processed at the receiver.</p>
!         <p> [Detail] [action]</p>
        </div>
        <div class="div2">
--- 650,657 ----
          <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> [Detail] the value of the wsa:Action header block</p>
        </div>
        <div class="div2">
***************
*** 662,673 ****
            the detail. The source SHOULD NOT retransmit the message until
            this duration has passed.</p>
!         <p> [Code] S:Receiver</p>
!         <p> [Subcode] wsa:EndpointUnavailable</p>
!         <p> [Reason] The endpoint is unable to process the message at
!           this time.</p>
!         <p> [Detail] &lt;wsa:RetryAfter
!           ...&gt;[xs:nonNegativeInteger]&lt;/wsa:RetryAfter&gt;</p>
!         <p> The following describes the attributes and elements listed
!           above:</p>
          <dl>
            
--- 663,672 ----
            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> [Detail]  a &lt;wsa:RetryAfter&gt; element</p>
!         <p> The following describes the &lt;wsa:RetryAfter&gt; element:</p>
          <dl>
            
***************
*** 705,709 ****
          additional security and sanity checks to prevent unintended
          actions.</p>
!       <div class="div2">
          
  <h3><a name="intseccons"></a>6.1 Additional Considerations for SOAP Intermediaries</h3>
--- 704,708 ----
          additional security and sanity checks to prevent unintended
          actions.</p>
!      <div class="div2">
          
  <h3><a name="intseccons"></a>6.1 Additional Considerations for SOAP Intermediaries</h3>
***************
*** 719,725 ****
        </div>
      </div>
      <div class="div1">
        
! <h2><a name="references"></a>7.  References</h2>
        <dl>
          <dt class="label"><a name="WSADDR-CORE"></a>[WS-Addressing-Core] </dt><dd>
--- 718,752 ----
        </div>
      </div>
+     
      <div class="div1">
        
! <h2><a name="conformance"></a>7. Conformance</h2>
!       
!       <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[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>] 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[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>]
!        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[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>].</p>
!       
!       <div class="note"><p class="prefix"><b>Note:</b></p><p>Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] defines additional conformance
!         requirements for the description of an endpoint.</p></div>
!       
!       <div class="note"><p class="prefix"><b>Note:</b></p><p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p></div>
!     </div>
!     
!     <div class="div1">
!       
! <h2><a name="references"></a>8.  References</h2>
        <dl>
          <dt class="label"><a name="WSADDR-CORE"></a>[WS-Addressing-Core] </dt><dd>
***************
*** 829,848 ****
      <div class="div2">
        
! <h3><a name="N66932"></a>B.1 Changes Since Last Call Working Draft</h3>
!       <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-05-25 @ 21:20</td><td>mhadley</td><td>Added resolution to issue lc105 - added requirement that no additional %-escaping be peformed on IRI type message addressing properties when serialized</td></tr><tr><td>2005-05-25 @ 21:07</td><td>mhadley</td><td>Added resolution to issue lc73 - clarrified meaning of omitting RetryAfter</td></tr><tr><td>2005-05-25 @ 21:03</td><td>mhadley</td><td>Added resolution to issue lc57 - added normative text describing fault binding</td></tr><tr><td>2005-05-25 @ 20:20</td><td>mhadley</td><td>Added resolution to issue lc66 - made it clear that type often refers to the content of elements rather than the element as a whole which can often also include attributes</td></tr><tr><td>2005-05-18 @ 19:44</td><td>mhadley</td><td>Added lc59 resolution - added missing namespace declaration in example</td></tr><tr><td>2005-05-18 @ 19:42</td><td>mhadley</td><td>Added lc53 resolution - expanded MAP tomessage addressing property and fixed editorial glitch</td></tr><tr><td>2005-05-18 @ 19:37</td><td>mhadley</td><td>Added lc52 resolution - MessageId to MessageID</td></tr><tr><td>2005-05-18 @ 19:35</td><td>mhadley</td><td>Added lc51 resolution - reordered property list to match order in core</td></tr><tr><td>2005-05-18 @ 19:22</td><td>mhadley</td><td>Added lc47 resolution - fixed URL in WSDL 2.0 biblio entry</td></tr><tr><td>2005-05-18 @ 19:16</td><td>mhadley</td><td>Added lc38 resolution - nonNegativeInteger to unsignedLong for RetryAfter</td></tr><tr><td>2005-05-18 @ 18:03</td><td>mhadley</td><td>Added lc67 resolution - made namespace uri a link</td></tr><tr><td>2005-05-18 @ 17:58</td><td>mhadley</td><td>Added lc64 resolution - numerous editorial fixes</td></tr><tr><td>2005-05-16 @ 20:20</td><td>mgudgin</td><td>Fixed reference to RFC3987 to match format of other biblio entries</td></tr><tr><td>2005-05-13 @ 18:56</td><td>mhadley</td><td>Added resolutions to issues 33 and 34: editorial corrections to bindin MAP to SOAP headers and new rule against multiple headers targetted at same recipient</td></tr><tr><td>2005-05-05 @ 18:10</td><td>mhadley</td><td>Added issue 28 resolution: fixed use of mixed notation and indirect terminology for MAPs in Binding Message Addressing Properties section</td></tr><tr><td>2005-05-05 @ 17:39</td><td>mhadley</td><td>Added resolution to issues 26 and 36: Clarified use of invalid map fault for mismatched wsa:Action and SOAPAction; renamed and clarified invalid map and missing map faults.</td></tr><tr><td>2005-04-22 @ 20:01</td><td>mhadley</td><td>Added resolution to lc32 - added note warning of infoset changes due to IsReferenceParameter addition when binding [reference parameter] to SOAP.</td></tr><tr><td>2005-04-22 @ 19:51</td><td>mhadley</td><td>Added resolution to lc31 - clarified what to do if a reference parameter already has an IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:46</td><td>mhadley</td><td>Added resolution to lc30 - added new section for definitio of IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:26</td><td>mhadley</td><td>Added resolution to lc29 - capitalized first character of IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:07</td><td>mhadley</td><td>Added resolution to lc27 - clarified confusing use of XML infoset terminology in XML representation of properties.</td></tr><tr><td>2005-04-22 @ 18:58</td><td>mhadley</td><td>Added resolution to lc24 - editorial nits.</td></tr><tr><td>2005-04-22 @ 18:49</td><td>mhadley</td><td>Added resolution to lc23 - changed IRI to URI for constant values that are URIs.</td></tr><tr><td>2005-04-22 @ 15:27</td><td>mhadley</td><td>Added resolution to lc1 - clarified impact of omitting [message id], [reply endpoint] and [fault endpoint] on fault message generation</td></tr><tr><td>2005-04-12 @ 13:17</td><td>mhadley</td><td>Fixed closing element in example</td></tr></table>
      </div>
      <div class="div2">
          
! <h3><a name="N66942"></a>B.2 Changes Since Second Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-03-21 @ 23:15</td><td>mgudgin</td><td>Added sentence about SOAP 1.1 to section 4</td></tr><tr><td>2005-03-18 @ 23:21</td><td>mgudgin</td><td>s/Addresssing/Addressing</td></tr><tr><td>2005-03-10 @ 03:40</td><td>mhadley</td><td>Incorporated additional editorial fixes from J. Marsh.</td></tr><tr><td>2005-03-10 @ 03:16</td><td>mhadley</td><td>Incorporated additional issue resolution text for issues 7 and 44 from H. Haas.</td></tr><tr><td>2005-03-10 @ 02:06</td><td>mhadley</td><td>Incorporated editorial fixes from J. Marsh.</td></tr><tr><td>2005-03-09 @ 07:11</td><td>mhadley</td><td>Fixed example that didn't reflect the chnage from wsa:Type to wsa:isReferenceParameter</td></tr><tr><td>2005-03-08 @ 20:50</td><td>mhadley</td><td>Added resolution to issue 53 (schema tweaks)</td></tr><tr><td>2005-03-02 @ 21:18</td><td>mhadley</td><td>Added resolution to issue 4</td></tr><tr><td>2005-03-02 @ 20:30</td><td>mhadley</td><tdAdded resolution to issue 7</td></tr><tr><td>2005-03-02 @ 19:36</td><td>mhadley</td><td>Added resolution to issues 22 and 51/</td></tr><tr><td>2005-02-28 @ 22:08</td><td>mhadley</td><td>Added resolution to issues 24 and 26</td></tr><tr><td>2005-02-27 @ 19:42</td><td>mhadley</td><td>Changed URI to IRI where appropriate.</td></tr><tr><td>2005-02-17 @ 15:37</td><td>mhadley</td><td>Added issue 47 resolution</td></tr><tr><td>2005-02-15 @ 22:06</td><td>mhadley</td><td>Fixed some references to message information headers to message information properties</td></tr></table>
        </div>
        <div class="div2">
          
! <h3><a name="N66952"></a>B.3 Changes Since First Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-24 @ 20:22</td><td>mgudgin</td><td>Removed spurious reference to section 3.3.2 from Section 3</td></tr><tr><td>2005-01-23 @ 21:11</td><td>mgudgin</td><td>Incorporated resolution of issue i008; added wsa:Type attribute to reference parameters</td></tr><tr><td>2005-01-20 @ 13:10</td><td>mgudgin</td><td>Removed text from first paragraph of section 3 per resolution of issue i040</td></tr><tr><td>2005-01-16 @ 22:41</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10<td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
        </div>
        <div class="div2">
          
! <h3><a name="N66962"></a>B.4 Changes Since Submission</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2004-11-24 @ 15:32</td><td>mhadley</td><td>Added note that addressing is backwards compatible with SOAP 1.1</td></tr><tr><td>2004-11-23 @ 21:38</td><td>mhadley</td><td>Updated titles of examples. Fixed table formatting and references. Replaced uuid URIs with http URIs in examples. Added document status.</td></tr><tr><td>2004-11-07 @ 02:03</td><td>mhadley</td><td>Second more detailed run through to separate core, SOAP and WSDL document contents. Removed dependency on WS-Policy. Removed references to WS-Trust and WS-SecurityPolicy</td></tr><tr><td>2004-11-02 @ 22:25</td><td>mhadley</td><td>Removed static change log and added dynamically generated change log from cvs.</td></tr><tr><td>2004-10-28 @ 17:05</td><td>mhadley</td><td>Initial cut of separating specification into core, soap and wsdl</td></tr></table>
        </div>
--- 856,875 ----
      <div class="div2">
        
! <h3><a name="N66972"></a>B.1 Changes Since Last Call Working Draft</h3>
!       <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-06-02 @ 19:45</td><td>mhadley</td><td>Added resolution to issue lc62 - added note confirming that endpoints may consume and respond to messages that do not use any WS-Addr headers</td></tr><tr><td>2005-06-02 @ 19:12</td><td>mhadley</td><td>Added resolution to issue lc6 and lc35 - added new conformance section, moved conformance text from module and extension sections</td></tr><tr><td>2005-06-02 @ 18:56</td><td>mhadley</td><td>Added resolution to issue lc73 - added note warning about use of reference parameters conflicting with normal message semantics</td></tr><tr><td>2005-06-02 @ 18:15</td><td>mhadley</td><td>Added resolution to issue lc37 - added DOS attack security considerations</td></tr><tr><td>2005-06-02 @ 17:43</td><td>mhadley</td><td>Added clarifications of fault property values</td></tr><tr><td>2005-05-25 @ 21:40</td><td>mhadley</td><td>Added new section in changelog to account for previous draft publicaion</td></tr><tr><td>2005-05-25 @ 21:20</td><td>mhadley</td><td>Added resolution to issue lc105 - added requirement that no additional %-escaping be peformed on IRI type message addressing properties when serialized</td></tr><tr><td>2005-05-25 @ 21:07</td><td>mhadley</td><td>Added resolution to issue lc73 - clarrified meaning of omitting RetryAfter</td></tr><tr><td>2005-05-25 @ 21:03</td><td>mhadley</td><td>Added resolution to issue lc57 - added normative text describing fault binding</td></tr><tr><td>2005-05-25 @ 20:20</td><td>mhadley</td><td>Added resolution to issue lc66 - made it clear that type often refers to the content of elements rather than the element as a whole which can often also include attributes</td></tr><tr><td>2005-05-18 @ 19:44</td><td>mhadley</td><td>Added lc59 resolution - added missing namespace declaration in example</td></tr><tr><td>2005-05-18 @ 19:42</td><td>mhadley</td><td>Added lc53 resolution - expanded MAP to message addressing property and fixed editorial glitch</td></tr><tr><d>2005-05-18 @ 19:37</td><td>mhadley</td><td>Added lc52 resolution - MessageId to MessageID</td></tr><tr><td>2005-05-18 @ 19:35</td><td>mhadley</td><td>Added lc51 resolution - reordered property list to match order in core</td></tr><tr><td>2005-05-18 @ 19:22</td><td>mhadley</td><td>Added lc47 resolution - fixed URL in WSDL 2.0 biblio entry</td></tr><tr><td>2005-05-18 @ 19:16</td><td>mhadley</td><td>Added lc38 resolution - nonNegativeInteger to unsignedLong for RetryAfter</td></tr><tr><td>2005-05-18 @ 18:03</td><td>mhadley</td><td>Added lc67 resolution - made namespace uri a link</td></tr><tr><td>2005-05-18 @ 17:58</td><td>mhadley</td><td>Added lc64 resolution - numerous editorial fixes</td></tr><tr><td>2005-05-16 @ 20:20</td><td>mgudgin</td><td>Fixed reference to RFC3987 to match format of other biblio entries</td></tr><tr><td>2005-05-13 @ 18:56</td><td>mhadley</td><td>Added resolutions to issues 33 and 34: editorial corrections to binding MAP to SOAP headers and new rule against multiple headers targetted t same recipient</td></tr><tr><td>2005-05-05 @ 18:10</td><td>mhadley</td><td>Added issue 28 resolution: fixed use of mixed notation and indirect terminology for MAPs in Binding Message Addressing Properties section</td></tr><tr><td>2005-05-05 @ 17:39</td><td>mhadley</td><td>Added resolution to issues 26 and 36: Clarified use of invalid map fault for mismatched wsa:Action and SOAPAction; renamed and clarified invalid map and missing map faults.</td></tr><tr><td>2005-04-22 @ 20:01</td><td>mhadley</td><td>Added resolution to lc32 - added note warning of infoset changes due to IsReferenceParameter addition when binding [reference parameter] to SOAP.</td></tr><tr><td>2005-04-22 @ 19:51</td><td>mhadley</td><td>Added resolution to lc31 - clarified what to do if a reference parameter already has an IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:46</td><td>mhadley</td><td>Added resolution to lc30 - added new section for definition of IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:6</td><td>mhadley</td><td>Added resolution to lc29 - capitalized first character of IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:07</td><td>mhadley</td><td>Added resolution to lc27 - clarified confusing use of XML infoset terminology in XML representation of properties.</td></tr><tr><td>2005-04-22 @ 18:58</td><td>mhadley</td><td>Added resolution to lc24 - editorial nits.</td></tr><tr><td>2005-04-22 @ 18:49</td><td>mhadley</td><td>Added resolution to lc23 - changed IRI to URI for constant values that are URIs.</td></tr><tr><td>2005-04-22 @ 15:27</td><td>mhadley</td><td>Added resolution to lc1 - clarified impact of omitting [message id], [reply endpoint] and [fault endpoint] on fault message generation</td></tr><tr><td>2005-04-12 @ 13:17</td><td>mhadley</td><td>Fixed closing element in example</td></tr></table>
      </div>
      <div class="div2">
          
! <h3><a name="N66982"></a>B.2 Changes Since Second Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-03-21 @ 23:15</td><td>mgudgin</td><td>Added sentence about SOAP 1.1 to section 4</td></tr><tr><td>2005-03-18 @ 23:21</td><td>mgudgin</td><td>s/Addresssing/Addressing</td></tr><tr><td>2005-03-10 @ 03:40</td><td>mhadley</td><td>Incorporated additional editorial fixes from J. Marsh.</td></tr><tr><td>2005-03-10 @ 03:16</td><td>mhadley</td><td>Incorporated additional issue resolution text for issues 7 and 44 from H. Haas.</td></tr><tr><td>2005-03-10 @ 02:06</td><td>mhadley</td><td>Incorporated editorial fixes from J. Marsh.</td></tr><tr><td>2005-03-09 @ 07:11</td><td>mhadley</td><td>Fixed example that didn't reflect the chnage from wsa:Type to wsa:isReferenceParameter</td></tr><tr><td>2005-03-08 @ 20:50</td><td>mhadley</td><td>Added resolution to issue 53 (schema tweaks)</td></tr><tr><td>2005-03-02 @ 21:18</td><td>mhadley</td><td>Added resolution to issue 4</td></tr><tr><td>2005-03-02 @ 20:30</td><td>mhadley</td><tdAdded resolution to issue 7</td></tr><tr><td>2005-03-02 @ 19:36</td><td>mhadley</td><td>Added resolution to issues 22 and 51/</td></tr><tr><td>2005-02-28 @ 22:08</td><td>mhadley</td><td>Added resolution to issues 24 and 26</td></tr><tr><td>2005-02-27 @ 19:42</td><td>mhadley</td><td>Changed URI to IRI where appropriate.</td></tr><tr><td>2005-02-17 @ 15:37</td><td>mhadley</td><td>Added issue 47 resolution</td></tr><tr><td>2005-02-15 @ 22:06</td><td>mhadley</td><td>Fixed some references to message information headers to message information properties</td></tr></table>
        </div>
        <div class="div2">
          
! <h3><a name="N66992"></a>B.3 Changes Since First Working Draft</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-24 @ 20:22</td><td>mgudgin</td><td>Removed spurious reference to section 3.3.2 from Section 3</td></tr><tr><td>2005-01-23 @ 21:11</td><td>mgudgin</td><td>Incorporated resolution of issue i008; added wsa:Type attribute to reference parameters</td></tr><tr><td>2005-01-20 @ 13:10</td><td>mgudgin</td><td>Removed text from first paragraph of section 3 per resolution of issue i040</td></tr><tr><td>2005-01-16 @ 22:41</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10<td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
        </div>
        <div class="div2">
          
! <h3><a name="N67002"></a>B.4 Changes Since Submission</h3>
          <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2004-11-24 @ 15:32</td><td>mhadley</td><td>Added note that addressing is backwards compatible with SOAP 1.1</td></tr><tr><td>2004-11-23 @ 21:38</td><td>mhadley</td><td>Updated titles of examples. Fixed table formatting and references. Replaced uuid URIs with http URIs in examples. Added document status.</td></tr><tr><td>2004-11-07 @ 02:03</td><td>mhadley</td><td>Second more detailed run through to separate core, SOAP and WSDL document contents. Removed dependency on WS-Policy. Removed references to WS-Trust and WS-SecurityPolicy</td></tr><tr><td>2004-11-02 @ 22:25</td><td>mhadley</td><td>Removed static change log and added dynamically generated change log from cvs.</td></tr><tr><td>2004-10-28 @ 17:05</td><td>mhadley</td><td>Initial cut of separating specification into core, soap and wsdl</td></tr></table>
        </div>

Received on Thursday, 2 June 2005 20:04:23 UTC