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

Full text for Issue 50 Proposal

From: Tom Rutt <tom@coastin.com>
Date: Mon, 14 Mar 2005 15:10:34 -0500
Message-ID: <4235EFBA.1090707@coastin.com>
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>

I had previously sent two emails, I now have put both mails together for 
the complete proposal for Issue 50.

Minimal change proposal for Core Spec to reflect agreements from 3/7 
Teleconference Call

These proposals, which are intended to convey a minimal change, assume 
we retain the definition of the anonymous address.

As an alternative, one could reformulate alternative proposals which get 
rid of the uri for anonymous, but result in the same semantics as that 
resulting from the proposals below. However, this would require 
repeating the equivalent of the “definition of anonymous” in the 
definitions for wsa:To and wsa:ReplyTo.

I leave this exercise for another email.

There was general agreement to align the text for wsa:ReplyTo with that 
of wsa:To.

Current text for wsa:To:
“
/wsa:To
This OPTIONAL element (of type xs:anyURI) provides the value for the 
[destination] property. If this element is NOT present then the value of 
the [destination] property is 
"http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the 
[children] of this element convey the value of this property.
“

Proposal 1):
Change:
“
/wsa:ReplyTo
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.
“
To:
“
/wsa:ReplyTo
This OPTIONAL element (of type wsa:EndpointReferenceType) provides the 
value for the [reply endpoint] property. If this element is NOT present 
then the value of the [reply endpoint] property is 
"http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the 
[children] of this element convey the value of this property. If this 
element is present, wsa:MessageID MUST be present.
“


There was also general agreement to have fault to default to the value 
for replyto:

Proposal 2):
Change:
“
/wsa:FaultTo
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.
“
to
“
/wsa:FaultTo
This OPTIONAL element (of type wsa:EndpointReferenceType) provides the 
value for the [fault endpoint] property. If this element is NOT present 
then the value of the [fault endpoint] property is the same as the value 
of the [reply endpoint] property. If this element is present, 
wsa:MessageID MUST be present.
“

There is also a need to tweak the corresponding abstract property text 
in section 3, since we have introduced the default semantics in the 
wsa:replyTo and wsa:FaultTo elements.:
• The abstract property definition for [reply endpoint] now has a 
default, so the second sentence is no longer appropriate.
• The abstract property definition for [message id] states that it must 
be present if a reply is expected, so the last sentence is not required 
in the definitions of [reply endpoint] and [fault endpoint].

Proposal 3):
Change:
“
[reply endpoint] : endpoint reference (0..1)
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 3.2 Formulating a Reply 
Message. If this property is present, the [message id] property is REQUIRED.
[fault endpoint] : endpoint reference (0..1)
An endpoint reference for the intended receiver for faults related to 
this message. When formulating a fault message as defined in 3.2 
Formulating a Reply Message, 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.
“
to:
“
[reply endpoint] : endpoint reference (0..1)
An endpoint reference for the intended receiver for replies to this 
message. The sender MUST use the contents of the [reply endpoint] to 
formulate the reply message as defined in 3.2 Formulating a Reply Message.
[fault endpoint] : endpoint reference (0..1)
An endpoint reference for the intended receiver for faults related to 
this message. When formulating a fault message as defined in 3.2 
Formulating a Reply Message, the sender MUST use the contents of the 
[fault endpoint], of the message being replied to, to formulate the 
fault message.
“

Additional Proposals for Resolution of Issue 50

The text on property [message id] was tied to the mandatory nature of 
replyTo. Thus, we also need to reflect the use of default (e.g.., “back 
channel” mapping) case in the abstract definitions of messageID and 
Relationship.


Proposal 4):
In Section 3
Change:
“
[message id] : IRI (0..1)
An IRI that uniquely identifies this message in time and space. No two 
messages with a distinct application intent may share a [message id] 
property. A message MAY be retransmitted for any purpose 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.
“
to:
“
[message id] : IRI (0..1)
An IRI that uniquely identifies this message in time and space. No two 
messages with a distinct application intent may share a [message id] 
property. A message MAY be retransmitted for any purpose 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 the response is going to anonymous destination, there is no need for 
the relatesTo to be sent in the reply message.

Proposal 5):
In Section 3.1:
Change:
“
/wsa:RelatesTo
This OPTIONAL (repeating) element information item contributes one 
abstract [relationship] property value, in the form of a (IRI, IRI) 
pair. The [children] property of this element (which is of type 
xs:anyURI) conveys the [message id] of the related message. This element 
MUST be present if the message is a reply.
“
to:
“
/wsa:RelatesTo
This OPTIONAL (repeating) element information item contributes one 
abstract [relationship] property value, in the form of a (IRI, IRI) 
pair. The [children] property of this element (which is of type 
xs:anyURI) conveys the [message id] of the related message. This element 
MUST be present if the message is a reply to a message containing a 
wsa:MessageId element.
“

-----

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Monday, 14 March 2005 20:12:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT