- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 03 Jun 2005 20:33:53 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv27749
Modified Files:
ws-addr-core.xml ws-addr-soap.xml
Log Message:
Added resolutions to issues lc58, lc79, lc91, lc102
Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.96
retrieving revision 1.97
diff -C2 -d -r1.96 -r1.97
*** ws-addr-core.xml 2 Jun 2005 19:48:59 -0000 1.96
--- ws-addr-core.xml 3 Jun 2005 20:33:51 -0000 1.97
***************
*** 411,415 ****
</note>
<p> Message addressing properties provide references for the endpoints involved in an
! interaction. The use of these properties to support specific interaction is in
general defined by both the semantics of the properties themselves and the implicit
or explicit contract that governs the message exchange. If explicitly available,
--- 411,415 ----
</note>
<p> Message addressing properties provide references for the endpoints involved in an
! interaction. The use of these properties to support specific interactions is in
general defined by both the semantics of the properties themselves and the implicit
or explicit contract that governs the message exchange. If explicitly available,
***************
*** 548,556 ****
<div2 id="msgaddrpropsinfoset">
<head>XML Infoset Representation of Message Addressing Properties</head>
- <p>Message addressing properties provide end-to-end characteristics of a message
- 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 the message addressing
! properties define in <specref ref="abstractmaps"/>:</p>
<eg xml:space="preserve">
<wsa:To>xs:anyURI</wsa:To>
--- 548,553 ----
<div2 id="msgaddrpropsinfoset">
<head>XML Infoset Representation of Message Addressing Properties</head>
<p>The following shows the XML Infoset representation of the message addressing
! properties defined in <specref ref="abstractmaps"/>:</p>
<eg xml:space="preserve">
<wsa:To>xs:anyURI</wsa:To>
Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.77
retrieving revision 1.78
diff -C2 -d -r1.77 -r1.78
*** ws-addr-soap.xml 2 Jun 2005 19:45:20 -0000 1.77
--- ws-addr-soap.xml 3 Jun 2005 20:33:51 -0000 1.78
***************
*** 1,3 ****
! <?xml version="1.0"?>
<!-- $Id$ -->
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.1//EN" "xmlspec.dtd" [
--- 1,3 ----
! gat<?xml version="1.0"?>
<!-- $Id$ -->
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.1//EN" "xmlspec.dtd" [
***************
*** 191,195 ****
<p>This feature may be used with any SOAP MEP. A binding that
supports this feature MUST provide a means to transmit the
! properties listed above with a message and to reconstitute
their values on receipt of a message.</p>
</div2>
--- 191,195 ----
<p>This feature may be used with any SOAP MEP. A binding that
supports this feature MUST provide a means to transmit the
! properties listed below with a message and to reconstitute
their values on receipt of a message.</p>
</div2>
***************
*** 292,296 ****
<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
--- 292,297 ----
<p>When sending a message each property is represented using the
appropriate element information item as a SOAP header block.
! By default, the resulting header blocks are targeted at the
! ultimate
recipient in the SOAP message path (note that extensions to
WS-Addressing could be written to specify different
***************
*** 300,307 ****
<p>When receiving a message, the abstract properties are
populated from their corresponding element information items
! in the message. Note that the message addressing properties
! gathered by an intermediary when receiving a SOAP message do
! not necessarily get replayed as message addressing properties when resending the
! message along the message path. A message MUST NOT contain
more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action,
or wsa:MessageID header targeted at a recipient.
--- 301,305 ----
<p>When receiving a message, the abstract properties are
populated from their corresponding element information items
! in the message. A message MUST NOT contain
more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action,
or wsa:MessageID header targeted at a recipient.
***************
*** 309,312 ****
--- 307,317 ----
wsa:InvalidAddressingHeader (see <specref ref="invalidmapfault"/>)
fault if such a message is received.</p>
+ <note><p>The SOAP processing model dictates that message addressing properties
+ targeted at an intermediary do
+ not normally get relayed as message addressing properties when the
+ message is forwarded along the message path. The specification for
+ a SOAP header used as a
+ reference property or use of the soap:relay attribute can override this default
+ behaviour.</p></note>
</div2>
<div2 id="additionalinfoset">
***************
*** 346,350 ****
appropriate caution to ensure their reference parameters do not cause
unintended or erroneous semantics in the resultant SOAP message. For
! example, using a reference parameter to send a WS-Security<bibref ref="WS-Security"/> header would
be ill-advised (since other parts of the SOAP infrastructure will often
control this header, and there must be at most one of them per message).</p></note>
--- 351,356 ----
appropriate caution to ensure their reference parameters do not cause
unintended or erroneous semantics in the resultant SOAP message. For
! example, using a reference parameter to send a WS-Security[<bibref
! ref="WS-Security"/>] header would
be ill-advised (since other parts of the SOAP infrastructure will often
control this header, and there must be at most one of them per message).</p></note>
***************
*** 618,623 ****
<div2 id="destinationfault">
<head> Destination Unreachable</head>
! <p>No endpoint can be found capable of acting in the role of the
! [destination] property.</p>
<p> [Code] a QName representing the value S:Sender</p>
<p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
--- 624,628 ----
<div2 id="destinationfault">
<head> Destination Unreachable</head>
! <p>The endpoint identified by the value of [destination] property cannot be reached.</p>
<p> [Code] a QName representing the value S:Sender</p>
<p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
***************
*** 684,688 ****
<head>Additional Considerations for SOAP Intermediaries</head>
<p>To avoid breaking signatures, intermediaries MUST NOT change
! the XML representation of WS-Addressing headers. Specifically,
intermediaries MUST NOT remove XML content that explicitly
indicates otherwise-implied content, and intermediaries MUST
--- 689,694 ----
<head>Additional Considerations for SOAP Intermediaries</head>
<p>To avoid breaking signatures, intermediaries MUST NOT change
! the XML representation of WS-Addressing headers when relaying those headers.
! Specifically,
intermediaries MUST NOT remove XML content that explicitly
indicates otherwise-implied content, and intermediaries MUST
Received on Friday, 3 June 2005 20:34:01 UTC