W3C home > Mailing lists > Public > public-ws-addressing-eds@w3.org > January to March 2005

2004/ws/addressing ws-addr-core.html,1.13,1.14 ws-addr-soap.html,1.12,1.13 ws-addr-wsdl.html,1.12,1.13

From: Marc Hadley <mhadley@dev.w3.org>
Date: Tue, 15 Feb 2005 23:23:53 +0000
To: public-ws-addressing-eds@w3.org
Message-ID: <E1D1C2r-0001RZ-QR@lionel-hutz.w3.org>

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

Modified Files:
	ws-addr-core.html ws-addr-soap.html ws-addr-wsdl.html 
Log Message:
Updated with latest changes

Index: ws-addr-wsdl.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-wsdl.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** ws-addr-wsdl.html	1 Feb 2005 19:51:03 -0000	1.12
--- ws-addr-wsdl.html	15 Feb 2005 23:23:51 -0000	1.13
***************
*** 53,57 ****
              <a href="http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl">http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl</a>
          </dd><dt>Previous versions:</dt><dd>
!             
          </dd><dt>Editors:</dt>
              <dd>Martin Gudgin, Microsoft Corp</dd>
--- 53,57 ----
              <a href="http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl">http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl</a>
          </dd><dt>Previous versions:</dt><dd>
!             <a href="http://www.w3.org/TR/2004/WD-ws-addr-wsdl-20041208">http://www.w3.org/TR/2004/WD-ws-addr-wsdl-20041208</a>
          </dd><dt>Editors:</dt>
[...1023 lines suppressed...]
!       alphabetical order):
!       Abbie Barbir (Nortel Networks), Rebecca Bergersen (IONA Technologies, Inc.), Andreas Bj&auml;rlestam (ERICSSON), Ugo Corda (SeeBeyond Technology Corporation), Francisco Curbera (IBM Corporation), Glen Daniels (Sonic Software), Paul Downey (BT), Jacques Durand (Fujitsu Limited), Michael Eder (Nokia), Robert Freund (Hitachi, Ltd.), Yaron Goland (BEA Systems, Inc.), Martin Gudgin (Microsoft Corporation), Arun Gupta (Sun Microsystems, Inc.), Hugo Haas (W3C/ERCIM), Marc Hadley (Sun Microsystems, Inc.), David Hull (TIBCO Software, Inc.), Yin-Leng Husband (HP), Anish Karmarkar (Oracle Corporation), Paul Knight (Nortel Networks), Philippe Le H&eacute;garet (W3C/MIT), Mark Little (Arjuna Technologies Ltd.), Jonathan Marsh (Microsoft Corporation), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (ERICSSON), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems, Inc.), Ales Novy (Systinet Inc.), David Orchard (BEA Systems, Inc.), Mark Peel (Novell, Inc.), Harris Reynolds (webMethods, Inc.), Tony Roges (Computer Associates), Tom Rutt (Fujitsu Limited), Rich Salz (DataPower Technology, Inc.), Davanum Srinivas (Computer Associates), Jiri Tejkl (Systinet Inc.), Greg Truty (IBM Corporation), Steve Vinoski (IONA Technologies, Inc.), Pete Wenzel (SeeBeyond Technology Corporation), Steve Winkler (SAP AG), &Uuml;mit Yal&ccedil;ınalp (SAP AG).</p>
!   <p>Previous members of the Working Group were: @@@.</p>
!   <p>The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-addressing/">discussions
!       on public-ws-addressing@w3.org</a> are also gratefully
!       acknowledged.</p>
! </div>
!  <div class="div1">
              
  <h2><a name="changelog"></a>B. Change Log (Non-Normative)</h2>
              <div class="div2">
                  
! <h3><a name="N10A79"></a>B.1 Changes Since First Working Draft</h3>
!                 <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-15 @ 23:19</td><td>mhadley</td><td>Added resolution to issue 45</td></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-25 @ 22:23</td><td>mhadley</td><td>Added descriptive text for wsa:Action attribute. Fixed references to WSDL 1.1 to be more explicit version-wise.</td></tr><tr><td>2005-01-24 @ 10:12</td><td>mgudgin</td><td>Incorporated resolution of i034 and i035; default action URI for WSDL 2.0 and default action URI for faults. All edits in section 3</td></tr><tr><td>2005-01-18 @ 04:01</td><td>mgudgin</td><td>Modified text in Section 2 WRT closing issue i020</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><tdAdded 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="N10A83"></a>B.2 Changes Since Submission</h3>
                  <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2004-12-04 @ 02:04</td><td>mgudgin</td><td>Added text to section on WSDL MEPs per resolution of Issue i003</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-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 @ 21:45</td><td>mhadley</td><td>Replaced hardcoded change log with one generated dynamically from CVS</td></tr><tr><td>2004-10-28 @ 18:09</td><td>mhadley</td><td>Fixed typo in abstract</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-core.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** ws-addr-core.html	1 Feb 2005 19:51:03 -0000	1.13
--- ws-addr-core.html	15 Feb 2005 23:23:51 -0000	1.14
***************
*** 52,55 ****
--- 52,57 ----
          </dd><dt>Latest version:</dt><dd>
              <a href="http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core">http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core</a>
+         </dd><dt>Previous versions:</dt><dd>
+ 	  <a href="http://www.w3.org/TR/2004/WD-ws-addr-core-20041208">http://www.w3.org/TR/2004/WD-ws-addr-core-20041208</a>
          </dd><dt>Editors:</dt>
              <dd>Martin Gudgin, Microsoft Corp</dd>
***************
*** 68,74 ****
          no official standing.</strong></p><p></p></div>
      <hr><div class="toc">
! <h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#tocRange"> Introduction</a><br>2. <a href="#_Toc77464317"> Endpoint References</a><br>3. <a href="#_Toc77464322"> Message Addressing Properties</a><br>4. <a href="#_Toc77464336"> References</a><br>A. <a href="#_Toc77464335"> Acknowledgements </a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br></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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#_Toc77464315"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#_Toc77464316"> Namespaces</a><br>2. <a href="#_Toc77464317"> Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#_Toc77464318"> Information Model for Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#_Toc77464319"> Endpoint Reference XML Infoset Representation</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#eprcomp"> Endpoint Reference Comparison</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br>3. <a href="#_Toc77464322"> Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#_Toc77464323">XML Infoset Representation of Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#formreplymsg"> Formulating a Reply Message</a><br>4. <a href="#_Toc77464336"> References</a><br></p>! <h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#_Toc77464335"> Acknowledgements </a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N10561">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N1056B">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
--- 70,76 ----
          no official standing.</strong></p><p></p></div>
      <hr><div class="toc">
! <h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#tocRange"> Introduction</a><br>2. <a href="#_Toc77464317"> Endpoint References</a><br>3. <a href="#_Toc77464322"> Message Addressing Properties</a><br>4. <a href="#_Toc77464336"> References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br></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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#_Toc77464315"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#_Toc77464316"> Namespaces</a><br>2. <a href="#_Toc77464317"> Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#_Toc77464318"> Information Model for Endpoint References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#_Toc77464319"> Endpoint Reference XML Infoset Representation</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#eprcomp"> Endpoint Reference Comparison</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#eprlifecycle">Endpoint Reference Lifecycle</a><br>3. <a href="#_Toc77464322"> Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#_Toc77464323">XML Infoset Representation of Message Addressing Properties</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1 <a href="#N103F5">Comparing URIs</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#formrelymsg"> Formulating a Reply Message</a><br>4. <a href="#_Toc77464336"> References</a><br></p>
! <h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N10593">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N1059D">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
***************
*** 146,150 ****
                      prefix is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite>
                      ]).</p>
!                 <a name="nsprefix"></a><br><table summary="Namespace prefixes usage in this specification" border="1">
                      <caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
                      <tbody>
--- 148,152 ----
                      prefix is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite>
                      ]).</p>
!                 <a name="nsprefix"></a><table summary="Namespace prefixes usage in this specification" border="1">
                      <caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
                      <tbody>
***************
*** 389,393 ****
       xmlns:wsa="http://www.w3.org/@@@@/@@/addressing"
       xmlns:fabrikam="http://example.com/fabrikam"
!      xmlns:wsdli="http://www.w3.org/@@@@/@@/wsdl-instance"
       wsdli:wsdlLocation="http://example.com/fabrikam
         http://example.com/fabrikam/fabrikam.wsdl"&gt;
--- 391,395 ----
       xmlns:wsa="http://www.w3.org/@@@@/@@/addressing"
       xmlns:fabrikam="http://example.com/fabrikam"
!      xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
       wsdli:wsdlLocation="http://example.com/fabrikam
         http://example.com/fabrikam/fabrikam.wsdl"&gt;
***************
*** 425,435 ****
                      SHOULD be used. </p>
                  <p>The [address] properties of two endpoint references are compared according to
!                     Section 6 of [<cite><a href="#RFC2396">RFC 2396bis</a></cite>].
!                     
!                 </p>
!                 
                  <p>Therefore, a consuming application should assume that different XML Schemas, WSDL
!                     definitions and policies apply to endpoint references whose addresses
!                      differ.</p>
              </div>
              <div class="div2">
--- 427,433 ----
                      SHOULD be used. </p>
                  <p>The [address] properties of two endpoint references are compared according to
!                     Section 6 of [<cite><a href="#RFC2396">IETF RFC 3986</a></cite>].</p>
                  <p>Therefore, a consuming application should assume that different XML Schemas, WSDL
!                     definitions and policies apply to endpoint references whose addresses differ.</p>
              </div>
              <div class="div2">
***************
*** 447,468 ****
              <p>This section defines the information model and syntax of message addressing
                  properties.</p>
!             <p> Message addressing properties provide references for the
!                 endpoints involved in an interaction. The use of these properties to support
!                 specific interaction is in general defined by both the semantics of the properties
!                 themselves and the implicit or explicit contract that governs the message exchange.
!                 If explicitly available, this contract can take different forms including but not
!                 being limited to WSDL MEPs and interfaces; business processes and e-commerce
!                 specifications, among others, can also be used to define explicit contracts between
!                 the parties. The basic interaction pattern from which all others are composed is
!                 "one way". In this pattern a source sends a message to a destination without any
!                 further definition of the interaction. "Request Reply" is a common interaction
!                 pattern that consists of an initial message sent by a source endpoint (the request)
!                 and a subsequent message sent from the destination of the request back to the source
!                 (the reply). A reply in this case can be either an application message, a fault, or
!                 any other message. Note, however, that reply messages may be sent as part of other
!                 message exchanges as well, and are not restricted to the usual single Request,
!                 single Reply pattern, or to a particular WSDL MEP. The contract between the
!                 interacting parties may specify that multiple or even a variable number or replies
!                 be delivered. </p>
              <p>Message addressing properties collectively augment a message with the following
                  abstract properties to support one way, request reply, and any other interaction
