Re: RefToMessageID

[jacques durand <jacques@savvion.com>]

Martin:

Martin W Sachs wrote:

> Nikola,
>
> You say "I am mostly motivated here in avoiding to the application the need
> to deal with IDs that are not business level,...".

That quote was actually from me (Jacques) but Nikola seems to endorse it.
<Jacques>(until email browsers are XML enabled,  these tags may be hard to track in
emails :)</Jacques>

>
>
> I agree.  The procurement application should not have to deal with those
> IDs but application-support middleware will have to deal with them.  As has
> been said before, this middleware is in the application layer but it
> performs support services for all applications and works best if the
> information it needs to deal with is provided in an application-independent
> way.

I am not sure what "application-independent" means exactly here,
but let me summarize my interpretation of the TRP spec with regard to this chaining
of normal messages through RefToMessageId, and the role
I assume  an MSH implementation will have here:

1. the MSH makes it possible (through its interface, which is still TBD) for the app to
- access MSH-generated MessageID of received messages, as well as of sent messages
- access and set RefTopMessageId of normal messages
The MSH never sets itself this field in normal messages (messages that are created by an
app).
If the RefToMessageId element is there in a normal message, it must be set to a previous
valid MessageId by the app.
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.

2. the MSH will set the RefTopMessageId in messages it generates by itself
(Acks and Errors, as well as "service" messages: status responses, pings)
and  process it appropriately (e.g.. a sender MSH will remove from its temporary msg
store
messages that have been well acknowledged, using the RefTopMessageId).

The underlying guideline in (1) and (2) above is:
whoever sets the RefToMessageId (MSH layer vs. app layer) , is expected to interpret it.

NOTE: I would not make  stronger requirements in the spec as what should be the
content of RefToMessageId if used in a business message (previously sent message ID?
last received message ID? It could actually be either one or the other, as in *some*
conversations
a sender  may actually send several messages without waiting for response.
It could also reflect a tree-like linkage of messages.
This is really up to the app  it seems to me, and the MSH should not do more than
checking
this element is not empty *when present*.

Regards,

jacques Durand
Savvion

> It is also outside the scope of the TRP specifications but the only
> carrier for this information that ebXML has is the messaging service
> headers.
>
> Regards,
> Marty
>
> *************************************************************************************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> *************************************************************************************
>
> Nikola Stojanovic <nhomest1@twcny.rr.com> on 01/08/2001 06:55:23 PM
>
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  Re: RefToMessageID
>
> <Martin>
> The only role the Messaging Spec needs to play is to provide an
> application-independent place to carry this piece of information in normal
> messages. Application independence is significant since this field is one
> which B2B middleware might process.
> </Martin>
>
> <Jacques>
> These practical considerations aside (I do not see any problem with
> providing to an app the MSH service of accessing and setting
> RefToMessageId),
> ...
> I am mostly motivated here in avoiding to the application the need to deal
> with IDs that are not business level, but again it does not hurt to have
> the
> MSH allow for this, as it can be useful in cases I may not have in mind.
> It becomes mostly an app design decision to use it or not (after all, V0.91
> says that RefToMessageId MUST contain a valid ref value *when present*...)
> </Jacques>
>
> It is nice to see that we are thinking along these lines.
>
> Regards,
> Nikola