- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 02 Jun 2005 19:39:43 +0000
- To: public-ws-addressing-eds@w3.org
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