--- 445,465 ----
              <p>This section defines the information model and syntax of message addressing
                  properties.</p>
!             <p> Message addressing properties provide references for the endpoints involved in an
!                 interaction. The use of these properties to support specific interaction is in
!                 general defined by both the semantics of the properties themselves and the implicit
!                 or explicit contract that governs the message exchange. If explicitly available,
!                 this contract can take different forms including but not being limited to WSDL MEPs
!                 and interfaces; business processes and e-commerce specifications, among others, can
!                 also be used to define explicit contracts between the parties. The basic interaction
!                 pattern from which all others are composed is "one way". In this pattern a source
!                 sends a message to a destination without any further definition of the interaction.
!                 "Request Reply" is a common interaction pattern that consists of an initial message
!                 sent by a source endpoint (the request) and a subsequent message sent from the
!                 destination of the request back to the source (the reply). A reply in this case can
!                 be either an application message, a fault, or any other message. Note, however, that
!                 reply messages may be sent as part of other message exchanges as well, and are not
!                 restricted to the usual single Request, single Reply pattern, or to a particular
!                 WSDL MEP. The contract between the interacting parties may specify that multiple or
!                 even a variable number or replies be delivered. </p>
              <p>Message addressing properties collectively augment a message with the following
                  abstract properties to support one way, request reply, and any other interaction
***************
*** 484,489 ****
                      <dt class="label"> [reply endpoint] : endpoint reference (0..1)</dt>
                      <dd>
!                         <p>An endpoint reference for the intended receiver for replies
!                             to this message. If a reply is expected, a message MUST contain a [reply
                              endpoint]. The sender MUST use the contents of the [reply endpoint] to
                              formulate the reply message as defined in <a href="#formreplymsg"><b>3.2  Formulating a Reply Message</b></a>.
--- 481,486 ----
                      <dt class="label"> [reply endpoint] : endpoint reference (0..1)</dt>
                      <dd>
!                         <p>An endpoint reference for the intended receiver for replies to this
!                             message. If a reply is expected, a message MUST contain a [reply
                              endpoint]. The sender MUST use the contents of the [reply endpoint] to
                              formulate the reply message as defined in <a href="#formreplymsg"><b>3.2  Formulating a Reply Message</b></a>.
***************
*** 494,503 ****
                      <dt class="label"> [fault endpoint] : endpoint reference (0..1)</dt>
                      <dd>
!                         <p>An endpoint reference for the intended receiver for faults
!                             related to this message. When formulating a fault message as defined in
!                                 <a href="#formreplymsg"><b>3.2  Formulating a Reply Message</b></a>, the sender MUST use the contents of
!                             the [fault endpoint], when present, of the message being replied to to
!                             formulate the fault message. If this property is present, the [message
!                             id] property is REQUIRED.</p>
                      </dd>
                  
--- 491,499 ----
                      <dt class="label"> [fault endpoint] : endpoint reference (0..1)</dt>
                      <dd>
!                         <p>An endpoint reference for the intended receiver for faults related to
!                             this message. When formulating a fault message as defined in <a href="#formreplymsg"><b>3.2  Formulating a Reply Message</b></a>, the sender MUST use the contents of the [fault
!                             endpoint], when present, of the message being replied to to formulate
!                             the fault message. If this property is present, the [message id]
!                             property is REQUIRED.</p>
                      </dd>
                  
***************
*** 541,545 ****
                          <p>This specification has one predefined relationship type as shown in
                                  <a href="#predefrels">Table 3-1</a>.</p>
!                         <a name="predefrels"></a><br><table border="1" summary="Predefined [relationship] type values">
                              <caption>Table 3-1. Predefined [relationship] values</caption>
                              <tbody>
--- 537,541 ----
                          <p>This specification has one predefined relationship type as shown in
                                  <a href="#predefrels">Table 3-1</a>.</p>
!                         <a name="predefrels"></a><table border="1" summary="Predefined [relationship] type values">
                              <caption>Table 3-1. Predefined [relationship] values</caption>
                              <tbody>
***************
*** 685,688 ****
--- 681,696 ----
                      
                  </dl>
+                 <div class="div3">
+                     
+ <h4><a name="N103F5"></a>3.1.1 Comparing URIs</h4>
+                     <p>The values of the Message Addressing Properties [action], [message id],
+                         and [relationship] are absolute URIs.  The purpose of these URIs is
+                         primarily identification, rather than resource retrieval.  As such,
+                         simple string comparison, as indicated in Internationalized Resource
+                         Identifiers<cite><a href="#IRI">IETF RFC 3987</a></cite> section 5.3.1, is sufficient to determine equivalence
+                         of these URIs.</p>
+                        
+                 </div>
+                 
              </div>
              <div class="div2">
***************
*** 769,777 ****
                  <dt class="label"><a name="RFC2119"></a>[IETF RFC 2119] </dt><dd>
                      <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a></cite>,
!                     S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at
                      http://www.ietf.org/rfc/rfc2119.txt. </dd>
!                 <dt class="label"><a name="RFC2396"></a>[RFC 2396bis] </dt><dd>
                      T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
!                     W3C/MIT, July 2004. (See <cite><a href="http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt">http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt</a></cite>.)</dd>
                  <dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second Edition)</a></cite>, T.
--- 777,785 ----
                  <dt class="label"><a name="RFC2119"></a>[IETF RFC 2119] </dt><dd>
                      <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a></cite>,
