Re: RefToMessageID

[Nikola Stojanovic <nhomest1@twcny.rr.com>]

<Jacques>
(through its interface, which is still TBD)
</Jacques>

This (TBD) is what hurts us a little bit.

<Jacques>
But the MSH will not process this RefToMessageId (in normal messages) in any
way: only pass it along. If there is any intent to use this field for, say,
message ordering, or some check, it is up to the application.
...
The underlying guideline in (1) and (2) above is: whoever sets the
RefToMessageId (MSH layer vs. app layer) , is expected to interpret it.
</Jacques>

There is a notion of ImplicitAcknowledgement => If Recipient side sends back
to Sender side a Normal message with RefToMessageID, which is a MessageID
created by Sender (very abstract here, although I like Marty's "MIDDLEWARE"
and I would even imagine many (not only MSH and "App") "middlewares"
(components, ...) that could do something like
RelateThisMessageToThatMessage (MessageID doesn't need to be exposed to
"App")) Sender might assume that Recipient has received (and by putting it
in a Response message Acknowledged) Sender's message. So, in that case (when
ImplicitAcknowledgement is a valid concept) some kind of CPP/CPA might be
needed to coordinate different "layers" (like: do | don't send both Implicit
and Explicit Acks, ...).

<Jacques>
It could also reflect a tree-like linkage of messages.
</Jacques>

Yes.

Regards,
Nikola