- 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
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 UTC