RFC 2524
Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3
Pages: 83
Informational
Informational
Part 3 of 4 – Pages 40 to 62
4 DUPLICATE OPERATION DETECTION SUPPORT
4.1 Duplicate Operation Detection Support Overview
Some operations are idempotent in nature, i.e. they can be performed more than once without any harm. However, some other operations are non-idempotent in nature, i.e. they should be performed only once. In the case of non-idempotent operations, performer should be able to detect duplicate operations and perform each non-idempotent operation only once. Examples of non-idempotent operations are Submission and Delivery of messages which shouldn't be performed more than once. Examples of idempotent operations are Submission-control and Delivery-control which can be performed more than once with no harm. ESRO Services don't detect duplicate invocation of operations. As a result, the Duplicate Operation Detection Support Functional Unit is used to detect duplication when the same operation instance is invoked more than once. Invoker assigns an Operation Instance Identifier to an operation and this Operation Instance Identifier is used at the peer performer entity to detect the duplicate invocation of the same operation. Using this support, non-idempotent operations can be repeated over and over with no harm because the duplicate invocations are detected by this functional unit. This support helps the performer not to perform an operation more than once. Support for duplication detection is realized through allocating Operation Instance Id (see Section 4.1.2, "Operation Instance Identifier") to an operation by invoker. When an operation is invoked using duplication detection support, performer logs the Operation Instance Identifier and checks the next operations against duplication. Operation value identifies whether performer should detect duplicate operations (see Section 4.1.1, "Operation Value") and Operation Instance Id is assigned by invoker and sent as the first byte of operation's parameter.4.1.1 Operation Value
Operation Values are divided into two groups. Operation values from 0 to 31 do not have Duplicate Operation Detection Support (0 to 31) and operation values from 32 to 63 have Duplicate Operation Detection Support.
Duplicate Operation Detection Functional Unit checks for duplication only if Operation Value is in the range of 32 to 63. When invoker user uses an Operation Value in the range of 32 to 63 which means operation with support for duplication detection, the user should specify an Operation Instance ID for the operation (see next section).4.1.2 Operation Instance Identifier
To support duplication detection, an Operation Instance Identifier is assigned by invoker user and sent as the first byte of the operation's parameter. This identifier is used on performer side to detect duplicate invocation of the same operation. Characteristics of Operation Instance Identifier is as follows: o Operation Instance Identifier is one byte and can have values from 0 to 255. o Operation Instance Identifier is sent as the first byte of the operations parameter (without encoding). o The length of Operation Instance Identifier is 8-bit, but depending on the performer capabilities, it might keep 0 to 127 Operation Instance Identifiers for duplication detection. The performer profile defines the number of outstanding Operation Instance Identifiers that are checked against duplication. When a performer profile indicates support for 0 outstanding Operation Instance Identifier, it means it does not have support for Duplicate Operation Detection. In this case, there should be only one outstanding operation at any point of time. o Instance ID check is not part of ESROS, per se. Use of Duplicate Detection is determined by EMSD-P. Operation Instance ID for operations 32-63 is the first byte of the argument. Duplicate Detection suuport strips that byte. o The Instance ID is not subject to Basic Encoding Rules (BER). o The invoker user assigns the Operation Instance Identifier to the operation at the time of requesting the invoke service. The Operation Value should be in the range of operation values with duplication detection support, i.e. 32 to 63. o It's the responsibility of the user to choose Operation Instance Identifier in a way that uniqely and unambiguously identifies the operation.
o From the invoker's perspective, assumption is that two
operations with the same operation Instance Identifier are
totally identical which means they produce exact same results.
o Operation Instance Identifier uniqely specifies a non-idempotent
operation and multiple invocations of such an operation will
eventually result in the same outcome because the duplicate
instances are identified and the operation is not performed more
than once.
o From the performer's perspective, assumption is that two
operations with the same Operation Instance Identifier should be
executed once and once only.
o If requested, the degree of duplication checked by Duplicate
Operation Detection Support Functional Unit on the performer's
side (i.e. the total number of outstanding Operation Instance
Identifier kept) can be communicated with the invoker to
synchronize the invocations.
o User of Duplicate Operation Detection Support is responsible to
behave based on the performer profile and its limitations in
this regard. This behavior is defined based on the desired
semantic of the operation which is to be implemented.
o On the performer side, when an Operation Instance Identifier is
received, a previous Operation Instance Identifier whose
distance to this latest one is greater than or equal to half of
the wrap-around range of the Operation Instance Identifier
number is expired, i.e. for an 8-bit Operation Instance
Identifier, the distance of 128 causes an old Operation Instance
Identifier to expire.
o It's the responsibility of the invoker user to use consecutive
Operation Instance Identifier numbers, or when it skips some
Operation Instance Identifiers, it should remember that if there
is an smaller Operation Instance Identifier on performer side
with the distance explained above, it will be expired.
5 EMSD PROCEDURE FOR OPERATIONS
The following sections shows the general procedures to be used in the
implementation of the EMSD Message Transfer Server (MTS) and the EMSD
User Agent (UA), with the option for 3-Way or 2-Way handshakes on
operations which support them. These procedures do not constitute
complete behavior specifications for implementations. The following
sections contain information helpful to implementors.
The MTS and the UA are event-driven. Each waits for any of the possible event types, and, upon receiving an event, processes it. After processing the event, the next event is waited upon.5.1 MTS Behavior
The MTS is event-driven. If it received an event from ESROS, then it could be any of the following types: o Message submit indication; o Message submit confirm and failure indication; o Result and Error indication for a deliver operation; o DeliveryVerify indication; o Result and Error indication for a submissionVerify operation; o Result and Error indication for a submissionControl operation; o DeliveryControl indication. For an ESROS event responsibility is passed to the MTS performer (Section 5.1.1). If the MTS received an event: o for message delivery, from the RFC-822 mailer; o requesting submission controls upon the UA, or; o indicating an elapsed timer (meaning that it's time to re- attempt a message delivery) then responsibility is passed to the MTS invoker (Section 5.1.5).5.1.1 MTS Performer
The MTS performer is responsible for processing the following operations, received from ESROS: o Message-submission o Delivery-control
o Delivery-verify
The MTS performer should first make sure that it has received an
INVOKE.indication. Any other type of primitive shouldn't be
occurring at this point, and should be ignored.
If there's something wrong with the PDU or operation data, the MTS
performer should send back an error to the proper invoker:
1. Send an ESROS Error Request, then go wait for a response (either
a confirmation or a failure indication). The response is sent
back on the same SAP type on which the event occurred.
2. Keep track of the type of request that was issued.
If there isn't anything wrong with the PDU or operation data, then
the MTS performer has received a valid event from ESROS. This could
be any of the defined Submission and Delivery Protocol operations.
5.1.2 Message-submission
1. The Message-submission operation first checks to see which SAP
this Submit Request came in on.
2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way
SAP (see #7).
3. If the event arrived on the 2-Way SAP, consider this a protocol
violation and ignore it.
4. Wait for a response to the request. The response could be either
an ERROR.confirm (see #5) or a FAILURE.indication (see #6).
5. The ERROR.request has been confirmed. The UA knows that the
submitted message wasn't sent. Since there was an error, there
is nothing more to do, so return.
6. If the result to the ErrorRequest is a Failure.indication, it
can be assumed that either the UA has received nothing (the
ERROR.request PDU was lost), which means failure for the UA; or
that the 3-Way acknowledgment was lost, which means that the UA
has in fact received the ERROR.request PDU and knows about the
delivery failure. Either way, the message can be ignored. There
is nothing more to do, so return.
7. If the event was received on the 3-Way SAP, then this is the
correct SAP on which to receive a Submit Request. Send back a
Result Request and keep track of the primitive which was issued.
8. Now wait for a response to our request. The response will be
either a Result.confirm (see #9) or a Failure.indication (see
#13).
9. The RESULT.request has been confirmed.
10. Submit the message to the RFC-822 mailer.
11. Attempt, a number of times, to send the submitted message via
the RFC-822 mailer. If the send was successful, then return.
12. If, after the maximum number of retries, the message was not
able to be sent, consider it a failure. Since the UA assumption
has been that submission was successful, but now it has not been
sent, a brand new message, a Non-Delivery message, must be
generated and delivered to the UA. When this is completed, then
return.
13. A FAILURE.indication has occurred due to the previously issued
RESULT.request.
14. A Submission Verification is issued to the UA to see if the
RESULT.request was received. There are three possible results
from sending the submission verification to the UA: Fail (see
#15), Send Message (see #16) or Drop Message (see #20).
15. Fail -- The Submission-verify request didn't reach the UA, or
the Submission Verify response didn't get back. Ignore the
message and return.
16. The Submission Verify operation succeeded, meaning that the UA
received the request, and responded with a message stating that
it wants the message to be sent.
17. Attempt, a number of times, to send the submitted message via
the RFC-822 mailer.
18. If the message was submitted to the RFC-822 mailer successfully,
then return. If, after the maximum number of retries, the
message was not able to send the message, consider it a failure.
19. The UA already assumes that the Message-submission was
successful. Now since the submitted message has not been sent,
a brand new message, a Non-Delivery message, must be generated
and delivered to the UA. After this is accomplished, then
return.
20. The UA responded with a message stating that the message should
be dropped. This may occur if the UA never received the result
from the MTS, meaning that it never received the Message Id, and
had to therefore inform the user that the message couldn't be
submitted. This may also occur if the UA doesn't have the
record of the message being verified. It can be because the
message record has been aged and expired, or because the EMSD-UA
has not been able to keep the record of the received message
because of storage or memory limitations. There is nothing to
do, so return.
5.1.3 Delivery-control
This operation can be processed immediately. After it is processed,
the appropriate result is returned.
5.1.4 Delivery-verify
This operation occurs when the UA doesn't think that the MTS has
received the RESULT.indication from a previously delivered message.
The UA wants to make sure that the MTS knows it has been delivered.
The MTS will determine what it knows of the specified message, and
send back a result. This can be processed immediately, as it doesn't
need to deal with duplicate detection.
5.1.5 MTS Invoker
The MTS invoker is responsible for processing the following
operations, received from ESROS:
o Message-delivery
o Submission-control
o Submission-verify
Submission-control
Process the Submission Control request.
Message-delivery
1. Check the User Agent's profile to determine the SAP.
2. Set the SAP to 3-Way.
3. Issue the INVOKE.request on the appropriate SAP, with duplication
detection enabled. Since a local error is possible on issuing
the INVOKE.request, a retry counter is needed.
4. There are three possible events possible in result to the
INVOKE.request: an ERROR.indication (see #5), a
RESULT.indication (see #9) or a FAILURE.indication (see #10).
5. An ERROR.indication was received, which means that the UA can't
accept the message right now.
6. If the reason was one of a transient nature, wait for a while and
then send the Deliver Request again.
7. If the reason was one of a permanent nature, send back a non-
delivery report to the originator.
8. Since the error was one of a permanent nature, then the MTS must
send back a non-delivery report, then log the unsuccessful
delivery with error from UA and return.
9. A RESULT.Indication was returned, which means that the Delivery
was successful. Send a delivery report to the originator if one
was requested and log successful delivery and return.
If the UA profile indicated that Complete mode was to be used,
keep track of the fact that this message has been successfully
delivered (as far as the MTS is concerned), so that if the UA
sends us a Delivery Verify operation, we know that we consider
the message to be delivered.
10. A FAILURE.indication was returned, which means there was a
problem getting the Deliver Request to the UA, or in getting the
response back from the UA. In any case, a response was never
received, so the request timed out. Wait for a while, and then
send the Deliver Request again.
As long as a FAILURE.indication is returned and the number of
retries has not been exceeded, keep trying to verify the
delivery.
Submission-verify
The Submission-verify operation is always issued on the 2-Way SAP.
The response is awaited. If a response doesn't come, the request is
queued and attempted again later.
1. Issue the INVOKE.request on the 2-Way SAP, with duplication
detection disabled. Since a local error on issuing the invoke
request is possible, a retry counter is needed.
2. An INVOKE.Request has been issued and a response has been
received. The response will be either a a RESULT.indication (see
#3) or a FAILURE.indication (see #4). There are no defined
errors to a Submission Verify operation, so an ERROR.indication
should not be occurring here.
3. A RESULT.indication was received. Either ResponseSendMessage or
ResponseDropMessage, as specified in the PDU, will be returned.
4. A FAILURE.indication was received, which means that there was a
problem getting the Submission Verify Request to the UA, or in
getting the response back from the UA. In any case, the response
was never received, so the request timed out. Wait for a while,
and then another attempt to send the Submission Verify request is
needed.
Non-Delivery Report
Issue an INVOKE.request containing a Submit operation with a content
type of Non-Delivery Report, to the UA. This operation is always
issued on the 2-Way SAP. The response is awaited. If a response
doesn't come, the request is queued and attempted again later.
1. Create a Submit operation.
2. Issue the INVOKE.request on the 2-Way SAP, with duplication
detection enabled. Since a local error on issuing the invoke
request is possible, a retry counter for is needed.
3. A response to the INVOKE.Request has been received. The response
will be either a RESULT.indication (see #5), ERROR.indication
(see #4), or a FAILURE indication (see #7).
4. An ERROR.indication was received, which means that the UA doesn't
know what to do with our non-delivery report. That's the UAs
problem, so just do nothing and return.
5. A RESULT.indication was received, which means we delivered a
successful non-delivery report.
6. The result is logged. Nothing more is needed, so return.
7. A FAILURE.indication was received, which means there was a
problem getting the Submit Request to the UA, or in getting the
response back from the UA. In any case, the response was never,
so the request timed out. Wait for a while, and then send the
Submission Verify request again.
5.2 UA Behavior
The User Agent is event-driven.
If it received an event from ESROS, then it could be any of the
following types:
o Message deliver indication;
o Message deliver confirm and failure indication;
o Result and Error indication for a submit operation;
o Submission verify indication;
o Result and Error indication for a delivery verify operation;
o Result and Error indication for a delivery control operation;
o Submission control indication.
For an ESROS event responsibility is passed to the UA performer
(Section 5.2.1).
IF the UA received an event indicating that there's a message from
the user, for submission, then responsibility is passed to the UA
invoker (Section 5.2.2).
5.2.1 UA Performer
The performer on the UA side is responsible for processing the
following operations:
o Message Delivery
o Submission Verification
o Submission Control
Message-delivery
1. A Message-delivery request is received.
2. Check for the correctness of the PDU. If the PDU is bad the see
#3. If the PDU is good then see #8.
3. Send an ESROS ERROR.request. If the request arrived on a 3-Way
SAP, use a 3-Way SAP for the result. If the request arrived on a
2-Way SAP, use a 2-Way SAP for the result. Keep track of the
type of request that was issued.
4. Wait for the ESROS event. The result could be an ERROR.confirm
(see #5) or a FAILURE.indication (see #7).
5. The ESROS event was an ERROR.confirm
6. Log the message as the Non-Delivery was confirmed by the MTS and
return.
7. If the ESROS event was a FAILURE.indication, that means one of
two things has occurred:
A. The MTS has received nothing (the ERROR.request PDU was lost),
which means that the MTS doesn't know that the message
delivery has been rejected. In this case, the MTS will
eventually time out, and retransmit the message delivery
request.
B. The 3-Way acknowledgment was lost, which means that the MTS
has in fact received the ERROR.request PDU and knows about the
delivery failure.
Either way, the message can now be ignored.
8. Send an ESROS RESULT.request. If the request arrived on a 3-Way
SAP, use a 3-Way SAP for the result. If the request arrived on a
2-Way SAP, use a 2-Way SAP for the result. Keep track of the
type of request that was issued.
9. Wait for the ESROS event. The result could be an RESULT.confirm
(see #10) or a FAILURE.indication (see #13).
10. If the event is a RESULT.confirm, then the delivered message can
now be given to the user.
11. Deliver the message to the user.
12. Log the message as Message Delivery Known to MTS.
13. If the event is a FAILURE.indication, then, if the delivery was
on a 3-Way SAP, a Delivery Verification request to the MTS can
be issued to see if the MTS actually got the RSULT.request. If
the delivery was on a 2-Way SAP, then the message will delivered
to the user and if the MTS has not received the RESULT.request,
it will retransmit it later and the duplicate will be ignored.
14. Deliver the message to the user. Since a FAILRUE.indication was
received in response to a RESULT.requst, it means that possible,
the MTS didn't receive the RESULT.request. The MTS could now
time out, and send another copy of the same message. Save the
message for duplication detection.
15. Log the fact that the message was delivered, but that the MTS
might not be aware of it.
16. If the UA supports Delivery Verification, and the Delivery
Request was sent on the 3-Way SAP, then see #17. If either of
these conditions are not true, then return.
17. Send a Delivery-verify request to see if the MTS got the
RESULT.request.
There are three possible results from sending the delivery
verification to the MTS: Fail (see #18), ResponseNonDelivery
(see #20) or ResponseDelivery (see #23).
18. Fail -- Delivery Verify request didn't reach the MTS, or the
Delivery Verify response didn't get back to the UA.
19. Log this as delivering the message to the user, but the MTS
having possibly sent a Non-Delivery report to the originator
even though the UA did actually deliver the message to the user.
Then return.
20. ResponseNonDelivery -- Verify Response indicates that the MTS
now knows (because of the Delivery Verify operation that the
message has been delivered to the user, but had not received our
RESULT.request nor a Delivery Verify operation in a timely
manner, and had already sent out a Non-Delivery report to the
originator.
21. The MTS had not received, from the UA, in a timely manner, a
RESULT.indication indicating that the message had been delivered
to the user. The MTS has already sent a Non-Delivery report to
the originator. The UA must let the user know about this. Log
the message as delivered to the user, but a Non-Delivery sent to
the originator.
22. Since the UA received a response to the Verify operation, it
knows that the MTS knows about this message delivery, so the UA
also knows that it won't be receiving a duplicate of it. The UA
can now remove this message's Message Id from the list of
possible duplicates.
23. ResponseDelivery -- Verify Response received from MTS.
24. This means that the MTS knows (either because the MTS had
received the RESULT.request that was sent by the UA or because
the MTS has now received the UAs Delivery-verification message,
informing that the UA received the message for delivery to the
user. The MTS is (or was) able to send a Delivery report to the
originator if one was requested. Log it as such.
25. Since the UA received a response to the Verify operation, it
knows that the MTS knows about this message delivery, so the UA
also knows that it won't be receiving a duplicate of it. The UA
can now remove this message's Message Id from the list of
possible duplicates and return.
Submission-verify
Process the Submission-verify request and return.
Submission-control
This operation can be processed immediately. After it is processed,
the appropriate result is returned.
5.2.2 UA Invoker
The invoker on the UA side is responsible for processing the
following operations:
o Message-submission
o Delivery-control
o Delivery-verify
Message-submission
General procedures for UA's Message-submission mirror that of MTS's
Message-delivery.
Delivery-control
1. Issue the INVOKE.request on the 3-Way SAP, with duplication
detection enabled. Since the UA can get a local error on issuing
the invoke request, a retry counter is needed.
If we got a local failure in issuing the Invoke Request, wait a
while and then try again (up to the limit of the maximum number
of retries).
2. The UA has issued an INVOKE.Request. Wait for a response from
ESROS. The response will be either a RESULT.indication (see #5),
ERROR.indication (see #3), or FAILURE.indication (see #7).
3. A ERROR.indicaiton was received, meaning that the MTS told says
that it cannot accept the message.
4. Log the MTS rejection and return
5. A RESULT.indication was received, which means that the Submission
was successful.
6. Log successful submission and return.
7. a FAILURE.indication was received, meaning that there was a
problem getting the Submit Request to the MTS, or in getting the
response back from the MTS. In any case, the UA never received
the response, so the request timed out. Wait for a while, and
then send the Submit Request again.
8. The UA has exceeded the maximum number of retries. Let the user
know, log the failure and return.
Delivery-verify
General procedures for UA's Delivery-verify mirror that of MTS's
Submission-verify.
6 EMSD FORMAT STANDARDS
6.1 Format Standard Overview
EMSD Format Standard (EMSD-FS) is a non-textual form of compact encoding of Internet mail (RFC-822) messages which facilitates efficient transfer of messages. EMSD-FS is used in conjunction with the EMSD-P but is not a general replacement for RFC-822. EMSD-FS defines a method of representation of short interpersonal message. It defines the "Content" encoding (Header + Body). Although EMSD-FS contains end-to-end information its scope is purely point-to-point. The "Efficient InterPersonal Message Format Standard" is defined in this section. This standard is primarily intended for communication among people. The EMSD Format Standard is designed to be fully consistent with RFC-822 [3]. In many ways EMSD-FS can be considered to be an efficiency oriented encoder and decoder. Through use of EMSD-FS an RFC-822 message is converted to a more compact binary encoding. This more compact message is then transfered between an EMSD-SA and EMSD- UA. The compact message (represented in EMSD-FS) may then be converted back to RFC-822 intact. For messages that are originated (submitted) with EMSD protocol, certain fields (e.g., addresses, message-id) can have special forms that are specialized and produce more compact EMSD-FS encoding. These special forms are legitimate values of RFC-822 messages. This specification expresses information objects using ASN.1 [X.208]. Encoding of ASN.1 shall be based on Basic Encoding Rules (BER) [5]. Future revisions of this specification will use Packed Encoding Rules (PER) [4]. The convention of (O) "OPTIONAL", (D) "DEFAULT", (C) "CONDITIONAL" and (M) "MANDATORY" which express requirements for presence of information is used in this section.6.2 Interpersonal Messages
An interpersonal message (IPM) consists of a heading and a body. IPM ::= SEQUENCE { heading Heading,
body Body OPTIONAL
};
6.2.1 Heading fields
The fields that may appear in the Heading of an IPM are defined and
described below.
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
};
Some fields have components and thus are composite, rather than
indivisible. A field component is called a sub-field.
Sender
This field is mandatory if the sender is different from the
originator.
Originator
The Originator heading field (O) identifies the IPM's originator.
Recipient-data
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 }
};
recipient-address
The Primary Recipients heading field identifies the zero or more
users who are the "primary recipients" of the IPM. The primary
recipients might be those users who are expected to act upon the IPM.
per-recipient-flags
The Copy Recipients heading field identifies the zero or more users
who are the "copy recipients" of the IPM. The copy recipients might
be those users to whom the IPM is conveyed for information.
recipient-type-copy
This field is set if the recipient is on the Carbon Copy (CC) list.
recipient-type-blind-copy
This field is set if the recipient is on the Blind Carbon Copy (BCC)
list.
The Blind Copy Recipients heading field (C) identifies zero or more
users who are the intended blind copy recipients of the IPM.
The phrase "copy recipients" above has the same meaning as in "Copy
Recipients" from Section 6.2.1 . A blind copy recipient is one whose
role as such is disclosed to neither primary nor copy recipients.
In the instance of an IPM intended for a blind copy recipient, this conditional field shall be present and identify that user. Whether it shall also identify the other blind copy recipients is a local matter. In the instance of the IPM intended for a primary or copy recipient, the field shall be absent. notification-request-rn A receipt notification (rn) reports its originator's receipt, or his expected and arranged future receipt, of an IPM. notification-request-nrn A non-receipt notification (nrn) reports its originator's failure to receive, to accept, or his delay in receiving, an IPM. notification-request-ipm-return When this field is set, the contents of the message are returned along with the notification. report-request-non-delivery The report request enables the MTS to acknowledge to the MTS-user one or more outcomes of a previous invocation of the message-submission or probe-submission abstract-operations. A report is returned only in case of non-delivery. report-request-delivery For the message-submission, report-delivery indicates the delivery or non-delivery of the submitted message to one or more recipients. For the probe-submission, the report-delivery indicates whether or not a message could be delivered if the message were to be submitted. reply-requested When set this field indicates that the originator requests that a recipient send a message in reply to the message which carries the request.
per-message-Flags Priority The Priority field (default is normal) identifies the priority that the authorizing users attach to the IPM. It may assume any one of the following values: urgent, normal, or non-urgent. At most one of either "non-urgent" or "urgent" may be specified concurrently. If neither is specified, then a Priority level of "normal" is assumed. Importance The Importance heading field (default normal) identifies the importance that the authorizing users attach to the IPM. It may assume any one of the following values: low, normal, or high. 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
(next page on part 4)