2004/ws/addressing ws-addr-core.xml,1.94,1.95

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

Modified Files:
	ws-addr-core.xml 
Log Message:
Added resolution to issue lc84 - removed redundant co-occurrence requirements and concentrated conformance requirements in section 3.3


Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.94
retrieving revision 1.95
diff -C2 -d -r1.94 -r1.95
*** ws-addr-core.xml	2 Jun 2005 18:47:06 -0000	1.94
--- ws-addr-core.xml	2 Jun 2005 19:39:41 -0000	1.95
***************
*** 419,433 ****
              <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>
--- 419,433 ----
              <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-response" 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
!                 response). A response 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 Response 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-response MEPs. More advanced MEPs may
                  require additional message addressing properties to augment the facilities provided
                  here. </p>
***************
*** 437,442 ****
              
              <p>Message addressing properties collectively augment a message with the following
!                 abstract properties to support one way, request reply, and other interaction
!                 pattern:</p>
              <glist>
                  <gitem>
--- 437,442 ----
              
              <p>Message addressing properties collectively augment a message with the following
!                 abstract properties to support one-way, request-response, and other interaction
!                 patterns:</p>
              <glist>
                  <gitem>
***************
*** 457,464 ****
                      <def>
                          <p>An endpoint reference for the intended receiver for replies to this
!                             message. If a reply is expected, a message MUST contain a [reply
!                             endpoint]. The sender MUST use the contents of the [reply endpoint] to
!                             formulate the reply message as defined in <specref ref="formreplymsg"/>.
!                             If this property is present, the [message id] property is REQUIRED.</p>
                      </def>
                  </gitem>
--- 457,461 ----
                      <def>
                          <p>An endpoint reference for the intended receiver for replies to this
!                             message.</p>
                      </def>
                  </gitem>
***************
*** 467,475 ****
                      <def>
                          <p>An endpoint reference for the intended receiver for faults related to
!                             this message. When formulating a fault message as defined in <specref
!                                 ref="formreplymsg"/>, 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>
                      </def>
                  </gitem>
--- 464,468 ----
                      <def>
                          <p>An endpoint reference for the intended receiver for faults related to
!                             this message.</p>
                      </def>
                  </gitem>
***************
*** 494,499 ****
                              communications failure and MAY use the same [message id] property. The
                              value of this property is an IRI whose interpretation beyond
!                             equivalence is not defined in this specification. If a reply is
!                             expected, this property MUST be present. </p>
                      </def>
                  </gitem>
--- 487,491 ----
                              communications failure and MAY use the same [message id] property. The
                              value of this property is an IRI whose interpretation beyond
!                             equivalence is not defined in this specification.</p>
                      </def>
                  </gitem>
***************
*** 527,534 ****
                              </tbody>
                          </table>
-                         <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>
                      </def>
                  </gitem>
--- 519,522 ----
***************
*** 541,553 ****
                  </gitem>
              </glist>
!             <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 pre-defined URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: <attval>&nsuri;/anonymous</attval>. 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>
                  <p>A binding of WS_Addressing message addressing properties MUST reflect the
--- 529,542 ----
                  </gitem>
              </glist>
