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
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
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
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 };
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,
-- 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
-- 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
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.
-- 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);
-- -- 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 {
-- 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
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
{ -- 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))
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),
-- 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
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
client: message server: accept client: QUIT server: ok close client: closeC.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.
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.
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/.
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.
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.