Some pictures and questions

[rsalz@CaveoSystems.com]

I've been confused about reliability, synchronicity, intermediaries, etc.
Yesterday's call didn't help. :)

In order to understand it, I drew some pictures.  I hope that others
find them useful, too.  The numbered lines are intended to show the
ordering and sequencing of the data flows.

The internal line within the MSH boxes is intended to show that there
is per-transport (HTTP, SMTP, etc) code.  The internal line within the
Party boxes is intended to show that there is an API.

 +------------+                                         +------------+
 |            |                                         |            |
 | From Party |                                         |  To Party  |
 |------------|                                         |------------|
 +------------+                                         +------------+
    ||   ^^                                               ^^     ||
     1    6                                                3      4
    vv   ||                                               ||     vv
 +------------+                                         +------------+
 |           || ================== 2 =================> ||           |
 | Orig. MSH ||                                         ||Target MSH |
 |           || <================= 5 ================== ||           |
 +------------+                                         +------------+

The data transfer mechanism *and format* for (1) and (6) are not currently
defined; the spec says that a language-independant binding (I assume
that means Corba IDL) is a topic of future work.  This is also true for
(3) and (4).

The data transfer mechanism for 2 and 5 is defined for different
transports, and the data format is ebXML (section 7).

I'm pretty sure that all of the above is correct.  Now for the questions
and discusson.

I believe we want the behavior that the application sees to be the same,
no matter the delivery topology.  Is that right?

If the From Party is connecting via HTTP to the Target MSH, then the
>From Party is also the Orignating MSH.  Now, it will probably be a
poor-quality MSH.  In fact, it might be so limited that it cannot meet
the spec, in which case the the browser (or mail user-agent, etc.)
*cannot* be an Orig. MSH.  For example, implementation of timeouts and
retries will be difficult.

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?

Next question:  what does "reliable" mean, from the client's perspective?
Does it mean that it got to the Originating MSH, the Target MSH, or
the To Party?  It seems to me that it cannot always mean it got to the
To Party, because that might be a big-iron batch process that isn't
scheduled to run until later.  For example, the best that the Target
MSH might be able to do is punch the cards and signal the operator to load
the deck. (Okay, maybe not cards.  Maybe write the 9track tape. :)

When Intermediate MSH's are involved, as shown below, does the meaning
of reliable change?

Last week we were approaching consensus to move to a point-to-point
protocol.  That would imply that reliable means "the next transit
agent got the message."  So the From Party has no visibility beyond
Originating MSH, and the Originating MSH only knows that the Intermediate
MSH accepted responsibility.

 +------------+                                         +------------+
 |            |                                         |            |
 | From Party |                                         |  To Party  |
 |------------|                                         |------------|
 +------------+                                         +------------+
    ||   ^^                                               ^^     ||
     1    6                                                3      4
    vv   ||                                               ||     vv
 +------------+              +------------+             +------------+
 |           || ==== 2.1 ==> ||          || === 2.2 ==> ||           |
 | Orig. MSH ||              ||Inter. MSH||             ||Target MSH |
 |           || <=== 5.2 === ||          ||<=== 5.1 === ||           |
 +------------+              +------------+             +------------+

What does "reliable" mean from an MSH's perspective?  Does it mean it got
to the next hop, or that it got to the target MSH? Is an MSH expected to
know if it's an Originator or an Intermediate? In the event of delivery
failure (e.g., the Target MSH determines that there is no such To PArty),
is the intent that the failure notice go to the Intermediate MSH for
delivery to the Originator or directly to the Originator?

How much state are we going to require the Intermediate MSH to keep?
Is it just a pass-through pipe, or is it expected to do its own resends
and re-acks, for example?

I think "synchronous" also gets into the picture...  What's the intended
behavior when an MSH says "I got your message" and later on finds out it
is unable to deliver it?  If the From Party API blocks until the message
is received, that's synchronous delivery, right?  If it doesn't block,
then the Originating MSH can only say "apparently queued successfully".
And later on -- via interrupt, callback, or explicitly query API --
the Originating MSH will be able to inform the From Party that delivery
failed.

Should all delivery failures be sent to the Originating MSH?  I think
they have to be, because the failing MSH has no way of knowing if the
>From Party is blocked in the API, looping in a queue read, or whatever.

Do we need delivery ACK notices?  Without them, then either:
    a.  an MSH must maintain state to tell its client about the failure; or
    b.  the Failure must contain the state
Is there another alternative?

Okay, that's enough.  Hope this more helpful than harmful.
	/r$