Re: Some pictures and questions

[christopher ferris <chris.ferris@east.sun.com>]

Rich,

Please see below.

Cheers,

Chris

Rich Salz wrote:
> 
> > Please see my responses below.
> 
> Great, thanks.  I'm approaching understanding. :)
> 
> > > So, are off-the-shelf browsers, mail programs, etc., intended to work
> > > as a "bundled-in" Originating MSH, or is it expected that additional
> > > code will be required on the client machine?
> >
> > the latter. Could be a plug-in, applet or some other mechanism.
> 
> Okay, so discussions like "the user repeatedly clicking on SEND" are not
> relevant, right?  That's come up a couple of times in the past week.

Well, it doesn't preclude this. The MSH could be light-weight
such that it didn't do the automated retry, but let the user decide.

> 
> > >From the "application's" perspective (client) as you point out,
> > there is no defined API, but because the MSH assumes responsibility
> > for the reliable delivery, an application *can* fire-n-forget
> > w/r/t the originating MSH. However, an application may require
> > synchronous exchange (e.g. it is going to block on a response)
> > and in this case the originating MSH has to perform its
> > function, await the response and return that response to
> > the calling application/client).
> 
> Synchronous with who -- the Target MSH or the From Party?  I *think* you
> mean the From Party, but I'm not positive.

By this I am referring to the From party all the way through the
To party (applications).

> 
> > In Tokyo, we discussed this and concluded that the intermediary
> > MSH was actually delivering the received message to a "routing
> > application" which made the determination as to the next
> > destination (resolving the To logical address to a physical
> > address of the next MSH in the chain). Thus, it is no different
> > than a terminal MSH in that it resolves the receipt of a message
> > to some application handler for processing.
> 
> So when the Intermediate MSH gets the message and acknowledges that to
> the Originating MSH, the Originating MSH is now "done"?  It must be,

That's my take, yes.

> else we would expect the Originating MSH to do pings and resends,

If it gets an ack, then it need not retry, cuz it can conclude
that the receiving MSH has assumed responsibility.

> right?  Actually, no it's not done, since it must be able to propagate
> later delivery failures back to the client.  This seems, again, to argue

These delivery failures are just messages for the application
(IMHO). The MSH couldn't care less;-) Again, what is it going
to do with this information? A retry is out of the question
most likely as it will only result in another delivery failure.

> that the MSH-to-MSH delivery failure message should contain all the
> state.  If the state is not in the failure message, then every MSH from

What state are we discussing here?

> the Originator and up to but not including the Target, must have enough
> state to back-propagate delivery failures.  Shared identical state
> across multiple services -- a recipe for disaster.  And that assumes the
> backward channel follows the exact same MSH path.

I have never had this misconception... others have/do as was
evident in the discussion the past few meetings. There can be
no assumption that the path that an ack takes is the same
as that taken by the original message *except* in the case
of a synchronous exchange which (IMHO) needs no explicit
ack message as the response is evidence enough that the
message was safely delivered.

> 
> > The intermediary should (IMHO) be supporting reliable delivery
> > and therefore it needs to persist the messages, ack them, etc.
> 
> Ack them?  To whom?

To the MSH node that delivered the message to it. That was
the intent of the SenderURI element of the RoutingHeader.
That was supposed to be the URI that the receiving MSH 
sends the acknowledgment.

> 
> > delivery ack is orthogonal to reliable messaging semantics
> > IMHO.
> 
> By "delivery ack" I meant MSH-to-MSH messages.  I do not see how you can
> get reliable messaing without positive ack *at the MSH layer.*  Was I
> unclear, or did you have a particular protocol in mind?

By delivery ack, I was referring to the DeliveryReceipt
which is not an MSH RM ack, but could be used for
nonrepudiation purposes by the From party. Obviously,
you were referring to the "intermediate" ack which is
the MSH RM ack. My bad;-)

> 
> I agree with the rest of your message.
> 
> Thanks.  I hope this will be useful input into future drafts.
>         /r$
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard