Re: Some comments on your EMSD document

[Mohsen BANAN <mohsen@neda.com>]

>>>>> On Tue, 12 Jan 1999 13:21:10 -0800, braden@ISI.EDU said:

  Braden> Mohsen,

  Braden> I would like to pass along to you some suggestions that could
  Braden> improve the readibilty and acceptance of your EMSD document.
  Braden> These are simply marginal notes I made as I plowed through it.

Thank you.

I have found your comments quite useful.

  Braden> First of all, some examples would be very, very helpful.  In reply to
  Braden> my question, you gave me a long, detailed dissection of the steps in a
  Braden> simple error-free submission.  A simple diagram could have conveyed the
  Braden> same concepts much more compactly and much more clearly.

We have a lot of diagrams and examples and tutorials that when used
jointly with the spec. make the spec. much more understandable.  Some
of those diagrams/examples/tutorials are already on the web site at
emsd.org.

We will be adding a lot more such information to emsd.org over time.

I have deliberately kept the spec. relatively dry. This is kind of 
consistent with say the approach taken with IMAP, ...


  Braden> In fact, your
  Braden> lengthy explanation did not cover the important case, when there is a
  Braden> failure of the exactly-once semantics.  I am still not exactly clear
  Braden> when and how you use the verify messages.

I'll try to explain that a bit more in the context of your comments.


Before getting to the specifics, let's cover some general aspects.

I have gone through and processed all of your comments.
I have already incorporated most of them in the next rev. of my copy
of the spec. I will finish the rest tomorrow. 

After I am done with all the updates, how do you prefer for me to get
that back to you? I can send you a complete updated spec.  Or I can
run a context diff and send the diffs to you. Or I can do both. Or, 
whatever else you prefer ...


In this message, I will respond to all of your comments first with the
following labels:

	AGREED:   Means I actually agree that something is wrong
                  and have either already fixed it for this RFC
                  or intend to fix it in future release of the 
                  protocol spec.

        EXPLANATION:  Means may be we don't understand each other
                 and I (or you) need more explanation.

        FIXED:    Means I have already done something to the spec.
                  that I believe adequately addresses your comments.

        FURTHER-DEVELOPMENT: Means more work needs to be done, but
                  that I don't think it is reasonable to try to do it
                  for this RFC publication and that I intend
                  to do it later. Sometimes added to Appendix D.

Many of the comments have more than one of the above labels.



Please, review my responses and let me know if you object to any of
them. I hope to be able to get a new draft that I believe satisfies
all of your comments out by tomorrow.

If I have missed anything or if you have other comments, please
forward them to me ASAP.

As you noted, publication of EMSD is not necessarily an end-point.
And, if after publication it proves to be useful we intend to improve
it in many ways. I view the current spec. (with reasonable mods) as an
adequate starting point that can result into progress in this area.
 

Let's work together quickly to have this finished.

Regards,

...Mohsen.


------------

  *>  
  *>  
  *>  INTERNET DRAFT			EXPIRES MAY 1998	INTERNET DRAFT
  *>  
  *>  ...
 
  *>                                  Neda's
  *>              Efficient Mail Submission and Delivery (EMSD)
  *>                    Protocol Specification Version 1.3
  *>  		  <draft-rfced-info-banan-00.txt>
  *>  
  *>  ...
  *>  
  *>  NOTE TO IESG AND RFC-EDITOR

  Braden> (This needs to be deleted or incorporated into the text).

- FIXED

I created a new section 1.7 titled "About This Specification" 
and moved that text there.

  *>  
  *>  1.4  Anticipated Uses Of EMSD
  *>  

  Braden> This section is not factually incorrect, but it has a flavor
  Braden> of hard sell about it.

I want to keep that section as is.
Others can disagree with these views ...
But that section reflects our views as the designers of this protocol.

  *>  
  *>  Efficient Mail Submission and Delivery User Agent (EMSD-UA): An
  *>      Application Process which incorporates both EMS-UA and EMD-UA
  *>      capabilities.
  *>  
  *>  

  Braden> I found these definitions confusing; I had to draw myself a picture to get
  Braden> them straight.  Your choice of "user" and "server" is confusing and
  Braden> semantically meaningless.  For push-mode delivery, the server is the
  Braden> client and the client is the server.  Would better choices have been
  Braden> "Terminal" and "Base".  Actually, the critical sentence that explains
  Braden> it comes at the beginning of the next section.

- FIXED

I have copied that critical sentence as a definition for
EMSD Protocol to the "Definition of Terms" section.
Which also includes a reference to Fig. 2.

  
  *>  This section offers a high level view of the Efficient Mail Submission
  *>  and Delivery Protocol and Format Standards (EMSD-P&FS).
  *>  

  Braden> It is wise to avoid introducing useless acronynms, which this
  Braden> one appers to be.

- EXPLANATION

EMSD-P&FS is actually used. Amongst other places in Fig. 2.


  *>  The EMSD-P&FS are used to transfer messages between the EMSD - Server
  *>  Agent (e.g., a Message Center) and the EMSD - User Agent (e.g., a
  *>  Two-Way Pager), see Figure 2.
  *>  

  Braden> Suggest moving this sentence (above) to beginning of section 1.5.

- AGREED
- FIXED

I copied it under the definition for EMSD-P.

And left it there for those readers who may have skiped over
the Preliminaries/Definitions section.


  Braden> uh, that seems misleading.  Of course EMSD-FS replaces RFC-822 for EMSD
  Braden> transmission!

- AGREED
- FIXED

The new text is:
----
    messages.  EMSD-FS is used in conjunction with the EMSD-P but is
    not a general replacement for RFC-822.  EMSD-FS defines a method
----    

  *>  
  *>      EMSD-P is responsible for wrapping a limited size message (see 1

  Braden> Which "1"?  You apparently mean "point 1. in section 1.3".

- AGREED
- FIXED
- EXPLANATION

Now it reads 

  "EMSD-P is responsible for wrapping a EMSD-FS message (see 1"

Which should make it clear the "1" is reference to EMSD-FS,

  *>      above) in a point-to-point envelope and submitting or delivering
  *>      it.  EMSD-P performs the envelope encoding and relies on the

  Braden> This seems like strange semantics for a "protocol".  It confuses
  Braden> protocol, which is an abstract set of rules, with the implementation
  Braden> that wraps, performs, ...

- AGREED
- FIXED
- EXPLANATION

Now it reads 

   "EMSD-P relies on the ..."

I got rid of "EMSD-P performs the envelope encoding" 
because it was redundant. 

I think the use of the word "wrap" in an Overview section is Okay.

  *>      reassembly.  The EMSD-P is expressed in terms of abstract services
  *>      using the ESROS notation.  This is described in the section
  *>      entitled Efficient Mail Submission and Delivery Protocol.
  *>  

  Braden> Introducing ESRO at this particular point does not seem logical.

- EXPLANATION

I don't consider that the formal introduction.

I think the Overview is the right place to mention that ESRO is used
...


  *>  
  *>  EM Submission is the process of transferring a message from EMDP-UA to

  EMDP-> EMSD?

- AGREED
- FIXED

 
  *>    o Message-submission (the submit operation)
  *>  
  *>    o Delivery-control (the deliveryControl operation).

  Braden> How about delivery-verify?

- AGREED
- FIXED
- EXPLANATION

The confusion there is that the spec. made the distinction
between "operations" and "service" without explaining it.

The new text is:

----
The Message-submission service enables an EMSD-UA to submit a message
to the EMSD-SA for transfer and delivery to one or more recipients.
The Message-submission Service comprises of the submit operation --
invoked by the EMSD-UA -- and possibly the submitVerify operation --
invoked by the EMSD-SA.

The Message-delivery service enables the EMSD-SA to deliver a message
to an EMSD-UA. The Message-delivery Service comprises of the deliver
operation -- invoked by the EMSD-SA -- and possibly the deliverVerify
operation -- invoked by the EMSD-UA.

EMSD-UA uses the following services:

  o Message-submission

  o Delivery-control (the deliveryControl operation).


EMSD-SA uses the following services:


  o Message-delivery

  o Submission-control (the submissionControl operation).
----

  *>    o Submission-control (the submissionControl operation).

  Braden> How about submit-verify?
  *>  

- AGREED
- FIXED
- EXPLANATION

Same as above.

  *>  
  *>   c. deliveryVerify
  *>  
  Braden> This list is redundant with that at the beginning of sectionk 3 (and
  Braden> they did not even agree).

- EXPLANATION

This is actually not redundant and is consistent, 
had the distinction between "service" and "operation" been 
clear. Now it should be better.

  *>  
  *>  
  *>  This operation's arguments are:
  *>  

  Braden> One of the things that makes this document really hard to read is
  Braden> the lack of indentation and other visual cues.  Here it is all
  Braden> pretty clear, but later when parameters get more complex, it is
  Braden> not only unclear, it may be wrong.

- AGREED
- EXPLANATION

This problem is a *LOT* less significant if 
one uses the PS or PDF formats.

The PS and PDF formats are available through www.emsd.org.

Do you want me to also send you the final PS format of the RFC?

  *>  

  Braden> And you need transition words, like "The fields are:".

- AGREED
- FIXED

  *>  
  *>  
  *>  The EMSD-UA SHALL not refuse performing the deliver ES-OPERATION

  Braden> Capitalized SHALL is not defined in section 1.6.  Do you mean MUST?

- AGREED
- FIXED

Yes.
  *>  message from all other messages.  When within the EMSD, it SHALL be

  SHALL-> MUST

- AGREED
- FIXED

  *>    password                [0]     IMPLICIT OCTET STRING
  *>                            SIZE (0..ub-password-length)) OPTIONAL
  *>  };
  *>  
  *>  -- StrongCredentials ::= NULL
  *>  -- for now.

  Braden> Using a password for a wireless network seems like pretty weak
  Braden> security!?

- EXPLANATION

