tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2524

 
 
 

Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3

Part 4 of 4, p. 63 to 83
Prev RFC Part

 


prevText      Top      Up      ToC       Page 63 
A  EMSD-P ASN.1 MODULE

   This section compiles in one place the complete ASN.1 Module for EM
   Submission and Delivery Protocol.

   EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=

   BEGIN

   EXPORTS EMSDORAddress, AsciiPrintableString, ContentType,
   DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber;

   -- Upper bounds

   ub-recipients  INTEGER ::= 256;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-reply-to INTEGER ::= 256;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-subject-field INTEGER ::= 128;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-password-length INTEGER ::= 16;
   ub-content-length INTEGER ::= 65535;
   -- also defined in EMSD-Probe
   ub-content-types INTEGER ::= 128;
   ub-message-id-length INTEGER ::= 127;
   ub-total-number-of-segments INTEGER ::= 32;
   ub-header-extensions INTEGER ::= 64;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-emsd-name-length INTEGER ::= 64;
   ub-emsd-address-length INTEGER ::= 20;
   ub-rfc822-name-length INTEGER ::= 127;
   ub-mime-version-length INTEGER ::= 8;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-mime-content-type-length INTEGER ::= 127;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-mime-content-id-length INTEGER ::= 127;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-mime-content-description-length INTEGER ::= 127;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-mime-content-transfer-encoding INTEGER ::= 127;
   -- also defined in EMSD-InterpersonalMessaging1995
   ub-local-message-nu INTEGER ::= 4096;

   ----------------------
   -- SUBMIT Operation --
   ----------------------

   submit ES-OPERATION

Top      Up      ToC       Page 64 
       ARGUMENT SubmitArgument
       RESULT SubmitResult
       ERRORS
       {
           submissionControlViolated,
           securityError,
           resourceError,
           protocolViolation,
           messageError
       } ::= 33;

   SubmitArgument ::= SEQUENCE
   {
     -- Security features
     security           [0]    IMPLICIT SecurityElement
                               OPTIONAL,

     -- Segmentation features for efficient transport
     segment-info                  SegmentInfo OPTIONAL,

     -- Content type of the message
     content-type                            ContentType,

     --
     -- THE CONTENT --
     --

     -- The submission content
     content                       ANY DEFINED BY content-type

   };

   SubmitResult ::= SEQUENCE

   {

     -- Permanent identifier for this message.
     -- Also contains the message submission time.
     -- See comment regarding assignment of message
     -- identifiers, at the definition of EMSDLocalMessageId.
     message-id                        EMSDLocalMessageId
       };

   --------------------------------
   -- Delivery Control Operation --
   --------------------------------

   deliveryControl ES-OPERATION

Top      Up      ToC       Page 65 
       ARGUMENT DeliveryControlArgument
       RESULT DeliveryControlResult
       ERRORS
       {
           securityError,
           resourceError,
           protocolViolation
       } ::= 2;

   DeliveryControlArgument ::= SEQUENCE
   {
     -- Request an addition of or removal of a set of restrictions
     restrict             [0]     IMPLICIT Restrict DEFAULT update,

     -- Which operations are to be placed in the restriction set
     permissible-operations  [1]     IMPLICIT Operations OPTIONAL,

     -- What maximum content length should be allowed
     permissible-max-content-length
                             [2]     IMPLICIT INTEGER
                                     (0..ub-content-length) OPTIONAL,

     -- What is the lowest priority message which may be delivered
     permissible-lowest-priority
                             [3]     IMPLICIT ENUMERATED
                                     {
                                        non-urgent     (0),
                                        normal         (1),
                                        urgent         (2)
                                     } OPTIONAL,

     -- Security features
     security                  [4]     IMPLICIT SecurityElement
                                                     OPTIONAL,

     -- User Feature selection
     user-features             [5]     IMPLICIT OCTET STRING OPTIONAL
   };

   DeliveryControlResult ::= SEQUENCE
   {
     -- Operation types queued at the EMSD-SA due to existing
     -- restrictions.
     waiting-operations    [0]   IMPLICIT Operations DEFAULT { },


     -- Types of messages queued at the EMSD-SA due to
     -- existing restrictions

Top      Up      ToC       Page 66 
     waiting-messages      [1]   IMPLICIT WaitingMessages DEFAULT { },

     -- Content Types of messages queued at the EMSD-SA
     waiting-content-types   SEQUENCE SIZE (0..ub-content-types) OF
                                           ContentType DEFAULT { }
   };

   Restrict ::= ENUMERATED
   {
       update                                      (1),
       remove                                      (2)
   };

   Operations ::= BIT STRING
   {
       submission                                  (0),
       delivery                                    (1)
   };


   WaitingMessages ::= BIT STRING
   {
       long-content                                (0),
       low-priority                                (1)
   };

   -- Delivery Verify Operation

   deliveryVerify ES-OPERATION

       ARGUMENT DeliveryVerifyArgument
       RESULT DeliveryVerifyResult
       ERRORS
       {
           verifyError,
           resourceError,
           protocolViolation
       } ::= 5;

   DeliveryVerifyArgument ::= SEQUENCE
   {
     -- Identifier of this message. This is the same identifier that
     -- was provided to the originator in the Submission Result.
     -- See comment regarding assignment of message identifiers,
     -- at the definition of EMSDMessageId.
     message-id                                      EMSDMessageId
   };

