- From: Marc Hadley <mhadley@dev.w3.org>
- Date: Tue, 15 Feb 2005 22:53:39 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv2381
Modified Files:
ws-addr-core.xml
Log Message:
Added resolution to issue 46
Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -C2 -d -r1.30 -r1.31
*** ws-addr-core.xml 10 Feb 2005 11:09:24 -0000 1.30
--- ws-addr-core.xml 15 Feb 2005 22:53:36 -0000 1.31
***************
*** 459,486 ****
SHOULD be used. </p>
<p>The [address] properties of two endpoint references are compared according to
! Section 6 of [<bibref ref="RFC2396"/>].
! <!-- Resolving i001
! The [reference properties] of two
! endpoint references are equal if:
! -->
! </p>
! <!-- Resolving i001
! <ulist>
! <item>
! <p>they contain the same number of individual properties;</p>
! </item>
! <item>
! <p>for each reference property in one endpoint reference there exists an
! equivalent reference property in the other. One [reference property] is
! equivalent to another [reference property] if their byte streams per
! Exclusive XML Canonicalization are equal.</p>
! </item>
! </ulist>
! -->
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
! definitions and policies apply to endpoint references whose addresses
! <!-- Resolving i001
! or reference properties
! --> differ.</p>
</div2>
<div2 id="eprlifecycle">
--- 459,465 ----
SHOULD be used. </p>
<p>The [address] properties of two endpoint references are compared according to
! Section 6 of [<bibref ref="RFC2396"/>].</p>
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
! definitions and policies apply to endpoint references whose addresses differ.</p>
</div2>
<div2 id="eprlifecycle">
***************
*** 496,517 ****
<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 general defined by both the semantics of the properties
! themselves and the implicit or explicit contract that governs the message exchange.
! If explicitly available, this contract can take different forms including but not
! being limited to WSDL MEPs and interfaces; business processes and e-commerce
! specifications, among others, can also be used to define explicit contracts between
! the parties. 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>Message addressing properties collectively augment a message with the following
abstract properties to support one way, request reply, and any other interaction
--- 475,495 ----
<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
! general defined by both the semantics of the properties themselves and the implicit
! or explicit contract that governs the message exchange. If explicitly available,
! this contract can take different forms including but not being limited to WSDL MEPs
! and interfaces; business processes and e-commerce specifications, among others, can
! also be used to define explicit contracts between the parties. 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>Message addressing properties collectively augment a message with the following
abstract properties to support one way, request reply, and any other interaction
***************
*** 533,538 ****
<label> [reply endpoint] : endpoint reference (0..1)</label>
<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"/>.
--- 511,516 ----
<label> [reply endpoint] : endpoint reference (0..1)</label>
<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"/>.
***************
*** 543,552 ****
<label> [fault endpoint] : endpoint reference (0..1)</label>
<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 to
! formulate the fault message. If this property is present, the [message
! id] property is REQUIRED.</p>
</def>
</gitem>
--- 521,530 ----
<label> [fault endpoint] : endpoint reference (0..1)</label>
<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 to formulate
! the fault message. If this property is present, the [message id]
! property is REQUIRED.</p>
</def>
</gitem>
***************
*** 738,741 ****
--- 716,730 ----
</gitem>
</glist>
+ <div3>
+ <head>Comparing URIs</head>
+ <p>The values of the Message Addressing Properties [action], [message id],
+ and [relationship] are absolute URIs. The purpose of these URIs is
+ primarily identification, rather than resource retrieval. As such,
+ simple string comparison, as indicated in Internationalized Resource
+ Identifiers<bibref ref="IRI"/> section 5.3.1, is sufficient to determine equivalence
+ of these URIs.</p>
+
+ </div3>
+
</div2>
<div2 id="formreplymsg">
***************
*** 825,834 ****
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
<titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>,
! S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt. </bibl>
! <bibl id="RFC2396" key="RFC 3986"
href="http://www.ietf.org/rfc/rfc3986.txt">
T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
! W3C/MIT, January 2005.</bibl>
<bibl id="XML10" key="XML 1.0" href="http://www.w3.org/TR/2000/REC-xml-20001006">
<titleref>Extensible Markup Language (XML) 1.0 (Second Edition)</titleref>, T.
--- 814,823 ----
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
<titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>,
! S. Bradner. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt. </bibl>
! <bibl id="RFC2396" key="IETF RFC 3986"
href="http://www.ietf.org/rfc/rfc3986.txt">
T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax,",
! W3C/MIT, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt</bibl>
<bibl id="XML10" key="XML 1.0" href="http://www.w3.org/TR/2000/REC-xml-20001006">
<titleref>Extensible Markup Language (XML) 1.0 (Second Edition)</titleref>, T.
***************
*** 885,888 ****
--- 874,880 ----
> OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>,
March 2004.</bibl>
+ <bibl id="IRI" key="IETF RFC 3987" href="http://www.ietf.org/rfc/rfc3987">M. Duerst, M. Suignard,
+ "Internationalized Resource Identifiers (IRIs)", January 2005. Available at http://www.ietf.org/rfc/rfc3987.
+ </bibl>
</blist>
</div1>
Received on Tuesday, 15 February 2005 22:53:39 UTC