!                     S. Bradner. Internet Engineering Task Force, June 1999. Available at
                      http://www.ietf.org/rfc/rfc2119.txt. </dd>
!                 <dt class="label"><a name="RFC2396"></a>[IETF RFC 3986] </dt><dd>
                      T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
!                     W3C/MIT, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt (See <cite><a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a></cite>.)</dd>
                  <dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second Edition)</a></cite>, T.
***************
*** 815,827 ****
                  <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd> OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>,
                      March 2004.</dd>
              </dl>
          </div>
      </div>
      <div class="back">
!         <div class="div1">
              
! <h2><a name="_Toc77464335"></a>A.  Acknowledgements  (Non-Normative)</h2>
!             <p>TBD</p>
!         </div>
          <div class="div1">
              
--- 823,850 ----
                  <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd> OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>,
                      March 2004.</dd>
+                 <dt class="label"><a name="IRI"></a>[IETF RFC 3987] </dt><dd>M. Duerst, M. Suignard, 
+                     "Internationalized Resource Identifiers (IRIs)", January 2005. Available at http://www.ietf.org/rfc/rfc3987. 
+                  (See <cite><a href="http://www.ietf.org/rfc/rfc3987">http://www.ietf.org/rfc/rfc3987</a></cite>.)</dd>
              </dl>
          </div>
      </div>
      <div class="back">
! 
              
! <div class="div1">
!   
! <h2><a name="acknowledgments"></a>A. Acknowledgements (Non-Normative)</h2>
!   <p>This document is the work of the <a href="http://www.w3.org/2002/ws/addr/">W3C Web Service
!       Addressing Working Group</a>.</p>
!   <p>Members of the Working Group are (at the time of writing, and by
!       alphabetical order):
!       Abbie Barbir (Nortel Networks), Rebecca Bergersen (IONA Technologies, Inc.), Andreas Bj&auml;rlestam (ERICSSON), Ugo Corda (SeeBeyond Technology Corporation), Francisco Curbera (IBM Corporation), Glen Daniels (Sonic Software), Paul Downey (BT), Jacques Durand (Fujitsu Limited), Michael Eder (Nokia), Robert Freund (Hitachi, Ltd.), Yaron Goland (BEA Systems, Inc.), Martin Gudgin (Microsoft Corporation), Arun Gupta (Sun Microsystems, Inc.), Hugo Haas (W3C/ERCIM), Marc Hadley (Sun Microsystems, Inc.), David Hull (TIBCO Software, Inc.), Yin-Leng Husband (HP), Anish Karmarkar (Oracle Corporation), Paul Knight (Nortel Networks), Philippe Le H&eacute;garet (W3C/MIT), Mark Little (Arjuna Technologies Ltd.), Jonathan Marsh (Microsoft Corporation), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (ERICSSON), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems, Inc.), Ales Novy (Systinet Inc.), David Orchard (BEA Systems, Inc.), Mark Peel (Novell, Inc.), Harris Reynolds (webMethods, Inc.), Tony Roges (Computer Associates), Tom Rutt (Fujitsu Limited), Rich Salz (DataPower Technology, Inc.), Davanum Srinivas (Computer Associates), Jiri Tejkl (Systinet Inc.), Greg Truty (IBM Corporation), Steve Vinoski (IONA Technologies, Inc.), Pete Wenzel (SeeBeyond Technology Corporation), Steve Winkler (SAP AG), &Uuml;mit Yal&ccedil;ınalp (SAP AG).</p>
!   <p>Previous members of the Working Group were: @@@.</p>
!   <p>The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-addressing/">discussions
!       on public-ws-addressing@w3.org</a> are also gratefully
!       acknowledged.</p>
! </div>
! 
! 
          <div class="div1">
              
***************
*** 829,838 ****
              <div class="div2">
                  
! <h3>B.1 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>B.2 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>
--- 852,861 ----
              <div class="div2">
                  
! <h3><a name="N10593"></a>B.1 Changes Since First Working Draft</h3>
!                 <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-15 @ 22:53</td><td>mhadley</td><td>Added resolution to issue 46</td></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><tdImproved 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="N1059D"></a>B.2 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.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** ws-addr-soap.html	1 Feb 2005 19:51:03 -0000	1.12
--- ws-addr-soap.html	15 Feb 2005 23:23:51 -0000	1.13
***************
*** 53,57 ****
              <a href="http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap">http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap</a>
          </dd><dt>Previous versions:</dt><dd>
!             
          </dd><dt>Editors:</dt>
              <dd>Martin Gudgin, Microsoft Corp</dd>
--- 53,57 ----
              <a href="http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap">http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap</a>
          </dd><dt>Previous versions:</dt><dd>
!             <a href="http://www.w3.org/TR/2004/WD-ws-addr-soap-20041208">http://www.w3.org/TR/2004/WD-ws-addr-soap-20041208</a>
          </dd><dt>Editors:</dt>
              <dd>Martin Gudgin, Microsoft Corp</dd>
***************
*** 66,72 ****
          no official standing.</strong></p><p></p></div>
      <hr><div class="toc">
