Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2524

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

Pages: 83
Informational
Part 4 of 4 – Pages 63 to 83
First   Prev   None

Top   ToC   RFC2524 - Page 63   prevText

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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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   ToC   RFC2524 - 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.