!             <p>The [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 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 pre-defined URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: <attval>&nsuri;/anonymous</attval>. Messages 
!                 whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
!                 address MUST rely on some out-of-band mechanism for delivering replies or faults
                  (e.g. returning the reply on the same transport connection).</p>
                  <p>A binding of WS_Addressing message addressing properties MUST reflect the
***************
*** 597,603 ****
                          <def>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [reply endpoint] property. This element MUST be
!                                 present if a reply is expected. If this element is present,
!                                 wsa:MessageID MUST be present.</p>
                          </def>
                      </gitem>
--- 586,590 ----
                          <def>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [reply endpoint] property.</p>
                          </def>
                      </gitem>
***************
*** 606,611 ****
                          <def>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [fault endpoint] property. If this element is
!                                 present, wsa:MessageID MUST be present.</p>
                          </def>
                      </gitem>
--- 593,597 ----
                          <def>
                              <p>This OPTIONAL element (of type wsa:EndpointReferenceType) provides
!                                 the value for the [fault endpoint] property.</p>
                          </def>
                      </gitem>
***************
*** 621,626 ****
                          <def>
                              <p>This OPTIONAL element (whose content is of type xs:anyURI) conveys the [message id]
!                                 property. This element MUST be present if wsa:ReplyTo or wsa:FaultTo
!                                 is present.</p>
                          </def>
                      </gitem>
--- 607,611 ----
                          <def>
                              <p>This OPTIONAL element (whose content is of type xs:anyURI) conveys the [message id]
!                                 property.</p>
                          </def>
                      </gitem>
***************
*** 631,636 ****
                                  abstract [relationship] property value, in the form of an (IRI, IRI)
                                  pair. The content of this element (of type
!                                 xs:anyURI) conveys the [message id] of the related message. This
!                                 element MUST be present if the message is a reply.</p>
                          </def>
                      </gitem>
--- 616,620 ----
                                  abstract [relationship] property value, in the form of an (IRI, IRI)
                                  pair. The content of this element (of type
!                                 xs:anyURI) conveys the [message id] of the related message.</p>
                          </def>
                      </gitem>
***************
*** 670,675 ****
              <div2 id="formreplymsg">
                  <head>Formulating a Reply Message</head>
!                 <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>
                  <olist>
                      <item>
--- 654,659 ----
              <div2 id="formreplymsg">
                  <head>Formulating a Reply Message</head>
!                 <p>This section specifies the WS-Addressing-specific rules for creating a reply or
!                     fault message related to another message.</p>
                  <olist>
                      <item>
***************
*** 678,694 ****
                              <item>
                                  <p>If the reply is a normal message, select the EPR from the
!                                     incoming message's [reply endpoint] message addressing property.
                                      If none is present, the processor MUST fault.</p>
                              </item>
                              <item>
!                                 <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>
                              </item>
                          </ulist>
                      </item>
--- 662,680 ----
                              <item>
                                  <p>If the reply is a normal message, select the EPR from the
!                                     related message's [reply endpoint] message addressing property.
                                      If none is present, the processor MUST fault.</p>
                              </item>
                              <item>
!                                 <p>Otherwise, if the reply is a fault message and the related
                                      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 related
                                      message's [reply endpoint] message addressing property.
                                      Otherwise, if the [reply endpoint] property is empty, the
!                                     behavior of the recipient of the related message is
                                      unconstrained by this specification.</p>
                              </item>
+                             <item><p>In either of the above cases, if the related message lacks a [message id] property,
+                                 the processor MUST fault.</p></item>
                          </ulist>
                      </item>
***************
*** 715,722 ****
                      </item>
                  </olist>
!                 <p>The following example illustrates a request message containing message addressing
                      properties serialized as header blocks in a SOAP 1.2 message:</p>
                  <example>
!                     <head>Example request message.</head>
                      <eg xml:space="preserve"
                      >
--- 701,708 ----
                      </item>
                  </olist>
!                 <p>The following example illustrates a message containing message addressing
                      properties serialized as header blocks in a SOAP 1.2 message:</p>
                  <example>
!                     <head>Example message.</head>
                      <eg xml:space="preserve"
                      >
***************
*** 761,765 ****
                  <p>The following example illustrates a reply to the above message:</p>
                  <example>
!                     <head>Example response message.</head>
                      <eg xml:space="preserve"
                      >
--- 747,751 ----
                  <p>The following example illustrates a reply to the above message:</p>
                  <example>
!                     <head>Example reply message.</head>
                      <eg xml:space="preserve"
                      >
***************
*** 819,824 ****
                  confused with a replay attack. It is also advisable to use message identifiers that are not
                  predictable, to prevent attackers from constructing and sending
!                 an unsolicited reply to an outstanding request without having to 
!                 see the actual request message.</p>
              <p>When [reply endpoint] and/or [fault endpoint] do not contain the
                  anonymous URI, the processor of such an EPR should take care to avoid
--- 805,810 ----
                  confused with a replay attack. It is also advisable to use message identifiers that are not
                  predictable, to prevent attackers from constructing and sending
!                 an unsolicited reply to a message without having to 
!                 see the actual message.</p>
              <p>When [reply endpoint] and/or [fault endpoint] do not contain the
                  anonymous URI, the processor of such an EPR should take care to avoid

Received on Thursday, 2 June 2005 19:39:44 UTC