Re: Correlation.MessageRef [was AM corrections]

Hi Stuart,

I think both Chris Ferris and I are somewhat unhappy with Correlation.MessageRef
being a local/relative reference.

IMO, the value of MessageRef (which I assume is something that would be embedded
in the message itself/binding) should not change as the message progresses
through intermediaries. It makes it hard otherwise to track messages, or to
refer to messages one has seen in the past.

For example, a given intermediary might send an ACK every 5 messages, and list
the corresponding MessageRef's. How would the sender know which messages are
being ACKed, if it used a different numbering scheme than the intermediary?

Jean-Jacques.


"Williams, Stuart" wrote:

> Local means local to one's point of reference ie. at the sender the
> reference is local to that sender, at an intermediary it is local to that
> intermediary, at a receiver it is local to that receiver. It's a local
> handle to a message.  You can think of it a bit like a local reference to a
> memory buffer (but that would be dangerous in practice because buffers get
> reused).

Jean-Jacques Moreau had written:

> Section 3.1.3 of the AM says:
> "The Correlation.MessageRef sub-field of the optional Correlation
> parameter on a XMLP_UnitData.receive primitive carries a **local**
> abstract reference to an XML protocol message that was previously
> forwarded by the intermediary XML protocol application."
>
> I suppose "local" is with respect to the initial sender, not the
> intermediary? (MessageRef  is immutable, and cannot be changed by
> intermediaries, right?) This is not quite clear from the text.

Chris Ferris also wrote:

> Yes, but my point was that MessageRef is a "local reference" or "handle"
> as Stuart has stated in previous postings. My question is then,
> where/how does the intermediary get this from if the message has
> never passed this way before?
>
> I suppose that one could argue that if an intermediary hadn't seen the
> message before, then the MessageRef would be meaningless to it,
> but I think I could make a case otherwise. Certainly, as a designer
> of an intermediary, I might make that mistake and wind up with
> software that didn't function correctly some of the time.

Received on Tuesday, 3 April 2001 08:45:48 UTC