The wireless networks that we have been using 
all have data-link layer confidentiality built in.

  *>  Small messages can benefit from the efficiencies of connectionless
  *>  feature of ESROS (See Efficient Short Remote Operations).

  Braden> (Section #?)

- AGREED
- FIXED

Ref to RFC-2188 added.

  *>  
  *>  Very large messages are transferred using the Connection Oriented
  *>  Transport Service.

  Braden> WHAT is the "Connection Oriented Transport Service"??

- AGREED
- FIXED

New text is:

---
Very large messages are transferred using protocols (e.g., SMTP) that
rely on Connection Oriented Transport Service (e.g., TCP).
---

  *>  then use of the segmenting/reassembly mechanism introduced in this
  *>  section is not necessary.  This feature is accommodated in this layer
  *>  by:
  *>  

  Braden> It *sounds* as if you have two layers of fragmentation, one in ESRO
  Braden> and one in EMSD.

- AGREED
- EXPLANATION

Yes. But,  segmenting/reassembly mechanism of the two layers 
have different efficiency and reliability characteristics.


  *>  
  *>  more than ub-total- number-of-segments segments can be derived from a
  *>  single message.
  *>  

  Braden>                 space   ^

- AGREED
- FIXED

  *>  
  *>    -- Content types between 32 and 63 (inclusive) are for
  *>    -- message types  defined within this and associated standards.

  Braden> ?? Who sets these standards, and how are they documented?

- AGREED 
- FIXED

New text is:

------
ContentType ::=  INTEGER
{
  -- Content type 0 is reserved and shall never be transmitted.
  reserved                                 (0),
  -- Content types between 1 and 31 (inclusive) are for
  -- internal-use only
  probe                                    (1), -- reserved
  delivery-report                          (2), -- reserved

  -- Content types between 32 and 63 (inclusive) are for
  -- message types  defined within this specifications.
  emsd-interpersonal-messaging-1995        (32),
  voice-messaging                          (33) -- reserved

  -- Content types beyond and including 64 are for
  -- bilaterally-agreed use between peers.
} (0..127);
-----


  *>  
  *>    o Submit operation with 3-Way handshake and Duplicate Operation
  *>      Detection Support Function is invoked.

  Braden> And the Message Center (Note that you have switched from your
  Braden> earlier user/server terminology to device/Message Center) does not
  Braden> forward the message until the 3WHS has completed.  That was, I
  Braden> presume, the import of the long example you gave in response to
  Braden> my earlier question.

- AGREED
- FIXED
- EXPLANATION

All refs to "Message Center/device" are changed to 
EMSD-SA/EMSD-UA.

The third bulet says that the message is sent only after the 
3WHS hsa been completed.

  *>    o Message is sent out by Message Center only if result operation is
  *>      confirmed or the operation is verified (in the case of
  *>      FAILURE.indication).
  *>  

  Braden> It is unclear to me what failure mode the verify request protects
  Braden> against.  When might there be a FAILURE.indication but SubmissionVerify
  Braden> succeeds?

Say when you are driving through a long tunnel where wireless coverage
is real bad for the duration of the ESRO re-transmits. After a while
SubmissionVerify kicks in and things start working again ....
SubmissionVerify can be subject to tries which are much longer than 
ESRO's re-transmits ...

Does that make sense?

  *>  
  *>    o A non-delivery report is sent by MTS only if the message is not
  *>      delivered.

  Braden> Do you mean this precisely as stated?  If so, it is not very
  Braden> reassuring.

  Braden> Suppose a message is submitted, the MC replies OK, then crashes.
  Braden> The terminal sends its final ACK to complete the 3WHS, but the
  Braden> message is lost.  What is missing is SMTP's "accept" message.

- EXPLANATION

I am not following you.

This section is about "Delivery". Your "Suppose" is about Submit.

Much of the "magic" of EMSD is centered around elimination of 
SMTP's "accept".

In the case of the submit, it is expected that the EMSD-SA does not
issue the Result.Request until the message is in persistent memory.
That takes of the crash problem. 

But, I am not sure if I understand your comment.


  *>  
  *>      delivery report is sent out.

  Braden> ?? How?

- EXPLANATION
- AGREED
- FIXED

Through an explicit deliveryVerify.

  *>  
  *>  ESRO Services don't detect duplicate invocation of operations.  As a

  Braden> I thought that ESRO provided exactly-once delivery.

- EXPLANATION

This is to protect against multiple invocations with the exact same 
argument. ESRO can't protect against that.

  *>  result, the Duplicate Operation Detection Support Functional Unit is

  Braden> What is a "functional unit"?

- EXPLANATION

It is not a layer.
It is not a protocol.

But, it is of use to possibly more than just EMSD.

Can you think of a better than "functional unit" name?

To me that name is not all the important.

  *>      Instance Identifiers that are checked against duplication.  When a
  *>      performer profile indicates support for 0 outstanding Operation
  *>      Instance Identifier, it means it does not have support for
  *>      Duplicate Operation Detection.  In this case, there should be only
  *>      one outstanding operation at any point of time.

  Braden> ?? How can the invoker assure that?  It has not control over whether
  Braden> the network makes delayed duplicates.  It has to wait for one
  Braden> maximum segment lifetime before sending another request.

Yes.

That was put there for some pager developers who wanted to assure that
all invoked ESRO operations were "serial" (i.e., one at a time).

I left this there because I felt that it wasn't doing much harm to
anyone because it is qualified with the "when".


  *>      is an smaller Operation Instance Identifier on performer side with
  *>      the distance explained above, it will be expired.
  *>  

  Braden> In other (fewer!) words, the 8 bit OIId is used as a modular sequence
  Braden> space.

  Braden> It is unclear why the performer needs to keep all the previous numbers;
  Braden> it need only test for monotonicity.

- EXPLANATION

Theoretically it is possible to over run.

  *>  
  *>  5.1  MTS Behavior
  *>  
  *>  The MTS is event-driven.

  Braden> You already said that.

- EXPLANATION

It is harmless and sometimes useful when 
reading the spec. in reference mode.

  *>  
  *>  If it received an event from ESROS, then it could be any of the
  *>  following types:
  *>  
  *>  
  *>    o Message submission indication;
  *>  
  *>    o Delivery verify indication;
  *>  
  *>    o Result indication for a submission verify operation;
  *>  
  *>    o Error indication for a submission verify operation;
  *>  
  *>    o Delivery control indication.

  Braden> How about Result & Error indications for a submission control operation?

  Braden> Also, an event must be completion of a 3WHS for message delivery.

- AGREED

Working on it.
Should be done by tomorrow.


On question for you.

I consider most of Chapter 5, non-essential. 
In that people who understand how the protocol should  work can
fill in the steps.

Also, I have already done the equivalent of that section in 3
different formats:
 1- text as in the current spec, 2- flow chart and 3- pseudo code.

I haven't decided which is better. No matter how I do it, it is 
too much for some and too little for others ...

What are your thoughts on this?

Is moving all of Chapter 5 into an appendix a good option?


  *>  
  *>    o indicating an elapsed timer (meaning that it's time to re-attempt
  *>      a message delivery)
  *>  

  Braden> This is very confusing!!  I can figure it out, but your job is to
  Braden> organize it clearly enough so it is not a pain.

- AGREED
- FURTHER-DEVELOPMENT

  *>  
  *>  
  *>  The MTS performer should first make sure that it has received an
  *>  INVOKE.indication.  Any other type of primitive shouldn't be occurring

  Braden> What is an INVOKE.indication?

- EXPLANATION

As defined in ESRO (page 10) ...

  *>  
  *>   2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way
  *>      SAP (see #7).

  Braden> How can a Message Submission request arrive as a 2-way SAP?  This is
  Braden> a clear protocol violation; why not just ignore it??!!

- AGREED
- FIXED

  *>  
  *>  The User Agent is event-driven.

  Braden> You already said that.

- EXPLANATION
 
Same as above.

  *>  
  *>  If it received an event from ESROS, then it could be any of the
  *>  following types:
  *>  
  *>  
  *>    o Message delivery indication;
  *>  
  *>    o Submission verify indication;
  *>  
  *>    o Result indication for a delivery verify operation;
  *>  
  *>    o Error indication for a delivery verify operation;
  *>  
  *>    o Submission control indication.

  Braden> Since this section is a symmetrical copy of the MTS section,
  Braden> my same comments apply.

Same as above.

  *>  
  *>  
  *>    o Message-submission
  *>  
  *>    o Delivery-control
  *>  

  Braden> ??? WHERE is the definition of Message-submission?

  Braden> How about Delivery-Verify?

- AGREED

I am working on it.
Should be ready by tomorrow.

  *>  
  *>  The EMSD Format Standard is designed to be fully consistent with
  *>  RFC-822 [3].  In many ways EMSD-FS can be considered to be an
  *>  efficiency oriented encoder and decoder.  Through use of EMSD-FS an

  Braden> A protocol is not an encoder/decoder.  A program has that role.

- EXPLANATION

But unlike EMSD-P, I don't consider EMSD-FS a protocol.

Also, this is an overview section. Also I am saying 
"In many ways EMSD-FS can be considered ...

I think the existing text is Okay.

  *>  RFC-822 message is converted to a more compact binary encoding.  This
  *> ...