! <h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#tocRange"> Introduction</a><br>2. <a href="#_Toc77464317">Binding Endpoint References</a><br>3. <a href="#_Toc77464328">Faults</a><br>4. <a href="#_Toc77464334"> Security Considerations</a><br>5. <a href="#_Toc77464336"> References</a><br>A. <a href="#_Toc77464335"> Acknowledgements </a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br></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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#_Toc77464315"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#_Toc77464316"> Namespaces</a><br>2. <a href="#_Toc77464317">Binding Endpoint References</a><br>3. <a href="#_Toc77464328">Faults</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#_Toc77464329"> Invalid Message Information Header</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#_Toc77464330"> Message Information Header Required</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#_Toc77464331"> Destination Unreachable</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#_Toc55895108"> Action Not Supported</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.5 <a href="#_Toc77464333"> Endpoint Unavailable</a><br>4. <a href="#_Toc77464334"> Security Considerations</a><br>5. <a href="#_Toc77464336"> References</a><br></p>
! <h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#_Toc77464335"> Acknowledgements </a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N103E3">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N103ED">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
--- 66,72 ----
          no official standing.</strong></p><p></p></div>
      <hr><div class="toc">
! <h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#tocRange"> Introduction</a><br>2. <a href="#_Toc77464317">Binding Endpoint References</a><br>3. <a href="#_Toc77464328">Faults</a><br>4. <a href="#_Toc77464334"> Security Considerations</a><br>5. <a href="#_Toc77464336"> References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br></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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#_Toc77464315"> Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#_Toc77464316"> Namespaces</a><br>2. <a href="#_Toc77464317">Binding Endpoint References</a><br>3. <a href="#_Toc77464328">Faults</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#_Toc77464329"> Invalid Message Information Property</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#_Toc77464330"> Message Information Property Required</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#_Toc77464331"> Destination Unreachable</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#_Toc55895108"> Action Not Supported</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.5 <a href="#_Toc77464333"> Endpoint Unavailable</a><br>4. <a href="#_Toc77464334"> Security Considerations</a><br>5. <a href="#_Toc77464336"> References</a><br></p>
! <h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B. <a href="#changelog">Change Log</a> (Non-Normative)<br>&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#N103FC">Changes Since First Working Draft</a><br>&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#N10406">Changes Since Submission</a><br></p></div><hr><div class="body">
          <div class="div1">
              
***************
*** 78,82 ****
                  abstract properties defined in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
              <p>The following example illustrates the use of these mechanisms in a SOAP 1.2 message
!                 being sent from http://example.com/business/client1 to http://example.com/fabrikam/Purchasing:</p>
              <div class="exampleOuter">
                  <p class="exampleHead" style="text-align: left"><i><span>Example 1-1. </span>Use of message addressing properties in a SOAP 1.2 message.</i></p>
--- 78,83 ----
                  abstract properties defined in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
              <p>The following example illustrates the use of these mechanisms in a SOAP 1.2 message
!                 being sent from http://example.com/business/client1 to
!                 http://example.com/fabrikam/Purchasing:</p>
              <div class="exampleOuter">
                  <p class="exampleHead" style="text-align: left"><i><span>Example 1-1. </span>Use of message addressing properties in a SOAP 1.2 message.</i></p>
***************
*** 102,111 ****
                      mechanisms defined in the specification are used. The body is represented by
                      lines (012) to (014).</p>
!                 <p>Lines (003) to (010) contain the message information header blocks. Specifically,
!                     lines (003) to (005) specify the identifier for this message and lines (006) to
!                     (008) specify the endpoint to which replies to this message should be sent as an
!                     Endpoint Reference. Line (009) specifies the address URI of the ultimate
!                     receiver of this message. Line (010) specifies an Action URI identifying
!                     expected semantics.</p>
              </div>
              <div class="div2">
--- 103,112 ----
                      mechanisms defined in the specification are used. The body is represented by
                      lines (012) to (014).</p>
!                 <p>Lines (003) to (010) contain the message information properties serialized as
!                     SOAP header blocks. Specifically, lines (003) to (005) specify the identifier
!                     for this message and lines (006) to (008) specify the endpoint to which replies
!                     to this message should be sent as an Endpoint Reference. Line (009) specifies
!                     the address URI of the ultimate receiver of this message. Line (010) specifies
!                     an Action URI identifying expected semantics.</p>
              </div>
              <div class="div2">
***************
*** 117,121 ****
                  <p>When describing abstract data models, this specification uses the notational
                      convention used by XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically,
!                     abstract property names always appear in square brackets (e.g., [some property]).</p>
                  <p>When describing concrete XML schemas [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>, <cite><a href="#XMLSchemaP2">XML Schema Datatypes</a></cite>], this specification uses the notational convention of
                      WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. Specifically, each member of an
--- 118,123 ----
                  <p>When describing abstract data models, this specification uses the notational
                      convention used by XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically,
!                     abstract property names always appear in square brackets (e.g., [some
!                     property]).</p>
                  <p>When describing concrete XML schemas [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>, <cite><a href="#XMLSchemaP2">XML Schema Datatypes</a></cite>], this specification uses the notational convention of
                      WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. Specifically, each member of an
***************
*** 123,127 ****
                      notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates
                      the presence of an element wildcard (&lt;xs:any/&gt;). The use of @{any}
!                     indicates the presence of an attribute wildcard (&lt;xs:anyAttribute/&gt;).</p>
              </div>
              <div class="div2">
--- 125,130 ----
                      notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates
                      the presence of an element wildcard (&lt;xs:any/&gt;). The use of @{any}
!                     indicates the presence of an attribute wildcard
!                     (&lt;xs:anyAttribute/&gt;).</p>
              </div>
              <div class="div2">
***************
*** 131,135 ****
                      listed in <a href="#nsrefs">Table 1-1</a>. Note that the choice of any namespace prefix
                      is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite> ]).</p>
