If X intends the message to go to Y but is not concerned with what happens
between C and Y, it either isn't reliable messaging. An alternative view
is that C is the To party and Y, perhaps, is C's subcontractor and indeed
should be invisible to X. Similarly with X and B.
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
*************************************************************************************
David Smiley <> on 08/14/2001 11:47:21 AM
To: "'Dan Weinreb '" <>
cc: "' '" <>
Subject: RE: T2 - Assertions and Questions
Dan,
You have interpreted my meaning correctly. Take your example:
X <-> A <-> B <-> C <-> Y
where the "chasm" is between B and C.
X sends messages intended for Y to C. X is not concerned with what happens
after successfully delivering the message to C.
Y sends messages intended for X to B. Y is not concerned with what happens
after successfully delivering the message to B and has no awareness of A
whatsoever. A is X's business.
David
-----Original Message-----
From: Dan Weinreb
To: David Smiley
Cc:
Sent: 8/14/2001 10:37 AM
Subject: Re: T2 - Assertions and Questions
Date: Mon, 13 Aug 2001 15:20:48 -0400
From: David Smiley <>
This is interesting. So suppose we have end parties X and Y, and
they're communicating through three intermediarites A, B, and C:
X <-> A <-> B <-> C <-> Y
If I understand you correctly, one of these hops is considered the
"chasm"; let's say it's the hop between B and C. Then:
Assertion #2:
The To Party defines the location where messages intended for it are
to be
sent.
In other words, when X and Y agree on a CPA, the CPA will assert that
the communication-protocol-level address for party Y is the address
that actually talks to C; and the address given for X is really B's
address. Is that what you're saying?
Assertion #3C:
For our purposes, there is no such thing as a multi-hop message.
Question #1:
Can we eliminate any references to multi-hop or intermediate MSH from
the
spec?
As I understand it, you're not saying that messages actually never take
multiple hops, but rather than it *seems* as if they don't, "for our
purposes".
So if I'm understanding correctly, the way I would phrase Assertion
#3C is "At the level of abstraction of the Message Services protocol,
there is no concept of a multi-hop message". The interactions between
X, A, and B (and those between Y and C) are handled at a lower level
of abstraction, hidden from the higher level. At the higher level, X,
A, and B together looks like a single entity; there is some lower
level that talks about how X, A, and B communicate among themselves.
Is that the idea?
-- Dan
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to:
