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

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

From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 02 Jun 2005 18:47:08 +0000
To: public-ws-addressing-eds@w3.org
Message-Id: <E1Dduii-0006xi-6y@lionel-hutz.w3.org>

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

Modified Files:
	ws-addr-core.xml 
Log Message:
Added resolution to issue lc89 - assorted editorial fixes

Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.93
retrieving revision 1.94
diff -C2 -d -r1.93 -r1.94
*** ws-addr-core.xml	2 Jun 2005 18:15:28 -0000	1.93
--- ws-addr-core.xml	2 Jun 2005 18:47:06 -0000	1.94
***************
*** 210,214 ****
                                  items that are required to properly interact with the endpoint.
                                  Reference parameters are provided by the issuer of the endpoint
!                                 reference and are assumed to be opaque to consuming applications.
                                  The binding of reference parameters to messages depends upon the
                                  protocol binding used to interact with the endpoint -
--- 210,215 ----
                                  items that are required to properly interact with the endpoint.
                                  Reference parameters are provided by the issuer of the endpoint
!                                 reference and are assumed to be opaque to other users of an
!                                 endpoint refernce.
                                  The binding of reference parameters to messages depends upon the
                                  protocol binding used to interact with the endpoint -
***************
*** 222,227 ****
                              <p>A reference may contain metadata that describes the behavior,
                                  policies and capabilities of the endpoint. Metadata may be included
!                                 in an endpoint reference to facilitate easier processing by the
!                                 consuming application, or because the metadata was dynamically
                                  generated.</p>
                              <p>The metadata embedded in an EPR is not necessarily a complete
--- 223,228 ----
                              <p>A reference may contain metadata that describes the behavior,
                                  policies and capabilities of the endpoint. Metadata may be included
!                                 in an endpoint reference to facilitate easier processing by
!                                 a user of an endpoint reference, or because the metadata was dynamically
                                  generated.</p>
                              <p>The metadata embedded in an EPR is not necessarily a complete
***************
*** 492,496 ****
                              id] property. A message MAY be retransmitted for any reason including
                              communications failure and MAY use the same [message id] property. The
!                             value of this property is an opaque IRI whose interpretation beyond
                              equivalence is not defined in this specification. If a reply is
                              expected, this property MUST be present. </p>
--- 493,497 ----
                              id] property. A message MAY be retransmitted for any reason including
                              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>
***************
*** 504,509 ****
                              The related message is identified by an absolute IRI that corresponds to
                              the related message's [message id] property. The message identifier IRI
!                             may refer to a specific message, or be the following well-known URI that
!                             means "unspecified message": <attval>&nsuri;/id/unspecified</attval>
                          </p>
                          <p>This specification has one predefined relationship type as shown in
--- 505,510 ----
                              The related message is identified by an absolute IRI that corresponds to
                              the related message's [message id] property. The message identifier IRI
!                             may refer to a specific message, or be the following pre-defined URI that
!                             means "unspecified message": <attval>&nsuri;/unspecified</attval>
                          </p>
                          <p>This specification has one predefined relationship type as shown in
***************
*** 546,551 ****
                  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 standard URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: <attval>&nsuri;/address/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>
--- 547,552 ----
                  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>
***************
*** 582,586 ****
                                  [destination] property. If this element is NOT present then the
                                  value of the [destination] property is
!                                 <attval>&nsuri;/address/anonymous</attval>.</p>
                          </def>
                      </gitem>
--- 583,587 ----
                                  [destination] property. If this element is NOT present then the
                                  value of the [destination] property is
!                                 <attval>&nsuri;/anonymous</attval>.</p>
                          </def>
                      </gitem>
***************
*** 664,668 ****
                      <p>Comparison of [destination] property values is out of scope, other than using
                          simple string comparison to detect whether the value is anonymous, that is,
!                         where [destination] has the value "&nsuri;/address/anonymous".</p>
                  </div3>
              </div2>
--- 665,669 ----
                      <p>Comparison of [destination] property values is out of scope, other than using
                          simple string comparison to detect whether the value is anonymous, that is,
!                         where [destination] has the value "&nsuri;/anonymous".</p>
                  </div3>
              </div2>
***************
*** 801,805 ****
          <div1 id="securityconsiderations">
              <head>Security Considerations</head>
!             <p>Users of WS-Addressing and EPRs (i.e., entities creating, consuming or receiving
                  Message Addressing Properties and EPRs) SHOULD only use EPRs from sources they
                  trust. For example, such users might rely on the presence of a verifiable
--- 802,806 ----
          <div1 id="securityconsiderations">
              <head>Security Considerations</head>
!             <p>Users of WS-Addressing and EPRs (i.e., entities creating and receiving
                  Message Addressing Properties and EPRs) SHOULD only use EPRs from sources they
                  trust. For example, such users might rely on the presence of a verifiable
Received on Thursday, 2 June 2005 18:47:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:40 GMT