!                 <a name="nsrefs"></a><br><table border="1" summary="Namespace prefixes usage in this specification">
                      <caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
                      <tbody>
--- 134,138 ----
                      listed in <a href="#nsrefs">Table 1-1</a>. Note that the choice of any namespace prefix
                      is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite> ]).</p>
!                 <a name="nsrefs"></a><table border="1" summary="Namespace prefixes usage in this specification">
                      <caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
                      <tbody>
***************
*** 181,185 ****
                  the absence of an applicable policy stating that a different mapping must be used,
                  the SOAP binding defined here is assumed to apply. To ensure interoperability with a
!                 broad range of devices, all conformant implementations MUST support the SOAP binding.</p>
              <p>The SOAP binding for endpoint references is defined by the following three rules:</p>
              <ul>
--- 184,189 ----
                  the absence of an applicable policy stating that a different mapping must be used,
                  the SOAP binding defined here is assumed to apply. To ensure interoperability with a
!                 broad range of devices, all conformant implementations MUST support the SOAP
!                 binding.</p>
              <p>The SOAP binding for endpoint references is defined by the following three rules:</p>
              <ul>
***************
*** 190,206 ****
                  </li>
                  <li>
!                     <p>Each 
! 
!                         [reference parameter] element becomes a header
!                         block in the SOAP message. The element information item of each 
! 
!                         [reference parameter] (including all of its [children],
!                         [attributes] and [in-scope namespaces]) is to be added as a header block in
!                         the new message.</p>
                  </li>
- 				<li>
- 				  <p>Each header block added as a result of the above rule is annotated with a wsa:Type attribute whose value is "parameter".
- 				  </p>
- 				</li>
              </ul>
              <p>The next example shows how the default SOAP binding for endpoint references is used
--- 194,206 ----
                  </li>
                  <li>
!                     <p>Each [reference parameter] element becomes a header block in the SOAP
!                         message. The element information item of each [reference parameter]
!                         (including all of its [children], [attributes] and [in-scope namespaces]) is
!                         added as a header block in the new message.</p>
!                 </li>
!                 <li>
!                     <p>Each header block added as a result of the above rule is annotated with a
!                         wsa:Type attribute whose value is "parameter". </p>
                  </li>
              </ul>
              <p>The next example shows how the default SOAP binding for endpoint references is used
***************
*** 212,216 ****
       xmlns:wsa="http://www.w3.org/@@@@/@@/addressing"
       xmlns:fabrikam="http://example.com/fabrikam"
!      xmlns:wsdli="http://www.w3.org/@@@@/@@/wsdl-instance"
       wsdli:wsdlLocation="http://example.com/fabrikam
         http://example.com/fabrikam/fabrikam.wsdl"&gt;
--- 212,216 ----
       xmlns:wsa="http://www.w3.org/@@@@/@@/addressing"
       xmlns:fabrikam="http://example.com/fabrikam"
!      xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
       wsdli:wsdlLocation="http://example.com/fabrikam
         http://example.com/fabrikam/fabrikam.wsdl"&gt;
***************
*** 252,259 ****
              <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 required message information
!                 headers on all fault messages. Fault messages are correlated as replies using the
!                 [relationship] property as defined in Section 3. The [action] property below
!                 designates WS-Addressing fault messages:</p>
              <div class="exampleInner"><pre>
  http://www.w3.org/@@@@/@@/addressing/fault
--- 252,259 ----
              <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
!                 information properties serialized as SOAP headers in all fault messages. Fault
!                 messages are correlated as replies using the [relationship] property as defined in
!                 Section 3. The [action] property below designates WS-Addressing fault messages:</p>
              <div class="exampleInner"><pre>
  http://www.w3.org/@@@@/@@/addressing/fault
***************
*** 311,337 ****
              <div class="div2">
                  
! <h3><a name="_Toc77464329"></a>3.1  Invalid Message Information Header</h3>
!                 <p>A message information header cannot be processed.</p>
                  <p> [Code] S:Sender</p>
!                 <p> [Subcode] wsa:InvalidMessageInformationHeader</p>
!                 <p> [Reason] A message information header is not valid and the message cannot be
                      processed. The validity failure can be either structural or semantic, e.g. a
                      [destination] that is not a URI or a [relationship] to a [message id] that was
                      never issued.</p>
!                 <p> [Detail] [invalid header]</p>
              </div>
              <div class="div2">
                  
! <h3><a name="_Toc77464330"></a>3.2  Message Information Header Required</h3>
!                 <p>A required message information header is absent.</p>
                  <p> [Code] S:Sender</p>
!                 <p> [Subcode] wsa:MessageInformationHeaderRequired</p>
!                 <p> [Reason] A required message information header, To, MessageID, or Action, is not present.</p>
!                 <p> [Detail] [Missing Header QName]</p>
              </div>
              <div class="div2">
                  
  <h3><a name="_Toc77464331"></a>3.3  Destination Unreachable</h3>
!                 <p>No endpoint can be found capable of acting in the role of the [destination] property.</p>
                  <p> [Code] S:Sender</p>
                  <p> [Subcode] wsa:DestinationUnreachable</p>
--- 311,339 ----
              <div class="div2">
                  
! <h3><a name="_Toc77464329"></a>3.1  Invalid Message Information Property</h3>
!                 <p>A message information property cannot be processed.</p>
                  <p> [Code] S:Sender</p>
