W3C home > Mailing lists > Public > public-ws-addressing-eds@w3.org > January to March 2005

2004/ws/addressing ws-addr-core.xml,1.30,1.31

From: Marc Hadley <mhadley@dev.w3.org>
Date: Tue, 15 Feb 2005 22:53:39 +0000
To: public-ws-addressing-eds@w3.org
Message-ID: <E1D1BZb-0000ci-2Q@lionel-hutz.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:01 UTC