2004/ws/addressing ws-addr-core.xml,1.96,1.97 ws-addr-soap.xml,1.77,1.78

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">
  &lt;wsa:To&gt;xs:anyURI&lt;/wsa:To&gt;
--- 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">
  &lt;wsa:To&gt;xs:anyURI&lt;/wsa:To&gt;

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