!                 <p> [Subcode] wsa:InvalidMessageInformationProperty</p>
!                 <p> [Reason] A message information property is not valid and the message cannot be
                      processed. The validity failure can be either structural or semantic, e.g. a
                      [destination] that is not a URI or a [relationship] to a [message id] that was
                      never issued.</p>
!                 <p> [Detail] [invalid property]</p>
              </div>
              <div class="div2">
                  
! <h3><a name="_Toc77464330"></a>3.2  Message Information Property Required</h3>
!                 <p>A required message information property is absent.</p>
                  <p> [Code] S:Sender</p>
!                 <p> [Subcode] wsa:MessageInformationPropertyRequired</p>
!                 <p> [Reason] A required message information property, To, MessageID, or Action, is not
!                     present.</p>
!                 <p> [Detail] [Missing Property QName]</p>
              </div>
              <div class="div2">
                  
  <h3><a name="_Toc77464331"></a>3.3  Destination Unreachable</h3>
!                 <p>No endpoint can be found capable of acting in the role of the [destination]
!                     property.</p>
                  <p> [Code] S:Sender</p>
                  <p> [Subcode] wsa:DestinationUnreachable</p>
***************
*** 360,364 ****
                  <p> [Subcode] wsa:EndpointUnavailable</p>
                  <p> [Reason] The endpoint is unable to process the message at this time.</p>
!                 <p> [Detail] &lt;wsa:RetryAfter ...&gt;[xs:NonNegativeInteger]&lt;/wsa:RetryAfter&gt;</p>
                  <p> The following describes the attributes and elements listed above:</p>
                  <dl>
--- 362,367 ----
                  <p> [Subcode] wsa:EndpointUnavailable</p>
                  <p> [Reason] The endpoint is unable to process the message at this time.</p>
!                 <p> [Detail] &lt;wsa:RetryAfter
!                     ...&gt;[xs:NonNegativeInteger]&lt;/wsa:RetryAfter&gt;</p>
                  <p> The following describes the attributes and elements listed above:</p>
                  <dl>
***************
*** 368,372 ****
                              <p>This element (of type xs:NonNegativeInteger) is a suggested minimum
                                  duration in milliseconds to wait before retransmitting the message.
!                                 If this element is omitted from the detail, the value is infinite.</p>
                          </dd>
                      
--- 371,376 ----
                              <p>This element (of type xs:NonNegativeInteger) is a suggested minimum
                                  duration in milliseconds to wait before retransmitting the message.
!                                 If this element is omitted from the detail, the value is
!                             infinite.</p>
                          </dd>
                      
***************
*** 388,395 ****
                  the mechanisms described in WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. In order to
                  properly secure messages, the body and all relevant headers need to be included in
!                 the signature. Specifically, the message information headers described in this
                  specification (e.g. &lt;wsa:To&gt;) need to be signed with the body in order
                  to "bind" the two together. It should be noted that for messages traveling through
!                 intermediaries, it is possible that some or all of the message information headers
                  may have multiple signatures when the message arrives at the ultimate receiver. It
                  is strongly recommended that the initial sender include a signature to prevent any
--- 392,399 ----
                  the mechanisms described in WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. In order to
                  properly secure messages, the body and all relevant headers need to be included in
!                 the signature. Specifically, the message information property headers described in this
                  specification (e.g. &lt;wsa:To&gt;) need to be signed with the body in order
                  to "bind" the two together. It should be noted that for messages traveling through
!                 intermediaries, it is possible that some or all of the message information property headers
                  may have multiple signatures when the message arrives at the ultimate receiver. It
                  is strongly recommended that the initial sender include a signature to prevent any
***************
*** 399,407 ****
                  ensure that a signature is provided with claims allowing it to speak for the
                  specified target in order to prevent certain classes of attacks (e.g. redirects). As
!                 well, care should be taken if the specified endpoint contains reference 
! 
! 				parameters as unverified endpoint references could cause certain classes of
!                 header insertion attacks.</p>
!             <p>The message information headers blocks may have their contents encrypted in order to
                  obtain end-to-end privacy, but care should be taken to ensure that intermediary
                  processors have access to required information (e.g. &lt;wsa:To&gt;).</p>
--- 403,410 ----
                  ensure that a signature is provided with claims allowing it to speak for the
                  specified target in order to prevent certain classes of attacks (e.g. redirects). As
!                 well, care should be taken if the specified endpoint contains reference
!                 parameters as unverified
!                 endpoint references could cause certain classes of header insertion attacks.</p>
!             <p>The message information property header blocks may have their contents encrypted in order to
                  obtain end-to-end privacy, but care should be taken to ensure that intermediary
                  processors have access to required information (e.g. &lt;wsa:To&gt;).</p>
***************
*** 490,496 ****
                      S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at
                      http://www.ietf.org/rfc/rfc2119.txt. </dd>
!                 <dt class="label"><a name="RFC2396"></a>[RFC 2396bis] </dt><dd>
!                     T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
!                     W3C/MIT, July 2004. (See <cite><a href="http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt">http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt</a></cite>.)</dd>
                  <dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second Edition)</a></cite>, T.
--- 493,499 ----
                      S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at
                      http://www.ietf.org/rfc/rfc2119.txt. </dd>
!                 <dt class="label"><a name="RFC2396"></a>[RFC 3986] </dt><dd> T.
!                     Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
!                     W3C/MIT, January 2005. (See <cite><a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a></cite>.)</dd>
                  <dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second Edition)</a></cite>, T.
***************
*** 504,513 ****
                      Information Set Recommendation is
                      http://www.w3.org/TR/1999/REC-xml-names-19990114. The <a href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
