Re: Some pictures and questions

[Rich Salz <rsalz@caveosystems.com>]

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

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

> 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,
else we would expect the Originating MSH to do pings and resends,
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
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
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.

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

Ack them?  To whom?
 
> 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?

I agree with the rest of your message.

Thanks.  I hope this will be useful input into future drafts.
	/r$