Additional Proposals for Resolution of Issue 50

Since 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)

“

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

“