- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 20 Jul 2005 18:32:30 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv26436
Modified Files:
ws-addr-core.html ws-addr-soap.html
Log Message:
Sync with XML
Index: ws-addr-core.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.html,v
retrieving revision 1.33
retrieving revision 1.34
diff -C2 -d -r1.33 -r1.34
*** ws-addr-core.html 12 Jul 2005 18:48:42 -0000 1.33
--- ws-addr-core.html 20 Jul 2005 18:32:28 -0000 1.34
***************
*** 70,75 ****
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="#tocRange">Introduction</a><br> 1.1 <a href="#notation">Notational Conventions</a><br> 1.2 <a href="#namespaces">Namespaces</a><br>2. <a href="#eprs">Endpoint References</a><br> 2.1 <a href="#eprinfomodel">Information Model for Endpoint References</a><br> 2.2 <a href="#eprinfoset">Endpoint Reference XML Infoset Representation</a><br> 2.3 <a href="#eprcomp">Endpoint Reference Comparison</a><br> 2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br> 2.5 <a href="#eprextensibility">Endpoint Reference Extensibility</a><br>3. <a href="#msgaddrprops">Message Addressing Properties</a><br> 3.1 <a href="#abstractmaps">Abstract Property Definitions</a><br> 3.2 <a href="#msgaddrpropsinfoset">XML Infoset Representation of MessageAddressing Properties</a><br> 3.2.1 <a href="#compiri">Comparing IRIs</a><br> 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> B.1 <a href="#N67285">Changes Since Last Call Working Draft</a><br> B.2 <a href="#N67295">Changes Since Second Working Draft</a><br> B.3 <a href="#N67305">Changes Since First Working Draft</a><br> B.4 <a href="#N67315">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
--- 70,75 ----
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="#tocRange">Introduction</a><br> 1.1 <a href="#notation">Notational Conventions</a><br> 1.2 <a href="#namespaces">Namespaces</a><br>2. <a href="#eprs">Endpoint References</a><br> 2.1 <a href="#eprinfomodel">Information Model for Endpoint References</a><br> 2.2 <a href="#eprinfoset">Endpoint Reference XML Infoset Representation</a><br> 2.3 <a href="#eprcomp">Endpoint Reference Comparison</a><br> 2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br> 2.5 <a href="#eprextensibility">Endpoint Reference Extensibility</a><br>3. <a href="#msgaddrprops">Message Addressing Properties</a><br> 3.1 <a href="#abstractmaps">Abstract Property Definitions</a><br> 3.2 <a href="#msgaddrpropsinfoset">XML Infoset Representation of MessageAddressing Properties</a><br> 3.2.1 <a href="#compiri">Comparing IRIs</a><br> 3.3 <a href="#formreplymsg">Formulating a Reply Message</a><br>4. <a href="#securityconsiderations">Security Considerations</a><br> 4.1 <a href="#N66948">Additional 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> B.1 <a href="#N67309">Changes Since Last Call Working Draft</a><br> B.2 <a href="#N67319">Changes Since Second Working Draft</a><br> B.3 <a href="#N67329">Changes Since First Working Draft</a><br> B.4 <a href="#N67339">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
***************
*** 136,140 ****
of {any} indicates the presence of an element wildcard
(<xs:any/>). The use of @{any} indicates the presence of an
! attribute wildcard (<xs:anyAttribute/>). In addition, where
pseudo-schemas are provided for a component, they use BNF-style conventions for
attributes and elements: "?" denotes optionality (i.e. zero or one occurrences),
--- 136,141 ----
of {any} indicates the presence of an element wildcard
(<xs:any/>). The use of @{any} indicates the presence of an
! attribute wildcard (<xs:anyAttribute/>).</p>
! <p>Where
pseudo-schemas are provided for a component, they use BNF-style conventions for
attributes and elements: "?" denotes optionality (i.e. zero or one occurrences),
***************
*** 144,148 ****
the normative schema. Elements with simple content are conventionally assigned a
value which corresponds to the type of their content, as defined in the
! normative schema.</p>
<p>When defining the cardinality of endpoint reference properties and message
addressing properties, this specification uses the following notation:
--- 145,150 ----
the normative schema. Elements with simple content are conventionally assigned a
value which corresponds to the type of their content, as defined in the
! normative schema. Pseudo schemas do not include extensibility points for
! brevity.</p>
<p>When defining the cardinality of endpoint reference properties and message
addressing properties, this specification uses the following notation:
***************
*** 218,222 ****
<h3><a name="eprinfomodel"></a>2.1 Information Model for Endpoint References</h3>
! <p>An endpoint reference consists of the following abstract properties:</p>
<dl>
--- 220,230 ----
<h3><a name="eprinfomodel"></a>2.1 Information Model for Endpoint References</h3>
! <p>An endpoint reference is a collection of abstract properties.
! This specification defines a core set of properties, but it is
! also possible for other specifications to extend these and/or add
! other properties. The semantics and XML Infoset representation
! for any such extension properties will be described in their defining
! specifications.
! An endpoint reference consists of the following abstract properties:</p>
<dl>
***************
*** 237,249 ****
"http://www.w3.org/@@@@/@@/addressing/anonymous"
</td>
! <td rowspan="1" colspan="1">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. This URI is used to allow such endpoints
! to send and receive messages. Messages sent to EPRs
! whose [address] is this value MUST rely on some out-of-band
! mechanism for delivery (e.g.
! using a pre-existing transport
! connection) from a prior interaction.</td>
</tr>
<tr>
--- 245,252 ----
"http://www.w3.org/@@@@/@@/addressing/anonymous"
</td>
! <td rowspan="1" colspan="1">Some endpoints cannot be located with a meaningful IRI;
! this URI is used to allow such endpoints to send and receive messages.
! The precise meaning of this URI is defined by the binding of
! Addressing to a specific protocol..</td>
</tr>
<tr>
***************
*** 253,257 ****
<td rowspan="1" colspan="1">Messages sent to EPRs whose [address] is this
value
! MUST be discarded (i.e. not sent). This URI
is
typically used in EPRs that designate a reply or fault
--- 256,260 ----
<td rowspan="1" colspan="1">Messages sent to EPRs whose [address] is this
value
! MUST be discarded (i.e. not sent). This URI
is
typically used in EPRs that designate a reply or fault
***************
*** 406,409 ****
--- 409,416 ----
</dl>
+ <div class="note"><p class="prefix"><b>Note:</b></p><p>Specifications which describe any extension elements or attributes
+ used to augment the above model will explain any effects those
+ extensions may have on the abstract properties. They may affect either
+ the core properties or extension properties as defined in <a href="#eprinfomodel"><b>2.1 Information Model for Endpoint References</b></a>.</p></div>
<p>The following shows an example endpoint reference. This element references the
the endpoint at the URI "http://example.com/fabrikam/acct".</p>
***************
*** 453,457 ****
extended endpoint reference is processed by software that understands the
extension(s). When designing endpoint reference extensions designers should
! consider whether they desire standard processing per this specification in cases
where their extension is not recognized or understood.</p>
</div>
--- 460,464 ----
extended endpoint reference is processed by software that understands the
extension(s). When designing endpoint reference extensions designers should
! consider that standard processing per this specification will prevail in cases
where their extension is not recognized or understood.</p>
</div>
***************
*** 462,475 ****
<p>This section defines the information model and syntax of message addressing
properties.</p>
- <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
- design</a>, some participants believe it is not adequately specified. Such
- feedback will help the Working Group determine whether it needs to re-examine
- this issue. </p>
- </div>
<p> Message addressing properties provide references for the endpoints involved in an
interaction. The use of these properties to support specific interactions is in
--- 469,472 ----
***************
*** 602,613 ****
properties defined in <a href="#abstractmaps"><b>3.1 Abstract Property Definitions</b></a>:</p>
<div class="exampleInner"><pre>
! <<b>wsa:To</b>><i>xs:anyURI</i></<b>wsa:To</b>>
! <<b>wsa:From</b>><i>wsa:EndpointReferenceType</i></<b>wsa:From</b>>
! <<b>wsa:ReplyTo</b>><i>wsa:EndpointReferenceType</i></<b>wsa:ReplyTo</b>>
! <<b>wsa:FaultTo</b>><i>wsa:EndpointReferenceType</i></<b>wsa:FaultTo</b>>
<<b>wsa:Action</b>><i>xs:anyURI</i></<b>wsa:Action</b>>
! <<b>wsa:MessageID</b>><i>xs:anyURI</i></<b>wsa:MessageID</b>>
! <<b>wsa:RelatesTo</b> RelationshipType="<i>xs:anyURI</i>"?><i>xs:anyURI</i></<b>wsa:RelatesTo</b>>
! <<b>wsa:ReferenceParameters</b>><i>xs:any</i>*</<b>wsa:ReferenceParameters</b>>
</pre></div>
<p>The following describes the attributes and elements listed in the schema overview
--- 599,610 ----
properties defined in <a href="#abstractmaps"><b>3.1 Abstract Property Definitions</b></a>:</p>
<div class="exampleInner"><pre>
! <<b>wsa:To</b>><i>xs:anyURI</i></<b>wsa:To</b>> ?
! <<b>wsa:From</b>><i>wsa:EndpointReferenceType</i></<b>wsa:From</b>> ?
! <<b>wsa:ReplyTo</b>><i>wsa:EndpointReferenceType</i></<b>wsa:ReplyTo</b>> ?
! <<b>wsa:FaultTo</b>><i>wsa:EndpointReferenceType</i></<b>wsa:FaultTo</b>> ?
<<b>wsa:Action</b>><i>xs:anyURI</i></<b>wsa:Action</b>>
! <<b>wsa:MessageID</b>><i>xs:anyURI</i></<b>wsa:MessageID</b>> ?
! <<b>wsa:RelatesTo</b> RelationshipType="<i>xs:anyURI</i>"?><i>xs:anyURI</i></<b>wsa:RelatesTo</b>> *
! <<b>wsa:ReferenceParameters</b>><i>xs:any</i>*</<b>wsa:ReferenceParameters</b>> ?
</pre></div>
<p>The following describes the attributes and elements listed in the schema overview
***************
*** 844,875 ****
</div>
</div>
<div class="div1">
<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 signature by a
! trusted party over the EPR, or an out-of-band means of establishing trust, to
! determine whether they should use a particular EPR.</p>
! <p>EPRs and message addressing properties SHOULD be integrity-protected to prevent
! tampering. Such optional integrity protection might be provided by the transport, a
! message level signature, or use of an XML digital signature within EPRs.</p>
! <p>To prevent information disclosure, EPR issuers SHOULD NOT put sensitive information
! into the [address] or [reference parameters] properties.</p>
! <p>Some processors may use message identifiers ([message id]) as part of a uniqueness
! metric in order to detect replays of messages. In this case, care should be taken to
! ensure that for purposes of replay detection, the message identifier is combined
! with other data, such as a timestamp, so that a legitimate retransmission of the
! message is not 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">
--- 841,904 ----
</div>
</div>
+
<div class="div1">
<h2><a name="securityconsiderations"></a>4. Security Considerations</h2>
!
! <p>Conformance to this specification does not require a message receiver to honor the
! WS-Addressing constructs within a message if the receiver is not satisfied that the
! message is safe to process.</p>
!
! <p>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.
! To an extent the content of such unsolicted messages can also be controlled using
! reference parameters supplied by the initial message sender. Because of these
! capabilities it is essential that communications using WS-Addressing are adequately
! secured and that a sufficient level of trust is established between the communicating
! parties before a receiver processes WS-Addressing constructs within a message. There
! are several aspects to securing a message: </p>
!
! <ol>
! <li><p>EPRs and message addressing properties should be integrity-protected to prevent
! tampering. Such integrity protection might be provided by the transport, a message
! level signature, or use of an XML digital signature within EPRs.</p></li>
! <li><p>Users of EPRs should validate the trustworthiness of an EPR before using it by
! considering the following aspects:</p>
! <ol>
! <li><p>whether the EPR was obtained from a trusted source</p></li>
! <li><p>whether the EPR was obtained from a source with authority to represent the [address] of that EPR</p></li>
! <li><p>whether the [address] of the EPR is a trusted destination</p></li>
! </ol>
! </li>
! </ol>
!
! <p>For example, the receiver of a message might rely on the presence of a verifiable signature
! by a trusted party over the message addressing properties to determine that the message
! originated from a trusted source and further require that the [reply endpoint] and
! [fault endpoint] are signed by a principle with authority to represent the [address] of
! those EPRs to ensure that unsolicted messages are not sent. Alternatively an out-of-band
! means of establishing trust might be used to determine whether a particular EPR is
! trustworthy.</p>
!
! <div class="div2">
!
! <h3><a name="N66948"></a>4.1 Additional Security Considerations</h3>
!
! <p>To prevent information disclosure, EPR issuers should not put sensitive information
! into the [address] or [reference parameters] properties unless it has been
! adequately protected against arbitrary
! disclosure.</p>
!
! <p>Some processors may use [message id] as part of a uniqueness metric in order to
! detect message replay. Care should be taken to ensure that, for purposes of
! replay detection, [message id] is composed from data, such as a timestamp,
! such that a legitimate retransmission of the message is not confused with a
! replay attack. It is also advisable to use a [message id] that is not
! predictable, to prevent attackers from constructing and sending an unsolicited
! reply to a message without having to see the actual message.</p>
! </div>
!
</div>
+
<div class="div1">
***************
*** 878,882 ****
<dt class="label"><a name="WSADDR-SOAP"></a>[WS-Addressing-SOAP] </dt><dd>
<cite><a href="ws-addr-soap.html">Web Services Addressing 1.0 - SOAP Binding</a></cite>, M. Gudgin, M. Hadley, Editors.</dd>
-
<dt class="label"><a name="WSADDR-WSDL"></a>[WS-Addressing-WSDL] </dt><dd>
<cite><a href="http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215">Web Services Addressing 1.0 - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, Editors.</dd>
--- 907,910 ----
***************
*** 960,969 ****
<div class="div2">
! <h3><a name="N67285"></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-07-12 @ 18:46</td><td>mhadley</td><td>Added resolution to issues lc69, lc108 - made wsa:ReplyTo default to anonymous, added new predefined address URI that designates no reply/fault</td></tr><tr><td>2005-07-12 @ 15:57</td><td>mhadley</td><td>Added resolution to issue 107 - assorted editorial fixes wrt alignment with WSDL terminology</td></tr><tr><td>2005-07-11 @ 19:58</td><td>mhadley</td><td>Added resolution to issue lc90 - clarified use of message id as uniqueness metric</td></tr><tr><td>2005-06-21 @ 17:46</td><td>mhadley</td><td>Added resolution to issues lc75 and lc88 - updated description of [message id]</td></tr><tr><td>2005-06-20 @ 19:08</td><td>mhadley</td><td>Added resolution to issue lc106 - updated pseudo schemas to match the notational conventions used by WSDL 2.0</td></tr><tr><td>2005-06-03 @ 20:33</td><td>mhadley</td><td>Added resolutions to issues lc58, lc79, lc91, lc102</td></tr><tr><td>205-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 draft publication</td></tr><tr><td>2005-05-25 @ 20:25</td><td>mhadley</td><td>Added resolution o 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-18 @ 18:51</td><td>mhadley</td><td>Added lc94 resolution - changed element to Element Informaton 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 atch 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 is out of scope except for using simple string comparison to determine whether the anonymous detination 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 description of metadata</td></tr><tr><td>2005-04-22 @ 17:38</td><td>mhadley</td><td>Added resolution tolc12 - 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 resolution to lc2 - assorted editorial changes</td></tr></table>
</div>
<div class="div2">
! <h3><a name="N67295"></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
--- 988,997 ----
<div class="div2">
! <h3><a name="N67309"></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-07-20 @ 18:21</td><td>mhadley</td><td>Added resolution to issues lc55 and lc87 - reworked security section</td></tr><tr><td>2005-07-19 @ 19:13</td><td>mhadley</td><td>Added resolution to issue lc101, lc104 - clarified extensibility of abstract properties</td></tr><tr><td>2005-07-19 @ 18:46</td><td>mhadley</td><td>Added revised resolution to issue lc20 - clarified meaning of anonymous uri in SOAP</td></tr><tr><td>2005-07-19 @ 18:28</td><td>mhadley</td><td>Added revised resolution to issue lc68 - updated text warning designers of EPR extensions that default processing prevails when their extension is not understood</td></tr><tr><td>2005-07-12 @ 18:46</td><td>mhadley</td><td>Added resolution to issues lc69, lc108 - made wsa:ReplyTo default to anonymous, added new predefined address URI that designates no reply/fault</td></tr><tr><td>2005-07-12 @ 15:57</td><td>mhadley</td><td>Added resolution to issue 107 -assorted editorial fixes wrt alignment with WSDL terminology</td></tr><tr><td>2005-07-11 @ 19:58</td><td>mhadley</td><td>Added resolution to issue lc90 - clarified use of message id as uniqueness metric</td></tr><tr><td>2005-06-21 @ 17:46</td><td>mhadley</td><td>Added resolution to issues lc75 and lc88 - updated description of [message id]</td></tr><tr><td>2005-06-20 @ 19:08</td><td>mhadley</td><td>Added resolution to issue lc106 - updated pseudo schemas to match the notational conventions used by WSDL 2.0</td></tr><tr><td>2005-06-03 @ 20:33</td><td>mhadley</td><td>Added resolutions to issues lc58, lc79, lc91, lc102</td></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-ocurrence 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 draft 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 ttributes 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-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 resoluton - 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 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>Added 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><td>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="N67319"></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
***************
*** 974,983 ****
<div class="div2">
! <h3><a name="N67305"></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="N67315"></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>
--- 1002,1011 ----
<div class="div2">
! <h3><a name="N67329"></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="N67339"></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.37
retrieving revision 1.38
diff -C2 -d -r1.37 -r1.38
*** ws-addr-soap.html 21 Jun 2005 17:47:10 -0000 1.37
--- ws-addr-soap.html 20 Jul 2005 18:32:28 -0000 1.38
***************
*** 66,71 ****
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> 1.1 <a href="#notation"> Notational Conventions</a><br> 1.2 <a href="#namespaces"> Namespaces</a><br>2. <a href="#s12feature">SOAP 1.2 Addressing 1.0 Feature</a><br> 2.1 <a href="#s12featurename">Feature Name</a><br> 2.2 <a href="#s12featuredesc">Description</a><br> 2.3 <a href="#s12featureprops">Properties</a><br> 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> 3.1 <a href="#s12modulename">Module Name</a><br> 3.2 <a href="#s12moduledesc">Description</a><br> 3.3 <a href="#additionalinfoset">Additional Infoset Items</a><br> 3.4 <a href="#bindrefp">Binding Message Addressing Properies</a><br>4. <a href="#s11ext">SOAP 1.1 Addressing 1.0 Extension</a><br> 4.1 <a href="#s11extname">Extension Name</a><br> 4.2 <a href="#s11extdesc">Description</a><br>5. <a href="#faults">Faults</a><br> 5.1 <a href="#N66318">SOAP 1.2 Fault Binding</a><br> 5.2 <a href="#N66388">SOAP 1.1 Fault Binding</a><br> 5.3 <a href="#invalidmapfault"> Invalid Addressing Header</a><br> 5.4 <a href="#missingmapfault"> Message Addressing Header Required</a><br> 5.5 <a href="#destinationfault"> Destination Unreachable</a><br> 5.6 <a href="#actionfault"> Action Not Supported</a><br> 5.7 <a href="#unavailablefault"> Endpoint Unavailable</a><br>6. <a href="#securityconsiderations">Security Considerations</a><br> 6.1 <a href="#intseccons">Additional Considerations for SOAP Intermediaries</a><br>7. <a ref="#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> B.1 <a href="#N67134">Changes Since Last Call Working Draft</a><br> B.2 <a href="#N67144">Changes Since Second Working Draft</a><br> B.3 <a href="#N67154">Changes Since First Working Draft</a><br> B.4 <a href="#N67164">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
--- 66,71 ----
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> 1.1 <a href="#notation"> Notational Conventions</a><br> 1.2 <a href="#namespaces"> Namespaces</a><br>2. <a href="#s12feature">SOAP 1.2 Addressing 1.0 Feature</a><br> 2.1 <a href="#s12featurename">Feature Name</a><br> 2.2 <a href="#s12featuredesc">Description</a><br> 2.3 <a href="#s12featureprops">Properties</a><br> 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> 3.1 <a href="#s12modulename">Module Name</a><br> 3.2 <a href="#s12moduledesc">Description</a><br> 3.3 <a href="#additionalinfoset">Additional Infoset Items</a><br> 3.4 <a href="#bindrefp">Binding Message Addressing Properies</a><br> 3.5 <a href="#soaphttp">Use of Anonymous Address in SOAP</a><br>4. <a href="#s11ext">SOAP 1.1 Addressing 1.0 Extension</a><br> 4.1 <a href="#s11extname">Extension Name</a><br> 4.2 <a href="#s11extdesc">Description</a><br>5. <a href="#faults">Faults</a><br> 5.1 <a href="#N66337">SOAP 1.2 Fault Binding</a><br> 5.2 <a href="#N66419">SOAP 1.1 Fault Binding</a><br> 5.3 <a href="#faultdetailelements">Fault Detail Elements</a><br> 5.3.1 <a href="#N66525">Problem Header</a><br> 5.3.2 <a href="#N66561">Problem Header QName</a><br> 5.3.3 <a href="#N66597">Problem IRI</a><br> 5.3.4 <a href="#N66633">Problem Action</a><br> 5.3.5 <a href="#N6693">Retry After</a><br> 5.4 <a href="#soapfaults">Predefined Faults</a><br> 5.4.1 <a href="#invalidmapfault"> Invalid Addressing Header</a><br> 5.4.1.1 <a href="#N66766">wsa:InvalidAddress</a><br> 5.4.1.2 <a href="#N66775">wsa:InvalidEPR</a><br> 5.4.1.3 <a href="#N66784">wsa:InvalidCardinality</a><br> 5.4.1.4 <a href="#N66793">wsa:MissingAddressInEPR</a><br> 5.4.1.5 <a href="#N66802">wsa:DuplicateMessageID</a><br> 5.4.1.6 <a href="#N66811">wsa:ActionMismatch</a><br> 5.4.2 < href="#missingmapfault"> Message Addressing Header Required</a><br> 5.4.3 <a href="#destinationfault"> Destination Unreachable</a><br> 5.4.4 <a href="#actionfault"> Action Not Supported</a><br> 5.4.5 <a href="#unavailablefault"> Endpoint Unavailable</a><br>6. <a href="#securityconsiderations">Security Considerations</a><br> 6.1 <a href="#N66945">Establishing EPR Trust</a><br> 6.2 <a href="#N66963">Additional Security Considerations</a><br> 6.3 <a href="#N66981">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> B.1 <a href="#N67390">Changes Since Last Call Working Draft</a><br> B.2 <a href="#N67400">Changes Since Second Working Draft</a><br> B.3 <a href="#N67410">Changes Since First Working Draft</a><br> B.4 <a href="#N67420">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
***************
*** 252,256 ****
http://www.w3.org/@@@@/@@/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 <a href="#invalidmapfault"><b>5.3 Invalid Addressing Header</b></a>.</p>
</div>
</div>
--- 252,256 ----
http://www.w3.org/@@@@/@@/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 <a href="#invalidmapfault"><b>5.4.1 Invalid Addressing Header</b></a>.</p>
</div>
</div>
***************
*** 287,291 ****
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. A
! recipient MUST generate a wsa:InvalidAddressingHeader (see <a href="#invalidmapfault"><b>5.3 Invalid Addressing Header</b></a>) fault if such a message is received.</p>
<div class="note"><p class="prefix"><b>Note:</b></p>
<p>The SOAP processing model dictates that message addressing properties targeted at an
--- 287,291 ----
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. A
! recipient MUST generate a wsa:InvalidAddressingHeader (see <a href="#invalidmapfault"><b>5.4.1 Invalid Addressing Header</b></a>) fault if such a message is received.</p>
<div class="note"><p class="prefix"><b>Note:</b></p>
<p>The SOAP processing model dictates that message addressing properties targeted at an
***************
*** 399,402 ****
--- 399,414 ----
</div>
</div>
+ <div class="div2">
+
+ <h3><a name="soaphttp"></a>3.5 Use of Anonymous Address in SOAP</h3>
+ <p>When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address of the
+ ReplyTo or FaultTo EPR,
+ the underlying SOAP protocol binding provides a channel to the specified endpoint.
+ Any underlying protocol binding supporting the SOAP request-response message
+ exchange pattern provides such a channel. For instance, the SOAP 1.2
+ HTTP binding[<cite><a href="#SOAP12-PART2">SOAP 1.2 Part 2: Adjuncts</a></cite>] puts the reply message in the
+ HTTP response.</p>
+ </div>
+
</div>
<div class="div1">
***************
*** 435,439 ****
otherwise unnecessary transport-level security. Failure to have an identical value,
or an empty value for SOAPAction, results in an Invalid Message Addressing Property
! fault (see <a href="#invalidmapfault"><b>5.3 Invalid Addressing Header</b></a>.</p>
</dd>
--- 447,451 ----
otherwise unnecessary transport-level security. Failure to have an identical value,
or an empty value for SOAPAction, results in an Invalid Message Addressing Property
! fault (see <a href="#invalidmapfault"><b>5.4.1 Invalid Addressing Header</b></a>.</p>
</dd>
***************
*** 444,449 ****
<h2><a name="faults"></a>5. Faults</h2>
! <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
--- 456,461 ----
<h2><a name="faults"></a>5. Faults</h2>
! <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
***************
*** 462,471 ****
<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> [Reason] The English language reason element, use of the specified fault code is
RECOMMENDED but alternate text MAY be used.</p>
! <p> [Detail] The detail element, use of the specified detail element is REQUIRED. If absent, no detail element is defined for the fault.</p>
<div class="div2">
! <h3><a name="N66318"></a>5.1 SOAP 1.2 Fault Binding</h3>
<p>The fault properties bind to a SOAP 1.2 fault as follows:</p>
<dl>
--- 474,486 ----
<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>
<div class="div2">
! <h3><a name="N66337"></a>5.1 SOAP 1.2 Fault Binding</h3>
<p>The fault properties bind to a SOAP 1.2 fault as follows:</p>
<dl>
***************
*** 485,488 ****
--- 500,510 ----
+ <dt class="label">[Subsubcode]</dt>
+ <dd>
+ <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>
+ </dd>
+
+
<dt class="label">[Reason]</dt>
<dd>
***************
*** 492,498 ****
! <dt class="label">[Detail]</dt>
<dd>
! <p>The value of the [Detail] property is bound as child of the SOAP faults
S:Fault/S:Detail element information item.</p>
</dd>
--- 514,520 ----
! <dt class="label">[Details]</dt>
<dd>
! <p>The value of the [Details] property is bound as child elements of the SOAP faults
S:Fault/S:Detail element information item.</p>
</dd>
***************
*** 513,516 ****
--- 535,541 ----
<S:Subcode>
<S:Value>[Subcode]</S:Value>
+ <S:Subcode>
+ <S:Value>[Subsubcode]</S:Value>
+ </S:Subcode>
</S:Subcode>
</S:Code>
***************
*** 529,540 ****
<div class="div2">
! <h3><a name="N66388"></a>5.2 SOAP 1.1 Fault Binding</h3>
<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>
<dl>
! <dt class="label">[Subcode]</dt>
<dd>
! <p>The value of the [Subcode] property is bound as the value of the SOAP faults
S11:Fault/faultcode element.</p>
</dd>
--- 554,566 ----
<div class="div2">
! <h3><a name="N66419"></a>5.2 SOAP 1.1 Fault Binding</h3>
<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>
<dl>
! <dt class="label">[Subcode] or [Subsubcode]</dt>
<dd>
! <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>
</dd>
***************
*** 548,556 ****
! <dt class="label">[Detail]</dt>
<dd>
<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 [Detail] property is bound as the value
of a new wsa:FaultDetail SOAP header block. The following describes the
wsa:FaultDetail element:</p>
--- 574,582 ----
! <dt class="label">[Details]</dt>
<dd>
<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>
***************
*** 559,564 ****
<dt class="label">/wsa:FaultDetail</dt>
<dd>
! <p>One of wsa:ActionNotSupported, wsa:InvalidAddressingHeader,
! wsa:MessageAddressingHeaderRequired, wsa:RetryAfter or xs:any.</p>
</dd>
--- 585,589 ----
<dt class="label">/wsa:FaultDetail</dt>
<dd>
! <p>Zero or more of the elements defined in <a href="#faultdetailelements"><b>5.3 Fault Detail Elements</b></a>.</p>
</dd>
***************
*** 579,588 ****
<S11:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
! <wsa:FaultDetail>[Detail]</wsa:FaultDetail>
<!-- Other headers elided for brevity. -->
</S11:Header>
<S11:Body>
<S11:Fault>
! <faultcode>[Subcode]</faultcode>
<faultstring xml:lang="en">[Reason]</faultstring>
</S11:Fault>
--- 604,613 ----
<S11:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
! <wsa:FaultDetail>[Details]</wsa:FaultDetail>
<!-- Other headers elided for brevity. -->
</S11:Header>
<S11:Body>
<S11:Fault>
! <faultcode>[Subcode] or [Subsubcode]</faultcode>
<faultstring xml:lang="en">[Reason]</faultstring>
</S11:Fault>
***************
*** 592,731 ****
</div>
</div>
<div class="div2">
! <h3><a name="invalidmapfault"></a>5.3 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 <wsa:InvalidAddressingHeader> element</p>
! <p> The following describes the <wsa:InvalidAddressingHeader> element:</p>
! <dl>
!
! <dt class="label">/wsa:InvalidAddressingHeader</dt>
! <dd>
! <p>A QName representing the name of the root element of the invalid header block</p>
! </dd>
!
!
! <dt class="label">/wsa:InvalidAddressingHeader/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
!
! </dl>
! </div>
! <div class="div2">
! <h3><a name="missingmapfault"></a>5.4 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 <wsa:MessageAddressingHeaderRequired> element</p>
! <p> The following describes the <wsa:MessageAddressingHeaderRequired> element:</p>
! <dl>
! <dt class="label">/wsa:MessageAddressingHeaderRequired</dt>
! <dd>
! <p>A QName representing the name of the missing header element</p>
! </dd>
! <dt class="label">/wsa:MessageAddressingHeaderRequired/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
! </dl>
! </div>
! <div class="div2">
- <h3><a name="destinationfault"></a>5.5 Destination Unreachable</h3>
- <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> [Detail] (empty)</p>
</div>
<div class="div2">
! <h3><a name="actionfault"></a>5.6 Action Not Supported</h3>
! <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] a <wsa:ActionNotSupported> element</p>
! <p> The following describes the <wsa:ActionNotSupported> element:</p>
! <dl>
!
! <dt class="label">/wsa:ActionNotSupported</dt>
! <dd>
! <p>The value of the wsa:Action header block</p>
! </dd>
!
! <dt class="label">/wsa:ActionNotSupported/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
! </dl>
! </div>
! <div class="div2">
!
! <h3><a name="unavailablefault"></a>5.7 Endpoint Unavailable</h3>
! <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> [Detail] a <wsa:RetryAfter> element</p>
! <p> The following describes the <wsa:RetryAfter> element:</p>
! <dl>
! <dt class="label">/wsa:RetryAfter</dt>
! <dd>
! <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>
! </dd>
! <dt class="label">/wsa:RetryAfter/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
! </dl>
</div>
</div>
<div class="div1">
<h2><a name="securityconsiderations"></a>6. Security Considerations</h2>
! <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[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>].</p>
! <p>When receiving a SOAP message, certain SOAP headers may be resulting from the serialization
! of an EPR's [reference parameters] property. The SOAP message receiver can perform
! 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>
! <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 "http://www.w3.org/@@@@/@@/addressing/reply",
! an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute,
! an intermediary MUST NOT add one. </p>
</div>
</div>
<div class="div1">
--- 617,953 ----
</div>
</div>
+
<div class="div2">
! <h3><a name="faultdetailelements"></a>5.3 Fault Detail Elements</h3>
! <p>The following subsections define a set of elements used to convey additional information
! in the faults described in <a href="#soapfaults"><b>5.4 Predefined Faults</b></a>.</p>
! <table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">Additional detail elements may be defined if feedback during CR indicates that
! this would be useful.</td></tr></table>
! <div class="div3">
! <h4><a name="N66525"></a>5.3.1 Problem Header</h4>
! <p> The following describes the <wsa:ProblemHeader> element:</p>
! <dl>
!
! <dt class="label">/wsa:ProblemHeader</dt>
! <dd>
! <p>The root element of the invalid header block, all descendants of the root element
! are also included.</p>
! </dd>
!
!
! <dt class="label">/wsa:ProblemHeader/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
!
! </dl>
! </div>
! <div class="div3">
+ <h4><a name="N66561"></a>5.3.2 Problem Header QName</h4>
+ <p> The following describes the <wsa:ProblemHeaderQName> element:</p>
+ <dl>
+
+ <dt class="label">/wsa:ProblemHeaderQName</dt>
+ <dd>
+ <p>A QName representing the name of the root element of the problem header block.</p>
+ </dd>
+
+
+ <dt class="label">/wsa:ProblemHeaderQName/@{any}</dt>
+ <dd>
+ <p>Optional extensibility attributes that do not affect processing.</p>
+ </dd>
+
+ </dl>
+ </div>
+ <div class="div3">
! <h4><a name="N66597"></a>5.3.3 Problem IRI</h4>
! <p> The following describes the <wsa:ProblemIRI> element:</p>
! <dl>
!
! <dt class="label">/wsa:ProblemIRI</dt>
! <dd>
! <p>The IRI that caused the problem.</p>
! </dd>
!
!
! <dt class="label">/wsa:ProblemIRI/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
!
! </dl>
! </div>
! <div class="div3">
! <h4><a name="N66633"></a>5.3.4 Problem Action</h4>
! <p> The following describes the <wsa:ProblemAction> element:</p>
! <dl>
!
! <dt class="label">/wsa:ProblemAction/wsa:Action</dt>
! <dd>
! <p>An optional element that provides the [action] that caused the problem.</p>
! </dd>
!
!
! <dt class="label">/wsa:ProblemAction/wsa:SoapAction</dt>
! <dd>
! <p>An optional element that provides the SOAPAction IRI that caused the problem.</p>
! </dd>
!
!
! <dt class="label">/wsa:ProblemAction/{any}</dt>
! <dd>
! <p>Optional extensibility elements that do not affect processing.</p>
! </dd>
!
!
! <dt class="label">/wsa:ProblemAction/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
!
! </dl>
! </div>
! <div class="div3">
!
! <h4><a name="N66693"></a>5.3.5 Retry After</h4>
! <p> The following describes the <wsa:RetryAfter> element:</p>
! <dl>
!
! <dt class="label">/wsa:RetryAfter</dt>
! <dd>
! <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>
! </dd>
!
!
! <dt class="label">/wsa:RetryAfter/@{any}</dt>
! <dd>
! <p>Optional extensibility attributes that do not affect processing.</p>
! </dd>
!
! </dl>
! </div>
</div>
+
<div class="div2">
! <h3><a name="soapfaults"></a>5.4 Predefined Faults</h3>
! <table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">Additional faults may be defined if feedback during CR indicates that
! this would be useful.</td></tr></table>
!
! <div class="div3">
! <h4><a name="invalidmapfault"></a>5.4.1 Invalid Addressing Header</h4>
! <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 <wsa:ProblemHeader> element that conveys a copy of the
! offending header or a
! <wsa:ProblemHeaderQName> 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>
! <div class="div4">
!
! <h5><a name="N66766"></a>5.4.1.1 wsa:InvalidAddress</h5>
! <p>Specifies that an [address] was invalid, [Details] MAY contain a wsa:ProblemIRI
! element in addition to the <wsa:ProblemHeader> element or
! <wsa:ProblemHeaderQName> element.</p>
! </div>
! <div class="div4">
!
! <h5><a name="N66775"></a>5.4.1.2 wsa:InvalidEPR</h5>
! <p>Specifies that the invalid header was expected to be an EPR but was not valid.</p>
! </div>
! <div class="div4">
!
! <h5><a name="N66784"></a>5.4.1.3 wsa:InvalidCardinality</h5>
! <p>Specifies that there was a greater than expected number of the specified header.</p>
! </div>
! <div class="div4">
!
! <h5><a name="N66793"></a>5.4.1.4 wsa:MissingAddressInEPR</h5>
! <p>Specifies that the invalid header was expected to be an EPR but did not contain an
! [address].</p>
! </div>
! <div class="div4">
!
! <h5><a name="N66802"></a>5.4.1.5 wsa:DuplicateMessageID</h5>
! <p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
! already received.</p>
! </div>
! <div class="div4">
!
! <h5><a name="N66811"></a>5.4.1.6 wsa:ActionMismatch</h5>
! <p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
! MAY contain a <wsa:ActionMismatch>
! element in addition to the <wsa:ProblemHeader> element or
! <wsa:ProblemHeaderQName> element.</p>
! </div>
! </div>
! <div class="div3">
! <h4><a name="missingmapfault"></a>5.4.2 Message Addressing Header Required</h4>
! <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 <wsa:ProblemHeaderQName> element that conveys the QName of the
! message addressing header that was missing.</p>
! </div>
! <div class="div3">
+ <h4><a name="destinationfault"></a>5.4.3 Destination Unreachable</h4>
+ <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 <wsa:ProblemIRI> element that conveys the [address] of the
+ [destination].</p>
+ </div>
+ <div class="div3">
! <h4><a name="actionfault"></a>5.4.4 Action Not Supported</h4>
! <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 <wsa:ProblemAction> element with a REQUIRED <wsa:Action> child
! element</p>
! </div>
! <div class="div3">
! <h4><a name="unavailablefault"></a>5.4.5 Endpoint Unavailable</h4>
! <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 <wsa:RetryAfter> element and an optional <wsa:ProblemIRI> element that conveys the [address] of the
! [destination].</p>
! </div>
</div>
+
</div>
<div class="div1">
<h2><a name="securityconsiderations"></a>6. Security Considerations</h2>
!
! <div class="note"><p class="prefix"><b>Note:</b></p><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></div>
!
! <p>As discussed in Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>],
! 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 endopoint] or [fault endpoint]
! to avoid inadvertant 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[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>].</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>
!
<div class="div2">
! <h3><a name="N66945"></a>6.1 Establishing EPR Trust</h3>
!
! <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[<cite><a href="#WS-Security">WS-Security</a></cite>] 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[<cite><a href="#WS-Security">WS-Security</a></cite>] 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 can have some level of confidence that the message
! sender has authority to represent the [address] of the EPR.</p>
!
</div>
+
+ <div class="div2">
+
+ <h3><a name="N66963"></a>6.2 Additional Security Considerations</h3>
+
+ <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 [<cite><a href="#WS-Security">WS-Security</a></cite>] - Security
+ Conciderations: Removal and modification of XML elements.</p>
+ </div>
+
+ <div class="div2">
+
+ <h3><a name="N66981"></a>6.3 Additional Considerations for SOAP Intermediaries</h3>
+
+ <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
+ "http://www.w3.org/@@@@/@@/addressing/reply", an intermediary MUST NOT
+ remove it; similarly, if there is no RelationshipType attribute, an
+ intermediary MUST NOT add one.</p>
+ </div>
+
</div>
<div class="div1">
***************
*** 758,762 ****
<dt class="label"><a name="WSADDR-CORE"></a>[WS-Addressing-Core] </dt><dd>
<cite><a href="ws-addr-core.html">Web Services Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, Editors.</dd>
-
<dt class="label"><a name="WSADDR-WSDL"></a>[WS-Addressing-WSDL] </dt><dd>
<cite><a href="http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215">Web Services Addressing 1.0 - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, Editors.</dd>
--- 980,983 ----
***************
*** 839,858 ****
<div class="div2">
! <h3><a name="N67134"></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-21 @ 17:12</td><td>mhadley</td><td>Added issue 71 resolution - clarified that the value of reason text is recommended but not required</td></tr><tr><td>2005-06-14 @ 14:25</td><td>mhadley</td><td>Added resolutions to issues lc56 and lc72 - Added new fault detail elements and header block for SOAP 1.1</td></tr><tr><td>2005-06-03 @ 20:36</td><td>mhadley</td><td>Fixed typo in document prologue</td></tr><tr><td>2005-06-03 @ 20:33</td><td>mhadley</td><td>Added resolutions to issues lc58, lc79, lc91, lc102</td></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-0602 @ 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 publication</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><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><d>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 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><t>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: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 II 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="N67144"></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="N67154"></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="N67164"></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>
--- 1060,1079 ----
<div class="div2">
! <h3><a name="N67390"></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-07-20 @ 18:21</td><td>mhadley</td><td>Added resolution to issues lc55 and lc87 - reworked security section</td></tr><tr><td>2005-07-20 @ 15:53</td><td>mhadley</td><td>Added resolution to issue lc76 - expanded faults section</td></tr><tr><td>2005-07-19 @ 20:08</td><td>mhadley</td><td>Added partial resolution to issue lc76 - added new sections for standard detail items and grouped faults in new section</td></tr><tr><td>2005-07-19 @ 18:46</td><td>mhadley</td><td>Added revised resolution to issue lc20 - clarified meaning of anonymous uri in SOAP</td></tr><tr><td>2005-06-21 @ 17:12</td><td>mhadley</td><td>Added issue 71 resolution - clarified that the value of reason text is recommended but not required</td></tr><tr><td>2005-06-14 @ 14:25</td><td>mhadley</td><td>Added resolutions to issues lc56 and lc72 - Added new fault detail elements and header block for SOAP 1.1</td></tr><tr><td>2005-06-03 @ 20:36</td><td>mhadle</td><td>Fixed typo in document prologue</td></tr><tr><td>2005-06-03 @ 20:33</td><td>mhadley</td><td>Added resolutions to issues lc58, lc79, lc91, lc102</td></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>mhadly</td><td>Added new section in changelog to account for previous draft publication</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 - expandd MAP to message 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 o binding 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 efinition 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="N67400"></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="N67410"></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="N67420"></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 Wednesday, 20 July 2005 18:32:44 UTC