Re: RefToMessageID

[Martin W Sachs <mwsachs@us.ibm.com>]

Jacques,

You are describing exactly what I had assumed and I agree with it.

"Application-independent" simply means functions that are done the same way
by all applications and therefore are candidates for support by middleware.

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
*************************************************************************************



jacques durand <jacques@savvion.com> on 01/09/2001 12:53:08 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Nikola Stojanovic <nhomest1@twcny.rr.com>, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>
Subject:  Re: RefToMessageID



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