Re: Publication of EMSD as an Informational RFC

[Mohsen BANAN <mohsen@neda.com>]

>>>>> On Wed, 6 Jan 1999 17:09:22 -0800, braden@ISI.EDU said:

  braden> Hi. I have a question on EMSD.  Section 3.3 says, "The deliver
  braden> operation uses 3-way handshake service of ESROS."

  braden> This seems inconsistent with section C.1.1, where the request
  braden> data seems to be delivered without a 3-way handshake.  Am I
  braden> misunderstanding?

The example in C.1.1 is for Submit not for Deliver. However, the
Deliver Operation's PDU exchanges are very similar.

Section 3.3 is consistent with C.1.1 (had it been an example of
delivery) and there are no conflicts or mistakes there. 

The delivery of the email message and its success (the result) and the
ESRO 3-way hand shake are combined and are essentially the same in
this case. Nothing more than that is needed unless there is a failure.

In the following text I will explain how the notation of section 3.3.1
maps into the 3 PDU exchanges of 3-way handshake service of ESROS.

The notation representing the deliver operation is:

	deliver ES-OPERATION
	   ARGUMENT DeliverArgument
	   RESULT NULL
	   ERRORS {...} ::= 35;

The DeliverArgument, essentially contains all of the email message
to be delivered.

The scope of this explanation is limited to the case where the 
operation itself involves no "ERRORS" (e.g., no security failures, ...).
The scope of this explanation is limited to the case where the ESRO's
retransmission capabilities are successful and it does not include the
situations where the devliverVerify operation is required.

In the following description the outer level indentation corresponds to the
EMSD layer and the inner level indentation corresponds to the ESRO
layer.


A- EMSD-Server-Agent:
=====================

   The DeliverArgument (the entire mail message) is encoded.
   
   An ESROS-INVOKE.request  primitive with the value of 35 as the 
   "Operation-value" and the value of DeliverArgument as 
   the "Invoke-argument" -- see Table 2, page 10, of RFC-2188 for
   details -- is issued to the ESRO layer.

  
       1- ESRO-Invoker (Server Agent):
       -------------------------------

	  The ESRO-INVOKE-PDU is sent out with the value of 
	  DeliverArgument (the entire email) in the "Operation
          Information" field of the PDU.


       1- ESRO-Performer (User Agent):
       -------------------------------

	  The ESRO-INVOKE-PDU is received.

          An ESROS-INVOKE.indication is issued to the EMSD layer.

B- EMSD-User-Agent:
===================

   The user agent gets the ESROS-INVOKE.indication and verifies that
   DeliverArgument (the entire mail message) is all correct and that 
   everything else is also valid.

   It then issues a ESROS-RESULT.request with the value of NULL as the
   "Result-argument" to the ESRO Layer. In this case because the
   NULL RESULT -- not an ERROR -- is going out, the User Agent in
   fact is conveying success of the delivery.

       2- ESRO-Performer (User Agent):
       -------------------------------

	  The ESRO-RESULT-PDU is sent out with the value of NULL
          in the "Result-parameter" field.

       2- ESRO-Invoker (Server Agent):
       -------------------------------

	  The ESRO-RESULT-PDU is received.

	  An ESROS-RESULT.indication is issued to the EMSD layer.


C- EMSD-Server-Agent:
====================

   The server agent gets the ESROS-RESULT.indication and tags
   that email message as delivered (subject to a deliverVerify).



       3- ESRO-Invoker (Server Agent):
       -------------------------------

	  As a result of the operation of the ESRO state machine
	  an ESRO-ACK-PDU is sent out.


       3- ESRO-Performer (User Agent):
       -------------------------------

	  The ESRO-ACK-PDU is received.

	  This indicates a successful 3-way hand shake.

	  An ESROS-RESULT.confirm is issued to the EMSD layer.


D- EMSD-User-Agent:
====================

   The user agent gets the ESROS-RESULT.confirm which
   indicates that no further action is required with respect to this
   delivery. The EMSD-User-Agent signals the arrival of the message
   to the user.


The 3-way hand shake of ESRO includes the RESULT parameter of EMSD and
because of that, no additional PDU exchanges (beyond those 3 PDUs) is
needed.

This concludes the explanation of a successful case of the 
"deliver" operation.


Does this explanation address your question?


  braden> BTW, I wonder whether you considered using T/TCP instead of
  braden> ESRO for the transport protocol.

Yes. I have. On three separate occasions.  

Once in the 1994 time frame, once in the 1996 time frame and once a
few months ago.  

In the 1994 time frame in the context of earlier designs of EMSD, we
looked at T/TCP. The class of short message two-way pagers that were
targeted at that time had memory and cost constraints of the type that
had excluded the possibility of including TCP on them. Because T/TCP
rides with TCP and because of the perceived complexity of T/TCP,
its use was rulled out by the small embedded device group.

In the 1996 time frame in the context of credit card verification over
wireless networks, ESRO and T/TCP were considered as potential
transport candidates. That effort/analysis was not well organized and
did not progress towards a published protocol (as far as I know).  I
was not directly involved with that activity.


For quite a while, but not as a high priority item, I have been
interested in experimenting with T/TCP as a plug-in replacement for
ESRO.  That involves a clear mapping between the service definition of
ESRO and T/TCP. We have an ESRO C language service definition API
which probably can be mapped to the T/TCP services. If that is done
right, the rest should all fall into place without difficulty.

Because of the clear separation of layers in EMSD, this may in fact 
be quite possible.

After the publication of EMSD, if you are interested, we can work
together to make progress on that front.




I hope you find the above explanation helpful. 

Please let me know if you have any other questions.

As you know, I am quite anxious about timely publication of EMSD and
I will make every effort to provide you with additional information
about the protocol promptly.


Regards,

...Mohsen.