!                     XML</a> is available at http://www.w3.org/TR/REC-xml-names. </dd>
                  <dt class="label"><a name="XMLInfoSet"></a>[XML Information Set] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, J. Cowan and R. Tobin, Editors. World
                      Wide Web Consortium, 24 October 2001. This version of the XML Information Set
                      Recommendation is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The <a href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
!                     Set</a> is available at http://www.w3.org/TR/xml-infoset. </dd>
                  <dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Structures] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>, H. Thompson, D. Beech, M.
--- 507,516 ----
                      Information Set Recommendation is
                      http://www.w3.org/TR/1999/REC-xml-names-19990114. The <a href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
!                         XML</a> is available at http://www.w3.org/TR/REC-xml-names. </dd>
                  <dt class="label"><a name="XMLInfoSet"></a>[XML Information Set] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, J. Cowan and R. Tobin, Editors. World
                      Wide Web Consortium, 24 October 2001. This version of the XML Information Set
                      Recommendation is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The <a href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
!                         Set</a> is available at http://www.w3.org/TR/xml-infoset. </dd>
                  <dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Structures] </dt><dd>
                      <cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>, H. Thompson, D. Beech, M.
***************
*** 530,559 ****
                          1.2 Part 1: Messaging Framework"</a> is available at
                      http://www.w3.org/TR/soap12-part1/. </dd>
!                 <dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>E. Christensen, et al,
!                         <cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</a></cite>, March 2001.</dd>
                  <dt class="label"><a name="SOAP11"></a>[SOAP 1.1] </dt><dd>Don Box, et al,
                          <cite><a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object Access Protocol (SOAP) 1.1</a></cite>, May 2000.</dd>
!                 <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd>
!                     OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>, March 2004.</dd>
              </dl>
          </div>
      </div>
!     <div class="back">
!         <div class="div1">
!             
! <h2><a name="_Toc77464335"></a>A.  Acknowledgements  (Non-Normative)</h2>
!             <p>TBD</p>
!         </div>
!         <div class="div1">
              
  <h2><a name="changelog"></a>B. Change Log (Non-Normative)</h2>
              <div class="div2">
                  
! <h3>B.1 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>B.2 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>
--- 533,570 ----
                          1.2 Part 1: Messaging Framework"</a> is available at
                      http://www.w3.org/TR/soap12-part1/. </dd>
!                 <dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>E. Christensen, et al, <cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL)
!                     1.1</a></cite>, March 2001.</dd>
                  <dt class="label"><a name="SOAP11"></a>[SOAP 1.1] </dt><dd>Don Box, et al,
                          <cite><a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object Access Protocol (SOAP) 1.1</a></cite>, May 2000.</dd>
!                 <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd> OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>,
!                     March 2004.</dd>
              </dl>
          </div>
      </div>
!     <div class="back"> 
! <div class="div1">
!   
! <h2><a name="acknowledgments"></a>A. Acknowledgements (Non-Normative)</h2>
!   <p>This document is the work of the <a href="http://www.w3.org/2002/ws/addr/">W3C Web Service
!       Addressing Working Group</a>.</p>
!   <p>Members of the Working Group are (at the time of writing, and by
!       alphabetical order):
!       Abbie Barbir (Nortel Networks), Rebecca Bergersen (IONA Technologies, Inc.), Andreas Bj&auml;rlestam (ERICSSON), Ugo Corda (SeeBeyond Technology Corporation), Francisco Curbera (IBM Corporation), Glen Daniels (Sonic Software), Paul Downey (BT), Jacques Durand (Fujitsu Limited), Michael Eder (Nokia), Robert Freund (Hitachi, Ltd.), Yaron Goland (BEA Systems, Inc.), Martin Gudgin (Microsoft Corporation), Arun Gupta (Sun Microsystems, Inc.), Hugo Haas (W3C/ERCIM), Marc Hadley (Sun Microsystems, Inc.), David Hull (TIBCO Software, Inc.), Yin-Leng Husband (HP), Anish Karmarkar (Oracle Corporation), Paul Knight (Nortel Networks), Philippe Le H&eacute;garet (W3C/MIT), Mark Little (Arjuna Technologies Ltd.), Jonathan Marsh (Microsoft Corporation), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (ERICSSON), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems, Inc.), Ales Novy (Systinet Inc.), David Orchard (BEA Systems, Inc.), Mark Peel (Novell, Inc.), Harris Reynolds (webMethods, Inc.), Tony Roges (Computer Associates), Tom Rutt (Fujitsu Limited), Rich Salz (DataPower Technology, Inc.), Davanum Srinivas (Computer Associates), Jiri Tejkl (Systinet Inc.), Greg Truty (IBM Corporation), Steve Vinoski (IONA Technologies, Inc.), Pete Wenzel (SeeBeyond Technology Corporation), Steve Winkler (SAP AG), &Uuml;mit Yal&ccedil;ınalp (SAP AG).</p>
!   <p>Previous members of the Working Group were: @@@.</p>
!   <p>The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-addressing/">discussions
!       on public-ws-addressing@w3.org</a> are also gratefully
!       acknowledged.</p>
! </div>
!  <div class="div1">
              
  <h2><a name="changelog"></a>B. Change Log (Non-Normative)</h2>
              <div class="div2">
                  
! <h3><a name="N103FC"></a>B.1 Changes Since First Working Draft</h3>
!                 <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></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><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 isue 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="N10406"></a>B.2 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 Tuesday, 15 February 2005 23:23:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:01 UTC