Top      Up      ToC       Page 67 
   DeliveryVerifyResult ::= SEQUENCE
   {
                            status  DeliveryStatus
   };

    DeliveryStatus  ::= ENUMERATED
   {
           no-report-is-sent-out                   (1),
           delivery-report-is-sent-out             (2),
           non-delivery-report-is-sent-out         (3)
   };

   -----------------------
   -- DELIVER Operation --
   -----------------------

   deliver ES-OPERATION
       ARGUMENT DeliverArgument
       RESULT NULL
       ERRORS
       {
           deliveryControlViolated,
           securityError,
           resourceError,
           protocolViolation,
           messageError
       } ::= 35;

   DeliverArgument ::= SEQUENCE
   {
     -- Identifier of this message. This is the same identifier that
     -- was provided to the originator in the Submission Result.
     -- See comment regarding assignment of message identifiers,
     -- at the definition of EMSDMessageId.
     message-id                                      EMSDMessageId,

     -- Time the message was delivered to the recipient by EMSD-SA
     message-delivery-time                           DateTime,

     -- Time EMSD-SA originally took responsibility for processing
     -- of this message. This field shall be omitted if the message-id
     -- contains an EMSDLocalMessageId, because that field contains
     -- the submission time within it.
     message-submission-time [0]     IMPLICIT   DateTime OPTIONAL,

     -- Security features
     security                [1]     IMPLICIT   SecurityElement OPTIONAL,

Top      Up      ToC       Page 68 
     -- SegContentTypementation features for efficient transport
     segment-info                               SegmentInfo OPTIONAL,

     -- The type of the content
     content-type                               ContentType,

     --
     -- THE CONTENT --
     --

     -- The submitted (and now being delivered) content
     content                       ANY DEFINED BY content-type

   };

   -- Submission Control Operation

   submissionControl ES-OPERATION
       ARGUMENT SubmissionControlArgument
       RESULT SubmissionControlResult
       ERRORS
       {
           securityError,
           resourceError,
           protocolViolation
       } ::= 4;

   SubmissionControlArgument ::= SEQUENCE
   {
     -- Request an addition of or removal of a set of restrictions
     restrict               [0]     IMPLICIT Restrict DEFAULT update,

     -- Which operations are to be placed in the restriction set
     permissible-operations  [1]     IMPLICIT Operations OPTIONAL,

     -- What maximum content length should be allowed
     permissible-max-content-length
                             [2]     IMPLICIT INTEGER
                                     (0..ub-content-length) OPTIONAL,

     -- Security features
     security                [3]     IMPLICIT SecurityElement
                                                     OPTIONAL
   };

   SubmissionControlResult ::= SEQUENCE
   {
     -- Operation types queued at the EMSD-SA due to existing

Top      Up      ToC       Page 69 
     -- restrictions.
     waiting-operations    [0]   IMPLICIT Operations DEFAULT { }

   };

   ----------------------------------
   -- Submission Verify Operation --
   ----------------------------------

   submissionVerify  ES-OPERATION

       ARGUMENT SubmissionVerifyArgument
       RESULT SubmissionVerifyResult
       ERRORS
       {
           submissionVerifyError,
           resourceError,
           protocolViolation
       } ::= 6;

   SubmissionVerifyArgument ::= SEQUENCE
     -- Identifier of this message. This is the same identifier that
     -- was provided to the originator in the Submission Result.
     -- See comment regarding assignment of message identifiers,
     -- at the definition of EMSDMessageId.
     {
        message-id                       EMSDMessageId
     };

   SubmissionVerifyResult ::= SEQUENCE
       {
           status  SubmissionStatus
       };

   SubmissionStatus::= ENUMERATED
   {
           send-message            (1),
           drop-message            (2)
   };

   -- GetConfiguration Operation
   -- To be fully defined later. This will possibly include,
   -- but not be limited to:
   --      get-local-time-zone
   --      get-protocol-version
   --      etc.

   getConfiguration ES-OPERATION

Top      Up      ToC       Page 70 
           ARGUMENT NULL
           RESULT NULL
           ERRORS
           {
               resourceError,
               protocolViolation
           } ::= 7;

   -- SetConfiguration Operation
   -- To be fully defined later.

   setConfiguration ES-OPERATION

           ARGUMENT NULL
           RESULT NULL
           ERRORS
           {
               resourceError,
               protocolViolation
           } ::= 8;

   -- Security --

   SecurityElement ::= SEQUENCE

   {
     credentials                   Credentials,
     contentIntegrityCheck         ContentIntegrityCheck OPTIONAL
   };

   Credentials ::= CHOICE
   {
     simple                          [0]   IMPLICIT SimpleCredentials
     -- Strong Credentials are for future study
     -- strong                       [1]   IMPLICIT StrongCredentials
     -- externalProcedure            [2]   EXTERNAL
   };

   SimpleCredentials ::= SEQUENCE

   {
     eMSDAddress                         EMSDAddress OPTIONAL,
     password                    [0]     IMPLICIT OCTET STRING
                                 (SIZE (0..ub-password-length)) OPTIONAL
   };

   -- StrongCredentials ::= NULL
   -- for now.

Top      Up      ToC       Page 71 
   -- ContentIntegrityCheck is a 16-bit checksum of content
   ContentIntegrityCheck ::= INTEGER (0..65535);

   SegmentInfo ::= CHOICE

   {
     first           [APPLICATION 2]         IMPLICIT FirstSegment,
     other           [APPLICATION 3]         IMPLICIT OtherSegment
   };

   FirstSegment ::= SEQUENCE

   {
     sequence-id                             INTEGER,
     number-of-segments                      INTEGER
     -- number-of-segments must not exceed ub-total-number-of-segments

   };

   OtherSegment ::= SEQUENCE

   {
     sequence-id                             INTEGER,
     segment-number                          INTEGER
   };

   -----------
   -- Errors --
   ------------

   protocolVersionNotRecognized  ERROR PARAMETER NULL ::= 1;

   submissionControlViolated  ERROR PARAMETER NULL ::= 2;

   messageIdentifierInvalid  ERROR PARAMETER NULL ::= 3;

   securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;

   deliveryControlViolated   ERROR PARAMETER NULL ::= 5;

   resourceError  ERROR PARAMETER NULL ::= 6;

   protocolViolation  ERROR PARAMETER NULL ::= 7;

   messageError  ERROR PARAMETER NULL ::= 8;

   SecurityProblem ::= INTEGER (0..127);

Top      Up      ToC       Page 72 
   --
   -- EXPORTED Definitions (for use by associated specifications) --
   --

   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);

   -- If this message was originated as an RFC-822 message, then this
   -- EMSDMessageId shall be the "Message-Id:" field from that message.
   -- If this message was originated within the EMSD domain,
   -- then this identifier shall be unique for the Message Center
   -- generating this id.

   EMSDMessageId ::= CHOICE
   {
     emsdLocalMessageId     [APPLICATION 4]  IMPLICIT
                            EMSDLocalMessageId,
     rfc822MessageId        [APPLICATION 5]  IMPLICIT
                            AsciiPrintableString
                            (SIZE (0..ub-message-id-length))

   };

   EMSDLocalMessageId ::= SEQUENCE
   {
     submissionTime                  DateTime,
     messageNumber                   INTEGER (0..ub-local-message-nu)
   };

   -- An Originator/Recipient Address in EMSD Environment

   EMSDORAddress ::= CHOICE
   {

Top      Up      ToC       Page 73 
     -- This is the local-format address
     emsd-local-address-format            EMSDAddress,


     -- This is a globally-unique RFC-822 Address
     rfc822DomainAddress                 AsciiPrintableString
   };



   EMSDAddress ::= SEQUENCE
   {
     emsd-address         OCTET STRING
                                    (SIZE (1..ub-emsd-address-length)),

     -- emsd-address is a decimal integer in BCD (Binary Encoded Decimal)
     -- format.
     -- If it had an odd number of digits, it is padded with 0 on
     -- the left.

     emsd-name                [0]     IMPLICIT OCTET STRING
                                      (SIZE (0..ub-emsd-name-length))
                                      OPTIONAL
   };

   DateTime ::= INTEGER;

   Iso8859String ::=  GeneralString;

   AsciiPrintableString ::= [ APPLICATION 0 ]
                            IMPLICIT Iso8859String (FROM

       (" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
        "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
        "?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
        "N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
        "^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
        "m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
        "|"|"}"|"~"|"\"|""""));

   ProtocolVersionNumber ::= [APPLICATION 1]    SEQUENCE
   {
     version-major                   INTEGER,
     version-minor           [0]     IMPLICIT INTEGER DEFAULT 0
   }
   END  -- end of EMSD-SubmissionAndDeliveryProtocol

Top      Up      ToC       Page 74 
B  EMSD-IPM ASN.1 MODULE

   This section compiles in one place the complete ASN.1 Module for
   EMSD-IPM.

   EMSD-InterpersonalMessaging1995 DEFINITIONS ::=

   BEGIN

   IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString
     FROM EMSD-SubmissionAndDeliveryProtocol;

   ub-recipients  INTEGER ::= 256;
   ub-reply-to INTEGER ::= 256;
   ub-subject-field INTEGER ::= 128;
   ub-header-extensions INTEGER ::= 64;
   ub-emsd-name-length INTEGER ::= 64;
   ub-mime-version-length INTEGER ::= 8;
   ub-mime-content-type-length INTEGER ::= 127;
   ub-mime-content-id-length INTEGER ::= 127;
   ub-mime-content-description-length INTEGER ::= 127;
   ub-mime-content-transfer-encoding INTEGER ::= 127;

   IPM ::=   SEQUENCE

   {
     heading                              Heading,
     body                                 Body OPTIONAL
   };

   Heading ::= SEQUENCE
   {
     -- Address of the sending agent (person, program, machine) of
     -- this message. This field is mandatory if the sender
     -- is different than the originator.
     sender                      [0]     EMSDORAddress OPTIONAL,

     -- Address of the originator of the message
     -- (not necessarily the sender)
     originator                          EMSDORAddress,

     -- List of recipients and flags associated with each.
     recipient-data                      SEQUENCE SIZE (1..ub-recipients)
                                         OF PerRecipientFields,

     -- Flags applying to this entire message
     per-message-flags           [1]     IMPLICIT BIT STRING

Top      Up      ToC       Page 75 
     {
        -- Priority values
        -- At most one of "non-urgent" and "urgent" may be specified
        -- concurrently.  If neither is specified, then a Priority
        -- level of "normal" is assumed.
        priority-non-urgent             (0),
        priority-urgent                 (1),

        -- Importance values
        -- At most one of "low" and "high" may be specified
        --  concurrently.  If neither is specified, then an
        -- Importance level of "normal" is  assumed.
        importance-low                  (2),
        importance-high                 (3),

        -- Indication of whether this message has been automatically
        -- forwarded
        auto-forwarded                  (4)
      }  OPTIONAL,

     -- User-specified recipient who is to receive replies to this
     -- message.
     reply-to                    [2]     IMPLICIT SEQUENCE SIZE
                                         (1..ub-reply-to)
                                         OF EMSDORAddress OPTIONAL,

     -- Identifier of a previous message, for which this message
     -- is a reply
     replied-to-IPM                       EMSDMessageId OPTIONAL,

     -- Subject of the message.
     subject                     [3]     IMPLICIT AsciiPrintableString
                                         (SIZE (0..ub-subject-field))
                                                   OPTIONAL,

     -- RFC-822 header fields not explicitly provided for in
     -- this Heading. For messages incoming from the external
     -- world (i.e. in RFC-822 format), the Message-Id: field
     -- need not go here, as it is placed in the
     -- Envelope's EMSDMessageId (message-id) field.
     extensions                [4]   IMPLICIT  SEQUENCE
                               (SIZE (0..ub-header-extensions))
                                     OF  IPMSExtension OPTIONAL,

     -- MIME Version (if other than 1.0)
     mime-version            [5]     IMPLICIT AsciiPrintableString
                                     (SIZE
                                     (0..ub-mime-version-length))

Top      Up      ToC       Page 76 
                                             OPTIONAL,

     -- Top-level MIME Content Type
     mime-content-type       [6]     IMPLICIT AsciiPrintableString
                                     (SIZE (0..
                                      ub-mime-content-type-length))
                                                OPTIONAL,

     -- MIME Content Id
     mime-content-id         [7]     IMPLICIT AsciiPrintableString
                                     (SIZE (0..
                                      ub-mime-content-id-length))
                                               OPTIONAL,

     -- MIME Content Description
     mime-content-description [8]    IMPLICIT AsciiPrintableString
                                     (SIZE (0..
                                  ub-mime-content-description-length))
                                               OPTIONAL,

     -- Top-level MIME Content Type
     mime-content-transfer-encoding
                              [9]     IMPLICIT AsciiPrintableString
                        (SIZE (0..ub-mime-content-transfer-encoding))
                                                  OPTIONAL
   };

   PerRecipientFields ::= SEQUENCE
   {
     recipient-address                            EMSDORAddress,
     per-recipient-flags                          BIT STRING

      {
         -- Recipient Types.
         -- At most one of "copy" and "blind-copy" may be
         -- specified concurrently for a single recipient.  If
         -- neither is specified, than the recipient
         -- is assumed to be a "primary" recipient.
         recipient-type-copy                             (0),
         recipient-type-blind-copy                       (1),

         -- Notification Request Types.
         -- Only one of "rn" and "nrn" may be specified
         -- concurrently, \x110011 for a single recipient.
         -- "rn" implies "nrn" in addition.
         notification-request-rn                         (2),
         notification-request-nrn                        (3),
         notification-request-ipm-return                 (4),

Top      Up      ToC       Page 77 
         -- Report Request Types
         -- At most one of these should be set for a
         -- particular recipient. "delivery" implies "non-delivery"
         -- in addition.
         report-request-non-delivery                     (5),
         report-request-delivery                         (6),

         -- Originator-to-Recipient request for a reply.
         reply-requested                                 (7)
      }  DEFAULT { report-request-non-delivery }

   };

   IPMSExtension ::= SEQUENCE
   {
     x-header-label                      AsciiPrintableString,
     x-header-value                      AsciiPrintableString
   };

   Body ::= SEQUENCE
   {
     compression-method          [0]     IMPLICIT CompressionMethod
                                                    OPTIONAL,
     -- If compression method is not specified,
     -- "no-compression" is implied.

     message-body                        OCTET STRING
     -- See MIME for structure of the Body.
     -- If a compression method is specified, the entire text containing
     -- the Content-Type: element followed by the RFC-822 body are
     -- compressed using the specified method, and placed herein.
   };

   CompressionMethod ::= INTEGER
   {
     -- Compression Methods numbered 0 to 63 are reserved for
     -- assignment within this and associated specifications.
     no-compression                  (0),
     lempel-ziv                      (1)

     -- Compression Methods numbered between 64 and 127 may be
     --  used on a bilaterally-agreed basis between peers.
   } (0..127)

   END  -- end of EMSD-InterpersonalMessaging1995

Top      Up      ToC       Page 78 
C  RATIONALE FOR KEY DESIGN DECISIONS

   This section summarizes the rationale behind key design decisions
   that were made while developing the EMSD Protocols.

C.1  Deviation From The SMTP Model

   SMTP is the main mail transport mechanism throughout the Internet.
   SMTP is widely deployed and well understood by many engineers who
   specialize in Internet email.  Because of these reasons, works based
   on SMTP or derived from it have a higher likelyhood of being widely
   deployed throughout the Internet.

   However, SMTP is highly inefficient for transfer of short messages.
   SMTP's inefficiency applies to both the number of transmissions and
   also to the number of bytes transmitted.

   Even when fully optimized with PIPELINING, SMTP is still quite
   inefficient.

   Submission of a short message with SMTP involves 15 transmissions.
   Submission of a short message with SMTP and PIPELINING involves 9
   transmissions.  Submission of a short message with EMSD (EMSD-P and
   ESRO) involves 3 transmissions (in typical cases).

   The key requirement driving the design of EMSD is efficiency.  It was
   determined that the at least 3 fold gains in efficiency justifies the
   deviation from the SMTP model.

C.1.1  Comparison of SMTP and EMSD Efficiency

   The table below illustrates the number of N-PDUs exchanged for
   transfer of a short Internet email when using SMTP, SMTP and
   PIPELINING, QMTP and EMSD. The names used for identifying the PDUs
   are informal names.

           SMTP      SMTP + pipelining   QMTP, QMQP,   EMSD
           -------   -----------------   ------------  -----------
   client: SYN       SYN                 SYN           Submit.Req
   server: SYN ok    SYN ok              SYN           Submit.Resp
   client: HELO      EHLO                message       ack
   server: ok        PIPELINING          accept close
   client: MAIL      MAIL RCPT DATA      close
   server: ok        ok
   client: RCPT      message QUIT
   server: ok        accept ok close
   client: DATA      close
   server: ok

Top      Up      ToC       Page 79 
   client: message
   server: accept
   client: QUIT
   server: ok close
   client: close

C.2  Use of ESRO Instead of TCP

   In order to provide the same level of reliability that the existing
   email protocols provide for short messages, it is clear that a
   reliable underlying service is needed.  UDP [6], by itself, is
   clearly not adequate.

   Use of TCP however, involves three phases:

      1. Connection Establishment

      2. Data Transfer

      3. Disconnect

   Reliable transfer of a short message using TCP at a minimum involves
   5 transmissions as it is the case with QMTP.

   The key requirement driving the design of EMSD is Efficiency.  It was
   determined that elimination of the extra 2 transmissions that are an
   inherent characteristic of TCP, justifies deviation from it.

   ESRO protocol, as specified in (RFC-2188 [1]), provides reliable
   connectionless remote operation services on top of UDP [6] with
   minimum overhead.  ESRO protocol supports segmentation and
   reassembly, concatenation and separation.

   Reliable transfer of a short message using ESRO involves 3
   transmissions as it is the case with EMSD-P.

C.3  Use Of Remote Procedure Call (RPC) Model

   Many Internet protocols are "text-based".  Few Internet protocols are
   RPC based.  Protocols designed around the "text-based" approach have
   a better track record of acceptance throughout the Internet.

   Considering that message submission and delivery in EMSD involve no
   more than two data exchanges, the text-based model becomes the same
   as an operation.  Furthermore, the RPC model is the natural way of
   using ESRO.

Top      Up      ToC       Page 80 
C.4  Use Of ASN.1

   In order to minimize the number of bytes transferred, efficient
   encoding mechanisms are needed.

   Amongst today's encoding mechanisms, ASN.1 has the unique feature of
   separating the abstract syntax from the encoding rules.  By selecting
   ASN.1 as the notation used for expressing EMSD's information objects,
   EMSD has the flexibility of using the most efficient encoding rules
   such as Packed Encoding Rules (PER) when they are available.

   Efficient encoding can always be better performed when the syntax of
   the information is known.  In general, encoding and compression
   techniques which use the knowledge of the syntax of the information
   produce better results than those compression techniques that work on
   arbitrary text.

Top      Up      ToC       Page 81 
D  FURTHER DEVELOPMENT

   Beyond this documentation of existing implementations, further
   development of EMSD protocol is anticipated.

   The following deficiencies and areas of improvement are identified.

      o Mapping of RFC-822 to EMSD-FS needs to be more explicit.

      o Mapping of EMSD-FS to RFC-822 needs to be more explicit.

      o Text of duplicate detection section needs more structure.

      o SubmissionControl operation needs more informative description.

      o Based on implementor's feedback the "EMSD PROCEDURE FOR
        OPERATIONS" section needs to be adjusted or re-done.

      o The EMSD protocol can be extended to also support transfer of
        raw RFC-822 text-based messages in addition to EMSD-FS. This
        would be a trade-off in favor of "ease of implementation"
        against "efficiency of bytes transfered".

      o Provide mechanisms to support fully automated initial
        provisioning of mail-boxes.

   Future development of the EMSD Protocol is anticipated to take place
   at http://www.emsd.org/.  Those interested in further development and
   maintenance of this protocol are invited to join the various mailing
   lists hosted at http://www.emsd.org/.

Top      Up      ToC       Page 82 
E. References

   [1] Banan, M., Cheng, J. and M. Taylor, "At&t/neda's efficient short
       remote operations (ESRO) protocol specification version 1.2.",
       RFC 2188, September 1997.

   [2] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.

   [3] Crocker, D., "Standard for the format of ARPA internet text
       messages", STD 11, RFC 822, August 1982.

   [4] Information Processing --- Open Systems Interconnection ---
       Specification of Packed Encoding Rules for Abstract Syntax
       Notation One (ASN.1). International Organization for
       Standardization and International Electrotechnical Committee.
       International Standard 8825-2.

   [5] Information Processing --- Open Systems Interconnection ---
       Specification of Basic Encoding Rules for Abstract Syntax
       Notation One (ASN.1). International Organization for
       Standardization and International Electrotechnical Committee,
       1987. International Standard 8825.

   [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
       1980.

Top      Up      ToC       Page 83 
F. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.