Re: Need volunteer to draft definition of reliablemessaging,wasRE:reliable messaging - hop by hop

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Tue, 04 Sep 2001 14:23:43 -0400
   From: christopher ferris <chris.ferris@east.sun.com>

Gee, I really want to comment on this but I am genuinely not sure I am
mapping what you're saying into the terminology that I've been
thinking with.

   If the sending node never receives an Ack, it would then generate a
   DFN "message" and deliver it, in some implementation specific manner
   to the "From Party" which would then take some (external) action 
   (like call the administrator of the receiving node to find out what 
   the problem might be).

Could you clarify what you mean by the word "message" in double-quotes
above, and exactly what "node" means?

The way I've been thinking about it, there is a layer of software
modularity that we're calling the MSH, which implements the messaging
protocol that we are designing.  The MSH software runs on various
machines; the MSH's talk to each other via HTTP, SMTP, etc., represented
by the <======> in the figure below.

There is a higher layer of software that calls (invokes) the MSH,
asking it to do things like "please try to send this message and tell
me what happens", which we have variously called the "Party" or the
"application".  The two layers communicate via some abstract API-like
interface, represented by the vertical bars in the following:

    From Application       To Application
           ^                     ^
           |                     |
           |                     |
           v                     v
          MSH     <=======>     MSH


When you mentioned a DFN "message" above, at first I thought you were
referring to this interface (the vertical bars): the MSH might, for
example, return a value to the application, in the manner of a
subroutine return, although the details, as you say, would be
implementation-specific.  This "message" would mean "I, the MSH,
assert to you that the delivery that you requested has failed."

But then you followed by saying

   A DFN may be (and probably should be) delivered reliably, 

So now it sounds like you're using "DFN" to mean a message in the
sense of communcation flowing through the network (the <====>).  I
think that's an entirely different animal and we would be better off
if we had different terminology for the two things.

-- Dan