At most one of either "low" or "high" may be specified concurrently.
If neither is specified, then a Importance level of "normal" is
assumed.
The values above are not defined by this specification; they are
given meaning by users.
auto-forwarded
The Auto-forwarded heading field (default is false) indicates whether
the IPM is the result of auto-forwarding. It is a Boolean value.
reply-to
User-specified recipient or recipients who are to receive replies to
this message.
replied-to IPM
The Replied-to IPM heading field (C) identifies the IPM to which the
present IPM is a reply. It comprises an IPM identifier.
This conditional field shall be present if, and only if, the IPM is a
reply.
Note - In the context of forwarding, care should be taken to
distinguish between the forwarding IPM and the forwarded IPM. This
field should identify whichever of these two IPMs to which the reply
responds.
subject
The Subject heading field (O) identifies the subject of the IPM. It
corresponds to the "Subject:" field of RFC-822.
extensions
The Extensions heading field [D no extensions (i.e. members)]
conveys information accommodated by no other heading field. It
comprises a Set of zero or more IPMS extensions, each conveying one
such information item.
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
6.2.2 Body part types
The types of body parts that may appear in the Body of an IPM are
structured using the MIME specification.
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)
7 ACKNOWLEDGMENTS
In the context of Limited Size Messaging (LSM) over CDPD and pACT
over Narrowband PCS, AT&T Wireless Services (AWS), funded work which
was relevant to the development of the EMSD protocols.
8 SECURITY CONSIDERATIONS
This protocol supports simple authentication of the originator's
address by the EMSD-SA and simple authentication of EMSD-SA by EMSD-
UA.
Mainstream Internet mail security mechanisms can be used in
conjunction with the EMSD protocol.
9 AUTHOR'S ADDRESS
Mohsen Banan
Neda Communications, Inc.
17005 SE 31st Place
Bellevue, WA 98008
EMail: mohsen@neda.com
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: 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.
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.",
RFC2188, September 1997.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC2119, March 1997.
[3] Crocker, D., "Standard for the format of ARPA internet text
messages", STD 11, RFC822, 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, RFC768, 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.