- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 22 Apr 2005 20:17:48 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv30832
Modified Files:
ws-addr-core.html ws-addr-soap.html
Log Message:
Updated to reflect changes in XML
Index: ws-addr-core.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.html,v
retrieving revision 1.23
retrieving revision 1.24
diff -C2 -d -r1.23 -r1.24
*** ws-addr-core.html 22 Mar 2005 16:22:02 -0000 1.23
--- ws-addr-core.html 22 Apr 2005 20:17:46 -0000 1.24
***************
*** 70,78 ****
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="#msgaddrpropsinfoset">XML Infoset Representation of Message Addressing Properties</a><br> 3.11 <a href="#compiri">Comparing IRIs</a><br> 3.2 <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 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> B.1 <a href="#N105EB">Changes Since Second Working Draft</a><br> B.2 <a href="#N105F5">Changes Since First Working Draft</a><br> B.3 <a href="#N105FF">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
! <h2><a name="tocRange"></a>1. Introduction</h2>
<p>Web Services Addressing (WS-Addressing) defines two constructs, message addressing
properties and endpoint references, that normalize the information typically
--- 70,78 ----
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="#msgaddrpropsinfoset">XML Infoset Representation of Message Addressing Properties</a><br> 3.1.1 <a hrf="#compiri">Comparing IRIs</a><br> 3.2 <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 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> B.1 <a href="#N105E3">Changes Since Second Working Draft</a><br> B.2 <a href="#N105ED">Changes Since First Working Draft</a><br> B.3 <a href="#N105F7">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
! <h2><a name="tocRange"></a>1. Introduction</h2>
<p>Web Services Addressing (WS-Addressing) defines two constructs, message addressing
properties and endpoint references, that normalize the information typically
***************
*** 98,128 ****
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
(002) <S:Header>
! (003) <wsa:MessageID>
! (004) http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA
! (005) </wsa:MessageID>
! (006) <wsa:ReplyTo>
! (007) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (008) </wsa:ReplyTo>
! (009) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (010) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (011) </S:Header>
! (012) <S:Body>
! (013) ...
! (014) </S:Body>
! (015) </S:Envelope>
</pre></div>
! <p>Lines (002) to (011) represent the header of the SOAP message where the
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 IRI identifying
expected semantics.</p>
</div>
<div class="div2">
! <h3><a name="notation"></a>1.1 Notational Conventions</h3>
<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
--- 98,126 ----
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
(002) <S:Header>
! (003) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (004) <wsa:ReplyTo>
! (005) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (006) </wsa:ReplyTo>
! (007) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (008) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (009) </S:Header>
! (010) <S:Body>
! (011) ...
! (012) </S:Body>
! (013) </S:Envelope>
</pre></div>
! <p>Lines (002) to (009) represent the header of the SOAP message where the
mechanisms defined in the specification are used. The body is represented by
! lines (010) to (012).</p>
! <p>Lines (003) to (008) contain the message information header blocks. Specifically,
! line (002) specifies the identifier for this message and lines (004) to (006)
! specify the endpoint to which replies to this message should be sent as an
! Endpoint Reference. Line (007) specifies the address URI of the ultimate
! receiver of this message. Line (008) specifies an action URI identifying
expected semantics.</p>
</div>
<div class="div2">
! <h3><a name="notation"></a>1.1 Notational Conventions</h3>
<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
***************
*** 142,146 ****
<div class="div2">
! <h3><a name="namespaces"></a>1.2 Namespaces</h3>
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <a href="#nsprefix">Table 1-1</a>. Note that the choice of any namespace
--- 140,144 ----
<div class="div2">
! <h3><a name="namespaces"></a>1.2 Namespaces</h3>
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <a href="#nsprefix">Table 1-1</a>. Note that the choice of any namespace
***************
*** 159,166 ****
</tr>
<tr>
- <td rowspan="1" colspan="1">S11</td>
- <td rowspan="1" colspan="1">http://schemas.xmlsoap.org/soap/envelope</td>
- </tr>
- <tr>
<td rowspan="1" colspan="1">wsa</td>
<td rowspan="1" colspan="1">http://www.w3.org/@@@@/@@/addressing</td>
--- 157,160 ----
***************
*** 186,190 ****
<div class="div1">
! <h2><a name="eprs"></a>2. Endpoint References</h2>
<p>This section defines the information model and syntax of an endpoint reference.</p>
<p> This specification introduces the endpoint reference, a construct designed to
--- 180,184 ----
<div class="div1">
! <h2><a name="eprs"></a>2. Endpoint References</h2>
<p>This section defines the information model and syntax of an endpoint reference.</p>
<p> This specification introduces the endpoint reference, a construct designed to
***************
*** 211,215 ****
<div class="div2">
! <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>
--- 205,209 ----
<div class="div2">
! <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>
***************
*** 217,221 ****
<dt class="label"> [address] : IRI (mandatory)</dt>
<dd>
! <p>An address IRI for the endpoint.</p>
</dd>
--- 211,215 ----
<dt class="label"> [address] : IRI (mandatory)</dt>
<dd>
! <p>An absolute IRI representing the address of the endpoint.</p>
</dd>
***************
*** 225,240 ****
<p>A reference may contain a number of individual parameters which are
associated with the endpoint to facilitate a particular interaction.
! Reference parameters are element information items that are named by
! QName and are required to properly interact with the endpoint.
! Reference parameters are also provided by the issuer of the endpoint
! reference and are otherwise assumed to be opaque to consuming
! applications. The use of reference parameters is dependent upon the
! protocol binding and data encoding used to interact with the
! endpoint. Web Services Addressing 1.0 - SOAP Binding[<cite><a href="#WSADDR-SOAP">WS-Addressing-SOAP</a></cite>]
! describes the default binding for the SOAP protocol. </p>
</dd>
! <dt class="label"> [metadata] : xsd:any (0..unbounded)</dt>
<dd>
<p>A reference may contain metadata that describes the behavior,
--- 219,234 ----
<p>A reference may contain a number of individual parameters which are
associated with the endpoint to facilitate a particular interaction.
! Reference parameters are namespace-qualified element information
! items that are required to properly interact with the endpoint.
! Reference parameters are provided by the issuer of the endpoint
! reference and are assumed to be opaque to consuming applications.
! The binding of reference parameters to messages depends upon the
! protocol binding used to interact with the endpoint -
! Web Services Addressing 1.0 - SOAP Binding[<cite><a href="#WSADDR-SOAP">WS-Addressing-SOAP</a></cite>] describes the
! default binding for the SOAP protocol. </p>
</dd>
! <dt class="label"> [metadata] : xs:any (0..unbounded)</dt>
<dd>
<p>A reference may contain metadata that describes the behavior,
***************
*** 243,251 ****
consuming application, or because the metadata was dynamically
generated.</p>
! <p>The metadata embedded in each of the EPRs MAY differ, as the metadata
! carried by an EPR is not necessarily a complete statement of the
! metadata pertaining to the endpoint. Moreover, while embedded
! metadata is necessarily valid at the time the EPR is initially
! created it may become stale at a later point in time.</p>
<p>To deal with conflicts between the embedded metadata of two EPRs, or
between embedded metadata and metadata obtained from a different
--- 237,244 ----
consuming application, or because the metadata was dynamically
generated.</p>
! <p>The metadata embedded in an EPR is not necessarily a complete
! statement of the metadata pertaining to the endpoint.Moreover, while
! embedded metadata is necessarily valid at the time the EPR is
! initially created it may become stale at a later point in time.</p>
<p>To deal with conflicts between the embedded metadata of two EPRs, or
between embedded metadata and metadata obtained from a different
***************
*** 261,265 ****
<div class="div2">
! <h3><a name="eprinfoset"></a>2.2 Endpoint Reference XML Infoset Representation</h3>
<p>This section defines an XML Infoset-based representation for an endpoint
reference as both an XML type (wsa:EndpointReferenceType) and as an XML element
--- 254,258 ----
<div class="div2">
! <h3><a name="eprinfoset"></a>2.2 Endpoint Reference XML Infoset Representation</h3>
<p>This section defines an XML Infoset-based representation for an endpoint
reference as both an XML type (wsa:EndpointReferenceType) and as an XML element
***************
*** 267,282 ****
<p>The wsa:EndpointReferenceType type is used wherever a Web service endpoint is
referenced. The following describes the contents of this type:</p>
! <div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 2-1. </span>Structure of the wsa:EndpointReference element.</i></p>
! <div class="exampleInner"><pre>
! <wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
-
<wsa:ReferenceParameters>... </wsa:ReferenceParameters> ?
<wsa:Metadata> ... </wsa:Metadata>?
! <xs:any/>*
! </wsa:EndpointReference>
! </pre></div>
! </div>
<p>The following describes the attributes and elements listed in the schema overview
above:</p>
--- 260,268 ----
<p>The wsa:EndpointReferenceType type is used wherever a Web service endpoint is
referenced. The following describes the contents of this type:</p>
! <div class="exampleInner"><pre><wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceParameters>... </wsa:ReferenceParameters> ?
<wsa:Metadata> ... </wsa:Metadata>?
! </wsa:EndpointReference></pre></div>
<p>The following describes the attributes and elements listed in the schema overview
above:</p>
***************
*** 306,310 ****
-
<dt class="label"> /wsa:EndpointReference/wsa:ReferenceParameters</dt>
<dd>
--- 292,295 ----
***************
*** 323,327 ****
<dt class="label"> /wsa:EndpointReference/wsa:ReferenceParameters/{any}</dt>
<dd>
! <p>Each element information item of found in [reference parameters]
(including all of its [children], [attributes] and [in-scope
namespaces]) is represented as is.</p>
--- 308,312 ----
<dt class="label"> /wsa:EndpointReference/wsa:ReferenceParameters/{any}</dt>
<dd>
! <p>Each element information item found in [reference parameters]
(including all of its [children], [attributes] and [in-scope
namespaces]) is represented as is.</p>
***************
*** 367,373 ****
</dl>
<p>The following shows an example endpoint reference. This element references the
! the endpoint at the IRI "http://example.com/www.fabrikam/acct".</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 2-2. </span>Example endpoint reference.</i></p>
<div class="exampleInner"><pre>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
--- 352,358 ----
</dl>
<p>The following shows an example endpoint reference. This element references the
! the endpoint at the URI "http://example.com/www.fabrikam/acct".</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 2-1. </span>Example endpoint reference.</i></p>
<div class="exampleInner"><pre>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
***************
*** 379,383 ****
<div class="div2">
! <h3><a name="eprcomp"></a>2.3 Endpoint Reference Comparison</h3>
<p>This specification provides no concept of endpoint identity and therefore does
not provide any mechanism to determine equality or inequality of EPRs and does
--- 364,368 ----
<div class="div2">
! <h3><a name="eprcomp"></a>2.3 Endpoint Reference Comparison</h3>
<p>This specification provides no concept of endpoint identity and therefore does
not provide any mechanism to determine equality or inequality of EPRs and does
***************
*** 397,401 ****
<h3><a name="eprextensibility"></a>2.5 Endpoint Reference Extensibility</h3>
! <p>As noted in <a href="#eprinfoset"><b>2.2 Endpoint Reference XML Infoset Representation</b></a> endpoint references are extensible. When
extension attributes or elements appear as part of an endpoint reference, the
processing model for such extensions is defined by the specification for those
--- 382,386 ----
<h3><a name="eprextensibility"></a>2.5 Endpoint Reference Extensibility</h3>
! <p>As noted in <a href="#eprinfoset"><b>2.2 Endpoint Reference XML Infoset Representation</b></a> endpoint references are extensible. When
extension attributes or elements appear as part of an endpoint reference, the
processing model for such extensions is defined by the specification for those
***************
*** 403,412 ****
such extensions that it does not recognise or understand.</p>
<p>Extension elements and attributes MAY add additional properties to an endpoint
! reference in addition to those specified in <a href="#eprinfomodel"><b>2.1 Information Model for Endpoint References</b></a>.
Endpoint reference extensions MAY modify the value of one or more existing
properties of an endpoint reference. Extensions MAY modify the rules for binding
endpoint reference properties to message addressing properties, or otherwise
indicate that a different binding be used. </p>
! <p>Note that this ability to modify existing properties and binding behaviour, when
coupled with the fact that software can ignore unknown or unrecognised
extensions, may result in a difference in behaviour depending on whether such an
--- 388,397 ----
such extensions that it does not recognise or understand.</p>
<p>Extension elements and attributes MAY add additional properties to an endpoint
! reference in addition to those specified in <a href="#eprinfomodel"><b>2.1 Information Model for Endpoint References</b></a>.
Endpoint reference extensions MAY modify the value of one or more existing
properties of an endpoint reference. Extensions MAY modify the rules for binding
endpoint reference properties to message addressing properties, or otherwise
indicate that a different binding be used. </p>
! <p>Note that this ability to modify existing properties and binding behavior, when
coupled with the fact that software can ignore unknown or unrecognised
extensions, may result in a difference in behaviour depending on whether such an
***************
*** 419,425 ****
<div class="div1">
! <h2><a name="msgaddrprops"></a>3. Message Addressing Properties</h2>
<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
--- 404,420 ----
<div class="div1">
! <h2><a name="msgaddrprops"></a>3. Message Addressing Properties</h2>
<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 interaction is in
***************
*** 429,448 ****
and interfaces; business processes and e-commerce specifications, among others, can
also be used to define explicit contracts between the parties.</p>
!
! <p> The basic interaction
! pattern from which all others are composed is "one way". In this pattern a source
! sends a message to a destination without any further definition of the interaction.
! "Request Reply" is a common interaction pattern that consists of an initial message
! sent by a source endpoint (the request) and a subsequent message sent from the
! destination of the request back to the source (the reply). A reply in this case can
! be either an application message, a fault, or any other message. Note, however, that
! reply messages may be sent as part of other message exchanges as well, and are not
! restricted to the usual single Request, single Reply pattern, or to a particular
! WSDL MEP. The contract between the interacting parties may specify that multiple or
! even a variable number or replies be delivered. </p>
! <p> The set of message addressing properties defined in this specification
! is sufficient for many simple variations of one-way and request-reply
! MEPs. More advanced MEPs may require additional message addressing
! properties to augment the facilities provided here. </p>
<p>Message addressing properties collectively augment a message with the following
abstract properties to support one way, request reply, and other interaction
--- 424,442 ----
and interfaces; business processes and e-commerce specifications, among others, can
also be used to define explicit contracts between the parties.</p>
! <p> The basic interaction pattern from which all others are composed is "one way". In
! this pattern a source sends a message to a destination without any further
! definition of the interaction. "Request Reply" is a common interaction pattern that
! consists of an initial message sent by a source endpoint (the request) and a
! subsequent message sent from the destination of the request back to the source (the
! reply). A reply in this case can be either an application message, a fault, or any
! other message. Note, however, that reply messages may be sent as part of other
! message exchanges as well, and are not restricted to the usual single Request,
! single Reply pattern, or to a particular WSDL MEP. The contract between the
! interacting parties may specify that multiple or even a variable number of replies
! be delivered. </p>
! <p> The set of message addressing properties defined in this specification is sufficient
! for many simple variations of one-way and request-reply MEPs. More advanced MEPs may
! require additional message addressing properties to augment the facilities provided
! here. </p>
<p>Message addressing properties collectively augment a message with the following
abstract properties to support one way, request reply, and other interaction
***************
*** 452,456 ****
<dt class="label"> [destination] : IRI (mandatory)</dt>
<dd>
! <p>The address of the intended receiver of this message.</p>
</dd>
--- 446,451 ----
<dt class="label"> [destination] : IRI (mandatory)</dt>
<dd>
! <p>An absolute IRI representing the address of the intended receiver of this
! message.</p>
</dd>
***************
*** 467,471 ****
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>.
If this property is present, the [message id] property is REQUIRED.</p>
</dd>
--- 462,466 ----
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>.
If this property is present, the [message id] property is REQUIRED.</p>
</dd>
***************
*** 475,482 ****
<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>
--- 470,477 ----
<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 formulate the
! fault message. If this property is present, the [message id] property is
! REQUIRED.</p>
</dd>
***************
*** 484,489 ****
<dt class="label"> [action] : IRI (mandatory)</dt>
<dd>
! <p>An identifier that uniquely identifies the semantics
! implied by this message.</p>
<p>It is RECOMMENDED that the value of the [action] property is an IRI
identifying an input, output, or fault message within a WSDL port type.
--- 479,484 ----
<dt class="label"> [action] : IRI (mandatory)</dt>
<dd>
! <p>An absolute IRI that uniquely identifies the semantics implied by this
! message.</p>
<p>It is RECOMMENDED that the value of the [action] property is an IRI
identifying an input, output, or fault message within a WSDL port type.
***************
*** 495,501 ****
<dt class="label"> [message id] : IRI (0..1)</dt>
<dd>
! <p>An IRI that uniquely identifies this message in time and space. No two
! messages with a distinct application intent may share a [message id]
! property. A message MAY be retransmitted for any purpose including
communications failure and MAY use the same [message id] property. The
value of this property is an opaque IRI whose interpretation beyond
--- 490,496 ----
<dt class="label"> [message id] : IRI (0..1)</dt>
<dd>
! <p>An absolute IRI that uniquely identifies this message in time and space.
! No two messages with a distinct application intent may share a [message
! id] property. A message MAY be retransmitted for any purpose including
communications failure and MAY use the same [message id] property. The
value of this property is an opaque IRI whose interpretation beyond
***************
*** 508,516 ****
<dd>
<p>A pair of values that indicate how this message relates to another
! message. The type of the relationship is identified by an IRI. The
! related message is identified by an IRI that corresponds to the related
! message's [message id] property. The message identifier IRI may refer to
! a specific message, or be the following well-known IRI that means
! "unspecified message": "http://www.w3.org/@@@@/@@/addressing/id/unspecified"
</p>
<p>This specification has one predefined relationship type as shown in
--- 503,511 ----
<dd>
<p>A pair of values that indicate how this message relates to another
! message. The type of the relationship is identified by an absolute IRI.
! The related message is identified by an absolute IRI that corresponds to
! the related message's [message id] property. The message identifier IRI
! may refer to a specific message, or be the following well-known URI that
! means "unspecified message": "http://www.w3.org/@@@@/@@/addressing/id/unspecified"
</p>
<p>This specification has one predefined relationship type as shown in
***************
*** 520,524 ****
<tbody>
<tr>
! <th align="left" rowspan="1" colspan="1">IRI</th>
<th align="left" rowspan="1" colspan="1">Description </th>
</tr>
--- 515,519 ----
<tbody>
<tr>
! <th align="left" rowspan="1" colspan="1">URI</th>
<th align="left" rowspan="1" colspan="1">Description </th>
</tr>
***************
*** 528,538 ****
</td>
<td rowspan="1" colspan="1">Indicates that this is a reply to the message identified by
! the IRI.</td>
</tr>
</tbody>
</table><br>
<p>A reply message MUST contain a [relationship] property consisting of the
! predefined reply IRI and the message id property of the request
! message.</p>
</dd>
--- 523,534 ----
</td>
<td rowspan="1" colspan="1">Indicates that this is a reply to the message identified by
! the [message id] IRI.</td>
</tr>
</tbody>
</table><br>
<p>A reply message MUST contain a [relationship] property consisting of the
! predefined reply URI and the [message id] property of the request
! message. A reply message MUST NOT contain more than one [relationship]
! property using the predefined reply URI</p>
</dd>
***************
*** 545,564 ****
</dl>
! <p>The dispatching of incoming messages is based on two message properties: the
! mandatory "destination" and "action" fields indicate the target processing location
! and the verb or intent of the message respectively.</p>
<p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
! endpoint. To allow these "anonymous" endpoints to initiate message exchange patterns
! and receive replies, WS-Addressing defines the following well-known IRI for use by
! endpoints that cannot have a stable, resolvable IRI:
! "http://www.w3.org/@@@@/@@/addressing/role/anonymous"
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
address MUST provide some out-of-band mechanism for delivering replies or faults
! (e.g. returning the reply on the same transport connection). This mechanism may be a
! simple request/reply transport protocol (e.g., HTTP GET or POST). This IRI MAY be
! used as the [destination] for reply messages and SHOULD NOT be used as the
! [destination] in other circumstances.</p>
<div class="div2">
--- 541,556 ----
</dl>
! <p>The mandatory [destination] and [action] properties indicate the target processing
! location and the verb or intent of the message respectively. The values of these
! properties can be used to facilitate the dispatch of incoming messages.</p>
<p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
! endpoint. To allow these "anonymous" endpoints to send and receive messages,
! WS-Addressing defines the following well-known URI for use by endpoints that cannot
! have a stable, resolvable IRI: "http://www.w3.org/@@@@/@@/addressing/role/anonymous"
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
address MUST provide some out-of-band mechanism for delivering replies or faults
! (e.g. returning the reply on the same transport connection).</p>
<div class="div2">
***************
*** 567,577 ****
that can be easily secured as a unit. These properties are immutable and not
intended to be modified along a message path. </p>
! <p>The following describes the XML Infoset representation of message addressing
properties:</p>
! <div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 3-1. </span>XML Infoset representation of message addressing properties.</i></p>
! <div class="exampleInner"><pre>
! <wsa:MessageID> xs:anyURI </wsa:MessageID>
! <wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>
--- 559,567 ----
that can be easily secured as a unit. These properties are immutable and not
intended to be modified along a message path. </p>
! <p>The following shows the XML Infoset representation of message addressing
properties:</p>
! <div class="exampleInner"><pre>
! <wsa:MessageID>xs:anyURI </wsa:MessageID>
! <wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>
***************
*** 579,584 ****
<wsa:ReplyTo>endpoint-reference</wsa:ReplyTo>
<wsa:FaultTo>endpoint-reference</wsa:FaultTo>
! </pre></div>
! </div>
<p>The following describes the attributes and elements listed in the schema overview
above:</p>
--- 569,574 ----
<wsa:ReplyTo>endpoint-reference</wsa:ReplyTo>
<wsa:FaultTo>endpoint-reference</wsa:FaultTo>
! <wsa:ReferenceParameters>xs:any*</wsa:FaultTo>
! </pre></div>
<p>The following describes the attributes and elements listed in the schema overview
above:</p>
***************
*** 652,657 ****
[destination] property. If this element is NOT present then the
value of the [destination] property is
! "http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the
! [children] of this element convey the value of this property.</p>
</dd>
--- 642,646 ----
[destination] property. If this element is NOT present then the
value of the [destination] property is
! "http://www.w3.org/@@@@/@@/addressing/role/anonymous".</p>
</dd>
***************
*** 661,667 ****
<dt class="label"> /wsa:Action</dt>
<dd>
! <p>This REQUIRED element of type xs:anyURI conveys the [action]
! property. The [children] of this element convey the value of this
! property.</p>
</dd>
--- 650,655 ----
<dt class="label"> /wsa:Action</dt>
<dd>
! <p>This REQUIRED element of type xs:anyURI conveys the value of the
! [action] property.</p>
</dd>
***************
*** 669,681 ****
<dt class="label"> /[reference parameters]*</dt>
<dd>
! <p>Each element information item of found in [reference parameters]
(including all of its [children], [attributes] and [in-scope
namespaces]) is represented as is.</p>
</dd>
-
</dl>
! <p>Note that each of the element information items described above allows
! attribute wildcards for future extensibility.</p>
<div class="div3">
--- 657,669 ----
<dt class="label"> /[reference parameters]*</dt>
<dd>
! <p>Each element information item found in [reference parameters]
(including all of its [children], [attributes] and [in-scope
namespaces]) is represented as is.</p>
</dd>
</dl>
! <p>Note that each of the element information items described above allows attribute
! wildcards for future extensibility. A message processor may safely ignore any
! extension attribute it does not recognize.</p>
<div class="div3">
***************
*** 684,695 ****
[relationship] are absolute IRIs. The purpose of these IRIs is primarily
identification, rather than resource retrieval. As such, simple string
! comparison, as indicated in Internationalized
! Resource Identifiers <cite><a href="#RFC3987">IETF RFC 3987</a></cite> section 5.3.1, is sufficient to determine equivalence of
these IRIs.</p>
</div>
</div>
<div class="div2">
! <h3><a name="formreplymsg"></a>3.2 Formulating a Reply Message</h3>
<p>The reply to a WS-Addressing compliant request message MUST be compliant to
WS-Addressing and is constructed according to the following rules:</p>
--- 672,685 ----
[relationship] are absolute IRIs. The purpose of these IRIs is primarily
identification, rather than resource retrieval. As such, simple string
! comparison, as indicated in Internationalized Resource Identifiers <cite><a href="#RFC3987">IETF RFC 3987</a></cite> section 5.3.1, is sufficient to determine equivalence of
these IRIs.</p>
+ <p>Comparison of [destination] property values is out of scope, other than using
+ simple string comparison to detect whether the value is anonymous, that is,
+ where [destination] has the value "http://www.w3.org/@@@@/@@/addressing/role/anonymous".</p>
</div>
</div>
<div class="div2">
! <h3><a name="formreplymsg"></a>3.2 Formulating a Reply Message</h3>
<p>The reply to a WS-Addressing compliant request message MUST be compliant to
WS-Addressing and is constructed according to the following rules:</p>
***************
*** 706,714 ****
<p>Otherwise, if the reply is a fault message and the incoming
message's [fault endpoint] message addressing property is not
! empty, select the EPR from that property. If the [fault endpoint]
! property is empty, select the EPR from the incoming message's
! [reply endpoint] message addressing property. Otherwise, if the
! [reply endpoint] property is empty, the behavior of the recipient
! of the incoming message is unconstrained by this specification.</p>
</li>
</ul>
--- 696,705 ----
<p>Otherwise, if the reply is a fault message and the incoming
message's [fault endpoint] message addressing property is not
! empty, select the EPR from that property. If the [fault
! endpoint] property is empty, select the EPR from the incoming
! message's [reply endpoint] message addressing property.
! Otherwise, if the [reply endpoint] property is empty, the
! behavior of the recipient of the incoming message is
! unconstrained by this specification.</p>
</li>
</ul>
***************
*** 723,727 ****
<li>
<p>[relationship]: a new pair of IRIs is added to this value as
! follows; the relationship type is the predefined reply IRI
"http://www.w3.org/@@@@/@@/addressing/reply" and the related message's
identifier is the [message id] property value from the message
--- 714,718 ----
<li>
<p>[relationship]: a new pair of IRIs is added to this value as
! follows; the relationship type is the predefined reply URI
"http://www.w3.org/@@@@/@@/addressing/reply" and the related message's
identifier is the [message id] property value from the message
***************
*** 739,751 ****
properties serialized as header blocks in a SOAP 1.2 message:</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 3-2. </span>Example request message.</i></p>
<div class="exampleInner"><pre>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
<S:Header>
! <wsa:MessageID>http://example.com/someuniquestring
! </wsa:MessageID>
! <wsa:ReplyTo>
! <wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To S:mustUnderstand="1">mailto:fabrikam@example.com</wsa:To>
--- 730,741 ----
properties serialized as header blocks in a SOAP 1.2 message:</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 3-1. </span>Example request message.</i></p>
<div class="exampleInner"><pre>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
<S:Header>
! <wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID>
! <wsa:ReplyTo>
! <wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To S:mustUnderstand="1">mailto:fabrikam@example.com</wsa:To>
***************
*** 782,786 ****
<p>The following example illustrates a reply to the above message:</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 3-3. </span>Example response message.</i></p>
<div class="exampleInner"><pre>
<S:Envelope
--- 772,776 ----
<p>The following example illustrates a reply to the above message:</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><i><span>Example 3-2. </span>Example response message.</i></p>
<div class="exampleInner"><pre>
<S:Envelope
***************
*** 788,800 ****
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
<S:Header>
! <wsa:MessageID>
! http://example.com/someotheruniquestring
! </wsa:MessageID>
! <wsa:RelatesTo>
! http://example.com/someuniquestring
! </wsa:RelatesTo>
! <wsa:To S:mustUnderstand="1">
! http://example.com/business/client1
! </wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action>
</S:Header>
--- 778,784 ----
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
<S:Header>
! <wsa:MessageID>http://example.com/someotheruniquestring</wsa:MessageID>
! <wsa:RelatesTo>http://example.com/someuniquestring</wsa:RelatesTo>
! <wsa:To S:mustUnderstand="1">http://example.com/business/client1</wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action>
</S:Header>
***************
*** 846,855 ****
<div class="div1">
! <h2><a name="references"></a>5. References</h2>
<dl>
<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="ws-addr-wsdl.html">Web Services Addressing 1.0 - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, Editors.</dd>
<dt class="label"><a name="WSDL20"></a>[WSDL 2.0] </dt><dd>
<cite><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803">Web Services Description Language 2.0</a></cite>, R. Chinnici, M.
--- 830,840 ----
<div class="div1">
! <h2><a name="references"></a>5. References</h2>
<dl>
<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>
<dt class="label"><a name="WSDL20"></a>[WSDL 2.0] </dt><dd>
<cite><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803">Web Services Description Language 2.0</a></cite>, R. Chinnici, M.
***************
*** 862,873 ****
S. Bradner. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt. </dd>
! <dt class="label"><a name="RFC3987"></a>[IETF RFC 3987] </dt><dd> M.
! Duerst, M. Suignard, "Internationalized Resource Identifiers (IRIs)", January
2005. (See <cite><a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a></cite>.)</dd>
<dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
<cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>, T.
Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
! Consortium, 4 February 2004. This version of the XML
! 1.0 Recommendation is http://www.w3.org/TR/2004/REC-xml-20040204. The <a href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/REC-xml. </dd>
<dt class="label"><a name="XMLNS"></a>[XML Namespaces] </dt><dd>
--- 847,858 ----
S. Bradner. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt. </dd>
! <dt class="label"><a name="RFC3987"></a>[IETF RFC 3987] </dt><dd>
! M. Duerst, M. Suignard, "Internationalized Resource Identifiers (IRIs)", January
2005. (See <cite><a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a></cite>.)</dd>
<dt class="label"><a name="XML10"></a>[XML 1.0] </dt><dd>
<cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>, T.
Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
! Consortium, 4 February 2004. This version of the XML 1.0 Recommendation is
! http://www.w3.org/TR/2004/REC-xml-20040204. The <a href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/REC-xml. </dd>
<dt class="label"><a name="XMLNS"></a>[XML Namespaces] </dt><dd>
***************
*** 883,898 ****
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/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</a></cite>, H. Thompson, D. Beech, M.
! Maloney, and N. Mendelsohn, Editors. World Wide
! Web Consortium, 28 October 2004. This
! version of the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</a> is available at http://www.w3.org/TR/xmlschema-1. </dd>
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Datatypes] </dt><dd>
! <cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second Edition</a></cite>, P. Byron and A. Malhotra,
! Editors. World Wide Web Consortium, 28 October 2004. This version of the XML Schema
! Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The
! <a href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
! Part 2</a> is available at http://www.w3.org/TR/xmlschema-2. </dd>
<dt class="label"><a name="SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework] </dt><dd>
<cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M.
--- 868,882 ----
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/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</a></cite>, H. Thompson,
! D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 28
! October 2004. This version of the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</a> is available at http://www.w3.org/TR/xmlschema-1. </dd>
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Datatypes] </dt><dd>
! <cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second Edition</a></cite>, P. Byron and
! A. Malhotra, Editors. World Wide Web Consortium, 28 October 2004. This version
! of the XML Schema Part 2 Recommendation is
! http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema Part
! 2</a> is available at http://www.w3.org/TR/xmlschema-2. </dd>
<dt class="label"><a name="SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework] </dt><dd>
<cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M.
***************
*** 928,943 ****
<div class="div2">
! <h3><a name="N105EB"></a>B.1 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 @ 22:36</td><td>mgudgin</td><td>Incorporated resolution of issue 50 into Section 3.2</td></tr><tr><td>2005-03-21 @ 22:06</td><td>mgudgin</td><td>Updated with resolution to issue 54</td></tr><tr><td>2005-03-21 @ 20:47</td><td>mgudgin</td><td>Removed parenthetical statement '(and opaquely)' from description of [action] property in Section 3 per resolution on 2005-03-21 telcon</td></tr><tr><td>2005-03-21 @ 16:39</td><td>mgudgin</td><td>s/that value/that the value in description of [action] property in Section 3</td></tr><tr><td>2005-03-21 @ 16:37</td><td>mgudgin</td><td>Split paragraph 2 in Section 3 into two seperate paragraphs</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>200503-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><td>Added 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-03-02 @ 14:07</td><td>mhadley</td><td>Added issue 52 resolution.</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 @ 21:42</td><td>mhadley</td><td>Added issue 48 resolution</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-23 @ 14:34</td><td>mgudgin</td><td>
Added new section 2.5: Endpoint Reference Extensibility per resolution of issue i042</td></tr><tr><td>2005-02-17 @ 16:16</td><td>mhadley</td><td>Added resolution to issue 44</td></tr><tr><td>2005-02-15 @ 22:53</td><td>mhadley</td><td>Added resolution to issue 46</td></tr></table>
</div>
<div class="div2">
! <h3><a name="N105F5"></a>B.2 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="N105FF"></a>B.3 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>
--- 912,930 ----
<div class="div2">
! <h3><a name="N105E3"></a>B.1 Changes Since Second Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></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 rsolution 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>hadley</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><tr><td>2005-03-30 @ 21:02</td><td>plehegar</td><td>Removed some extra blanks
! Added the note from David Hull at
! http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0254.html
! per teleconference March 28, 2005</td></tr><tr><td>2005-03-21 @ 22:36</td><td>mgudgin</td><td>Incorporated resolution of issue 50 into Section 3.2</td></tr><tr><td>2005-03-21 @ 22:06</td><td>mgudgin</td><td>Updated with resolution to issue 54</td></tr><tr><td>2005-03-21 @ 20:47</td><td>mgudgin</td><td>Removed parenthetical statement '(and opaquely)' from description of [action] property in Section 3 per resolution on 2005-03-21 telcon</td></tr><tr><td>2005-03-21 @ 16:39</td><td>mgudgin</td><td>s/that value/that the value in description of [action] property in Section 3</td></tr><tr><td>2005-03-21 @ 16:37</td><td>mgudgin</td><td>Split paragraph 2 in Section 3 into two seperate paragraphs</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-02 @ 21:18</td><td>mhadley</td><td>Added rsolution to issue 4</td></tr><tr><td>2005-03-02 @ 20:30</td><td>mhadley</td><td>Added 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-03-02 @ 14:07</td><td>mhadley</td><td>Added issue 52 resolution.</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 @ 21:42</td><td>mhadley</td><td>Added issue 48 resolution</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-23 @ 14:34</td><td>mgudgin</td><td>
Added new section 2.5: Endpoint Reference Extensibility per resolution of issue i042</td></tr><tr><td>2005-02-17 @ 16:16</td><td>mhadley</td><td>Added resolution to issue 44</td></tr><tr><td>2005-02-15 @ 22:53</td><td>mhadley</td><td>Added resolution to issue 46</td></tr></table>
</div>
<div class="div2">
! <h3><a name="N105ED"></a>B.2 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="N105F7"></a>B.3 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.25
retrieving revision 1.26
diff -C2 -d -r1.25 -r1.26
*** ws-addr-soap.html 12 Apr 2005 13:18:41 -0000 1.25
--- ws-addr-soap.html 22 Apr 2005 20:17:46 -0000 1.26
***************
*** 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="#bindrefp">Binding Message Addressing Properties</a><br>4. <a href="#s11ext">SOAP 1.1 Addressing 1.0 Extension</a><br> &nbp; 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="#invalidmapfault"> Invalid Message Addressing Property</a><br> 5.2 <a href="#missingmapfault"> Message Addressing Property Required</a><br> 5.3 <a href="#destinationfault"> Destination Unreachable</a><br> 5.4 <a href="#actionfault"> Action Not Supported</a><br> 5.5 <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 href="#references"> 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> B.1 <a href="#N104F2">Changes Since Second Working Draft</a><br> B.2 <a href="#N104FC">Changes Since First Working Draft</a><br> B.3 <a href="#N10506">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>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="#invalidmapfault"> Invalid Message Addressing Property</a><br> 5.2 <a href="#missingmapfault"> Message Addressing Property Required</a><br> 5.3 <a href="#destinationfault"> Destination Unreachable</a><br> 5.4 <a href="#actionfault"> Action Not Supported</a><br> 5.5 <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 href="#references"> 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> B.1 <a href="#N1051D">Changes Since Second Working Draft</a><br> B.2 <a href="#N10527">Changes Since First Working Draft</a><br> B.3 <a href="#N10531">Changes Since Submission</a><br></p></div><hr><div class="body">
<div class="div1">
***************
*** 85,111 ****
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
(002) <S:Header>
! (003) <wsa:MessageID>
! (004) http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA
! (005) </wsa:MessageID>
! (006) <wsa:ReplyTo>
! (007) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (008) </wsa:ReplyTo>
! (009) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (010) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (011) </S:Header>
! (012) <S:Body>
! (013) ...
! (014) </S:Body>
! (015) </S:Envelope>
</pre></div>
! <p>Lines (002) to (011) represent the header of the SOAP message where the
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 addressing 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 IRI identifying expected semantics.</p>
</div>
<div class="div2">
--- 85,109 ----
xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
(002) <S:Header>
! (003) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (004) <wsa:ReplyTo>
! (005) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (006) </wsa:ReplyTo>
! (007) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (008) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (009) </S:Header>
! (010) <S:Body>
! (011) ...
! (012) </S:Body>
! (013) </S:Envelope>
</pre></div>
! <p>Lines (002) to (009) represent the header of the SOAP message where the
mechanisms defined in the specification are used. The body is represented by
! lines (010) to (012).</p>
! <p>Lines (003) to (008) contain the message addressing properties serialized as SOAP
! header blocks. Specifically, line (003) specifies the identifier for this
! message and lines (004) to (006) specify the endpoint to which replies to this
! message should be sent as an Endpoint Reference. Line (007) specifies the
! address URI of the ultimate receiver of this message. Line (008) specifies an
! action URI identifying expected semantics.</p>
</div>
<div class="div2">
***************
*** 181,185 ****
<h3><a name="s12featurename"></a>2.1 Feature Name</h3>
! <p>The SOAP 1.2 Addressing 1.0 Feature is named using the following IRI:</p>
<ul>
<li>
--- 179,183 ----
<h3><a name="s12featurename"></a>2.1 Feature Name</h3>
! <p>The SOAP 1.2 Addressing 1.0 Feature is named using the following URI:</p>
<ul>
<li>
***************
*** 271,275 ****
<h3><a name="s12modulename"></a>3.1 Module Name</h3>
! <p>The SOAP 1.2 Addressing 1.0 Module is identified using the following IRI:</p>
<ul>
<li>
--- 269,273 ----
<h3><a name="s12modulename"></a>3.1 Module Name</h3>
! <p>The SOAP 1.2 Addressing 1.0 Module is identified using the following URI:</p>
<ul>
<li>
***************
*** 283,294 ****
<p>The SOAP 1.2 Addressing 1.0 Feature (see <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>) defines a
set of SOAP properties and their correspondence to the abstract message
! addressing properties defined by Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>]. The SOAP 1.2 Addressing 1.0 Module uses the XML Infoset representation of
! the abstract message addressing properties defined in Web Services Addressing 1.0 - Core.</p>
<p>When sending a message each property is represented using the appropriate element
information item as a SOAP header block. The resulting header blocks are
targetted at the ultimate recipient in the SOAP message path (note that
extensions to WS-Addressing could be written to specify different targetting).
! <a href="#bindrefp"><b>3.3 Binding Message Addressing Properties</b></a> describes additional processing required when binding
! message addressing properties to SOAP header blocks.</p>
<p>When receiving a message, the abstract properties are populated from their
corresponding element information items in the message. Note that the message
--- 281,293 ----
<p>The SOAP 1.2 Addressing 1.0 Feature (see <a href="#s12feature"><b>2. SOAP 1.2 Addressing 1.0 Feature</b></a>) defines a
set of SOAP properties and their correspondence to the abstract message
! addressing properties defined by Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>]. The SOAP 1.2 Addressing 1.0 Module defines SOAP headers corresponding to
! the XML Infoset representation of the abstract message addressing properties
! defined in Web Services Addressing 1.0 - Core.</p>
<p>When sending a message each property is represented using the appropriate element
information item as a SOAP header block. The resulting header blocks are
targetted at the ultimate recipient in the SOAP message path (note that
extensions to WS-Addressing could be written to specify different targetting).
! <a href="#bindrefp"><b>3.4 Binding Message Addressing Properties</b></a> describes additional processing required when
! binding message addressing properties to SOAP header blocks.</p>
<p>When receiving a message, the abstract properties are populated from their
corresponding element information items in the message. Note that the message
***************
*** 299,323 ****
<div class="div2">
! <h3><a name="bindrefp"></a>3.3 Binding Message Addressing Properties</h3>
! <p>When a message is be addressed to an endpoint, the values of the SOAP 1.2 Addressing
! 1.0 Feature properties
! are mapped to the message as SOAP header blocks with the following additional
! modifications:</p>
<ul>
<li>
! <p>The value of the http://www.w3.org/@@@@/@@/addressing/feature/ReferenceParameters property
! is added to the SOAP
! message header. The element information item of each [reference parameter]
! (including all of its [children], [attributes] and [in-scope
! namespaces]) is added as a SOAP 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:isReferenceParameter attribute whose value is "true".
! </p>
</li>
<li>
<p>Each property that is of type IRI MUST be serialized as an absolute IRI
! in the SOAP message.</p>
</li>
</ul>
--- 298,345 ----
<div class="div2">
! <h3><a name="additionalinfoset"></a>3.3 Additional Infoset Items</h3>
! <p>The SOAP 1.2 Addressing 1.0 Module defines the following additional XML Infoset
! items:</p>
! <dl>
!
! <dt class="label">/[reference parameters]/@wsa:IsReferenceParameter</dt>
! <dd>
! <p>This REQUIRED attribute (of type xs:boolean) signifies whether the
! message information header is a reference parameter, see section
! <a href="#bindrefp"><b>3.4 Binding Message Addressing Properties</b></a> for more details on its use.</p>
! </dd>
!
! </dl>
! </div>
! <div class="div2">
!
! <h3><a name="bindrefp"></a>3.4 Binding Message Addressing Properties</h3>
! <p>When a message is to be addressed to an endpoint, the XML representation of each
! SOAP 1.2 WS-Addressing 1.0 Feature property is inserted into the message as a
! SOAP header block subject to the following additional constraints:</p>
<ul>
<li>
! <p>The value of the http://www.w3.org/@@@@/@@/addressing/feature/ReferenceParameters property is
! added to the SOAP message header. The element information item of each
! of the [reference parameters] (including all of its [children],
! [attributes] and [in-scope namespaces]) is added as a SOAP header block
! in the new message.</p>
</li>
<li>
<p>Each header block added as a result of the above rule is annotated with a
! wsa:IsReferenceParameter attribute (see <a href="#additionalinfoset"><b>3.3 Additional Infoset Items</b></a>) whose value is a valid xs:boolean representaion of
! "true". Any existing wsa:IsReferenceParameter attribute
! on the header block is replaced.</p>
! <div class="note"><p class="prefix"><b>Note:</b></p>
! <p>Integrity validation of [reference parameters] needs to take into
! account the addition of wsa:IsReferenceParameter attributes and the
! corresponding introduction of the WS-Addressing namespace to the
! [in-scope namespaces]</p>
! </div>
</li>
<li>
<p>Each property that is of type IRI MUST be serialized as an absolute IRI
! in the corresponding XML Infoset representation of that Message
! Addressing Property.</p>
</li>
</ul>
***************
*** 343,350 ****
</wsa:EndpointReference></pre></div>
</div>
! <p>The address value is copied in the "To"
! header block and the "CustomerKey" and "ShoppingCart" elements are copied
! literally as a header blocks in a SOAP message addressed to this endpoint. The
! resulting SOAP message would look as follows:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 3-2. </span>Example endpoint reference mapped to SOAP message header blocks.</i></p>
--- 365,372 ----
</wsa:EndpointReference></pre></div>
</div>
! <p>The address value is copied in the "To" header block and the "CustomerKey" and
! "ShoppingCart" elements are copied literally as a header blocks in a SOAP
! message addressed to this endpoint. The resulting SOAP message would look as
! follows:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 3-2. </span>Example endpoint reference mapped to SOAP message header blocks.</i></p>
***************
*** 357,362 ****
<wsa:To>http://example.com/fabrikam/acct</wsa:To>
<wsa:Action>...</wsa:Action>
! <fabrikam:CustomerKey wsa:isReferenceParameter='true'>123456789</fabrikam:CustomerKey>
! <fabrikam:ShoppingCart wsa:isReferenceParameter='true'>ABCDEFG</fabrikam:ShoppingCart>
...
</S:Header>
--- 379,384 ----
<wsa:To>http://example.com/fabrikam/acct</wsa:To>
<wsa:Action>...</wsa:Action>
! <fabrikam:CustomerKey wsa:IsReferenceParameter='true'>123456789</fabrikam:CustomerKey>
! <fabrikam:ShoppingCart wsa:IsReferenceParameter='true'>ABCDEFG</fabrikam:ShoppingCart>
...
</S:Header>
***************
*** 375,384 ****
ensure interoperability with a broad range of devices, all conformant
implementations that include support for SOAP 1.1 MUST support the SOAP 1.1
! Addressing 1.0 Extension. This SOAP 1.1 extension is provided for backwards
! compatibility only.</p>
<div class="div2">
<h3><a name="s11extname"></a>4.1 Extension Name</h3>
! <p>The SOAP 1.1 Addressing 1.0 Extension is identified using the following IRI:</p>
<ul>
<li>
--- 397,406 ----
ensure interoperability with a broad range of devices, all conformant
implementations that include support for SOAP 1.1 MUST support the SOAP 1.1
! Addressing 1.0 Extension. This SOAP 1.1 extension is provided for backwards
! compatibility only.</p>
<div class="div2">
<h3><a name="s11extname"></a>4.1 Extension Name</h3>
! <p>The SOAP 1.1 Addressing 1.0 Extension is identified using the following URI:</p>
<ul>
<li>
***************
*** 416,426 ****
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 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
</pre></div>
! <p>The definitions of faults use the following properties:</p>
<p> [Code] The fault code.</p>
<p> [Subcode] The fault subcode.</p>
--- 438,453 ----
preamble in each subsection is met.</p>
<p>Endpoints compliant with this specification MUST include the required message
! addressing properties serialized as SOAP headers in generated fault messages. Fault
messages are correlated as replies using the [relationship] property as defined in
! Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>]. Note that omission of the
! [message id] property in an input message may impact the ability of a fault message
! receiver to correlate the fault message to the message that caused the fault message
! to be generated. Omission of the [fault endpoint] or [reply endpoint] properties in
! input messages may impact the delivery of a generated fault message</p>
! <p>The [action] property below designates WS-Addressing fault messages:</p>
<div class="exampleInner"><pre>
http://www.w3.org/@@@@/@@/addressing/fault
</pre></div>
! <p>The definitions of faults uses the following properties:</p>
<p> [Code] The fault code.</p>
<p> [Subcode] The fault subcode.</p>
***************
*** 432,457 ****
<div class="exampleInner"><pre>
<S:Envelope>
! <S:Header>
! <wsa:Action>
! http://www.w3.org/@@@@/@@/addressing/fault
! </wsa:Action>
! <!-- Headers elided for clarity. -->
! </S:Header>
! <S:Body>
! <S:Fault>
! <S:Code>
! <S:Value>[Code]</S:Value>
! <S:Subcode>
! <S:Value>[Subcode]</S:Value>
! </S:Subcode>
! </S:Code>
! <S:Reason>
! <S:Text xml:lang="en">[Reason]</S:Text>
! </S:Reason>
! <S:Detail>
! [Detail]
! </S:Detail>
! </S:Fault>
! </S:Body>
</S:Envelope>
</pre></div>
--- 459,482 ----
<div class="exampleInner"><pre>
<S:Envelope>
! <S:Header>
! <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
! <!-- Headers elided for brevity. -->
! </S:Header>
! <S:Body>
! <S:Fault>
! <S:Code>
! <S:Value>[Code]</S:Value>
! <S:Subcode>
! <S:Value>[Subcode]</S:Value>
! </S:Subcode>
! </S:Code>
! <S:Reason>
! <S:Text xml:lang="en">[Reason]</S:Text>
! </S:Reason>
! <S:Detail>
! [Detail]
! </S:Detail>
! </S:Fault>
! </S:Body>
</S:Envelope>
</pre></div>
***************
*** 463,472 ****
<div class="exampleInner"><pre>
<S11:Envelope>
! <S11:Body>
! <S11:Fault>
! <faultcode>[Subcode]</faultcode>
! <faultstring xml:lang="en">[Reason]</faultstring>
! </S11:Fault>
! </S11:Body>
</S11:Envelope>
</pre></div>
--- 488,501 ----
<div class="exampleInner"><pre>
<S11:Envelope>
! <S11:Header>
! <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
! <!-- Headers elided for brevity. -->
! </S11:Header>
! <S11:Body>
! <S11:Fault>
! <faultcode>[Subcode]</faultcode>
! <faultstring xml:lang="en">[Reason]</faultstring>
! </S11:Fault>
! </S11:Body>
</S11:Envelope>
</pre></div>
***************
*** 524,528 ****
<p> [Reason] The endpoint is unable to process the message at this time.</p>
<p> [Detail] <wsa:RetryAfter
! ...>[xs:NonNegativeInteger]</wsa:RetryAfter></p>
<p> The following describes the attributes and elements listed above:</p>
<dl>
--- 553,557 ----
<p> [Reason] The endpoint is unable to process the message at this time.</p>
<p> [Detail] <wsa:RetryAfter
! ...>[xs:nonNegativeInteger]</wsa:RetryAfter></p>
<p> The following describes the attributes and elements listed above:</p>
<dl>
***************
*** 578,582 ****
<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>
--- 607,611 ----
<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>
***************
*** 597,602 ****
<cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>, T.
Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
! Consortium, 4 February 2004. This version of the XML
! 1.0 Recommendation is http://www.w3.org/TR/2004/REC-xml-20040204. The <a href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/REC-xml. </dd>
<dt class="label"><a name="XMLNS"></a>[XML Namespaces] </dt><dd>
--- 626,631 ----
<cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>, T.
Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
! Consortium, 4 February 2004. This version of the XML 1.0 Recommendation is
! http://www.w3.org/TR/2004/REC-xml-20040204. The <a href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/REC-xml. </dd>
<dt class="label"><a name="XMLNS"></a>[XML Namespaces] </dt><dd>
***************
*** 612,627 ****
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/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</a></cite>, H. Thompson, D. Beech, M.
! Maloney, and N. Mendelsohn, Editors. World Wide
! Web Consortium, 28 October 2004. This
! version of the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</a> is available at http://www.w3.org/TR/xmlschema-1. </dd>
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Datatypes] </dt><dd>
! <cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second Edition</a></cite>, P. Byron and A. Malhotra,
! Editors. World Wide Web Consortium, 28 October 2004. This version of the XML Schema
! Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The
! <a href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
! Part 2</a> is available at http://www.w3.org/TR/xmlschema-2. </dd>
<dt class="label"><a name="SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework] </dt><dd>
<cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M.
--- 641,655 ----
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/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</a></cite>, H. Thompson,
! D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 28
! October 2004. This version of the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</a> is available at http://www.w3.org/TR/xmlschema-1. </dd>
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Datatypes] </dt><dd>
! <cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second Edition</a></cite>, P. Byron and
! A. Malhotra, Editors. World Wide Web Consortium, 28 October 2004. This version
! of the XML Schema Part 2 Recommendation is
! http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema Part
! 2</a> is available at http://www.w3.org/TR/xmlschema-2. </dd>
<dt class="label"><a name="SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework] </dt><dd>
<cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M.
***************
*** 666,680 ****
<div class="div2">
! <h3><a name="N104F2"></a>B.1 Changes Since Second Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-04-12 @ 13:17</td><td>mhadley</td><td>Fixed closing element in example</td></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>mhdley</td><td>Added resolution to issue 4</td></tr><tr><td>2005-03-02 @ 20:30</td><td>mhadley</td><td>Added 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="N104FC"></a>B.2 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="N10506"></a>B.3 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>
--- 694,708 ----
<div class="div2">
! <h3><a name="N1051D"></a>B.1 Changes Since Second Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-04-22 @ 20:01</td><td>mhadley</td><td>Added resolution to lc32 - added note warning of infoset changes due to IsReferenceParameter addition when binding [reference parameter] to SOAP.</td></tr><tr><td>2005-04-22 @ 19:51</td><td>mhadley</td><td>Added resolution to lc31 - clarified what to do if a reference parameter already has an IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19:46</td><td>mhadley</td><td>Added resolution to lc30 - added new section for definition of IsReferenceParameter attribute.</td></tr><tr><td>2005-04-22 @ 19: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 resoluion 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><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><td2005-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><td>Added 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="N10527"></a>B.2 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="N10531"></a>B.3 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 Friday, 22 April 2005 20:17:59 UTC