The receiver reassembles a sequence of message-segments into a single
message. A message shall not be further processed unless all
segments of the message are received. Failure to receive the message
shall be determined by the following events:
o Expiration of Reassembly Timer (see Section 3.4.3).
o Receipt of a message-segment with different sequence identifier.
In the event of the above mentioned failures, the receiver shall
discard a partially assembled sequence.
In Reassembly process, all arguments other than content are ignored
in all segments except the first one. The content parts of all
segments are concatenated to compose the original message content.
When sender receives FAILURE.indication (as opposed to a
resourceError) for a message-segment, the whole message shall be
retransmitted.
In the case of submission and delivery operations, the verify
function is used as described below:
Receiver ignores FAILURE.indications received for message-segments,
and just collects the message-segments to complete the message.
However, it keeps a failure status for a segmented message which says
if any segment of the message has received FAILURE.indication. When
receiver succeeds to assemble the whole segmented message, then if
the status of the message shows there has been a FAILURE.indication
for any of the message-segments, it verifies the message through
verify operation. It's not enough to invoke verify operation just
based on the last message-segment because the sender might send a
segment without waiting for the result of the previous segment. In
such cases, there might be any combination of success and failure for
message-segments on the sender side.
Receiver uses the error code ResourceError (see Section 3.4.3) to ask
for retransmission of a single segment and uses the error code
MessageError (see Section 3.4.3) to ask for retransmission of all
segments (the whole message).
Reassembly Timer
The Reassembly Timer is a local timer maintained by the receiver of
message-segments that assists in performing the reassembly function.
This timer determines how long a receiver waits for all segments of a
message-segment sequence to be received. The timer protects the
receiver from the loss of a series of segments and possible sequence
identifier wrap-around.
The Reassembly Timer shall be started on receipt of a message-segment
with different sequence identifier than that previously received.
The timer shall be stopped on receipt of all segments composing the
sequence.
The value of Reassembly Timer is defined based on the network
characteristics and the number of segments. This requires that the
transmission of all segments of a single message must be completed
within this time limit.
3.4.3 Common 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);
protocolVersionNotRecognized
The major and minor protocol versions presented do not match those
recognized as being valid.
submissionControlViolated
The Submission control violated error reports the violation by the
MTS-user of a control on submission services imposed by the MTS via
the Submission control service. The Submission control violated
abstract-error has no parameters.
messageIdentifierInvalid
The Message Identifier Invalid error reports that the Message
Identifier presented to the MTS is not considered valid.
securityError
The Security error reports that the requested operation could not be
provided by the MTS or MTS-user because it would violate the security
policy in force.
deliveryControlViolated
The Delivery control violated error reports the violation by the MTS
of a control on delivery operations imposed by the MTS-user via the
Delivery-control operation.
resourceError
The messaging agent cannot currently support this operation. In the
case of segmentation and reassembly, resourceError is by the receiver
used to request that the sender retransmit of a single segment.
protocolViolation
Indicates that one or more mandatory argument(s) were missing.
messageError
For a multi-segment message, this error indicates that the messaging
agent has not received the message completely and that the message
must be retransmitted.
SecurityProblem
To ensure the security-policy is not violated during delivery, the
message-security-label is checked against the security-context. If
delivery is barred by the security-policy then, subject to the
security policy, a report instruction for this is generated.
3.4.4 ContentType
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);
3.4.5 EMSDMessageId
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 EMSD-SA 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)
};
3.4.6 EMSDORAddress
EMSDORAddress ::= CHOICE
{
-- This is the local-format address
emsd-local-address-format EMSDAddress,
-- This is a globally-unique RFC-822 Address
rfc822DomainAddress AsciiPrintableString
};
In the global sense Originators and Recipients are represented by
EMSDORAddress. The rfc822Domain may be used to address any
recipient.
3.4.7 EMSDAddress
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
};
Originator and Recipients in the scope of EMSD network are identified
by a digit based addressing scheme. EMSDAddress can only be used
where the scope of addressing has clearly been limited to the EMSD
network.
3.4.8 DateTime
DateTime ::= INTEGER;
DateTime is a Julian date, expressed as the number of seconds since
00:00:00 UTC, January 1, 1970.
3.4.9 AsciiPrintableString
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"|"{"|
"|"|"}"|"~"|"\"|""""));
3.4.10 ProtocolVersionNumber
ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
{
version-major INTEGER,
+------------------+-------+----+---------+----+---------+-----+-----+
|Operation |Invoker|Sap |Performer|Sap |Duplicate|OpId |ESROS|
| | |Sel | |Sel |Detect | |Use |
|__________________|_______|____|_________|____|_________|_____|_____|
|submit |UA |4 |MTS |5 |Yes |33 |3-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|deliver |MTS |2 |UA |3 |Yes |35 |3-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|deliveryControl |UA |8 |MTS |9 |No |2 |2-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|submissionControl |MTS |6 |UA |7 |No |4 |2-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|submissionVerify |MTS |6 |UA |7 |No |6 |2-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|deliveryVerify |UA |8 |MTS |9 |No |5 |2-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|getConfiguration |UA |8 |MTS |9 |No |7 |2-Way|
|__________________|_______|____|_________|____|_________|_____|_____|
|setConfiguration |MTS |6 |UA |7 |No |8 |2-Way|
+------------------+-------+----+---------+----+---------+-----+-----+
Table 1: EMSD-P Operations Summary
version-minor [0] IMPLICIT INTEGER DEFAULT 0
}
3.5 Submission and Delivery Procedures
Table 1 provides a comprehensive summary of EMSD-P operations, the
SAP selectors used and the operation IDs used.
Submission
The semantics of a submission operation is Exactly Once. Exactly
Once means that every operation is carried out exactly one time, no
more and no less. This semantic can not be fully implemented
because, if after invoking the operation, an invoker has a Success
(e.g. result) indication and the performer has a FAILURE.indication,
and the network goes down, the result of the operation will be Zero
(and not Exactly Once).
No more than one is controlled and guaranteed by the performer by
using the Duplicate Operation Detection Support Functions (see the
chapter entitled Duplicate Operation Detection Support).
Not zero but one is realized by performer by using the
SubmissionVerify operation. When the performer receives
FAILURE.indication, it's responsibility is to resolve the case by
using SubmissionVerify resulting in Not zero but one.
Submission procedure is as follows:
o Submit operation with 3-Way handshake and Duplicate Operation
Detection Support Function is invoked.
o If performer at EMSD-SA receives FAILURE.indication, it invokes
SubmissionVerify.
o Message is sent out by EMSD-SA only if result operation is
confirmed or the operation is verified (in the case of
FAILURE.indication).
The semantic of SubmissionVerify operation is At Least Once. This
type of semantics corresponds to the case that invoker keeps trying
over and over until it gets a proper reply. This operation can be
performed more than once without any harm.
Implications:
o MTS sends out the message if and only if it's sure that UA knows
about it.
Delivery
The semantics of Deliver operation is Exactly Once. Exactly Once
means that every operation is carried out exactly one time, no more
and no less. This semantic can not be fully implemented and if after
invoking the operation, invoker has Success indication and performer
has FAILURE.indication, and the network goes down, the result of the
operation will be Zero (and not Exactly Once).
No more than one is controlled and guaranteed by performer and by
using the Duplicate Operation Detection Support Functions.
Not zero but one is realized by performer by using the DeliveryVerify
operation. When performer receives FAILURE.indication, it's
responsible to resolve the case by using DeliveryVerify resulting in
Not zero but one.
Delivery procedure is as follows:
o Deliver operation with 3-Way handshake is invoked.
o If performer at User Agent (device) receives FAILURE.indication,
it invokes DeliveryVerify.
The semantic of DeliveryVerify operation is At Least Once. This type
of semantics corresponds to the case that invoker keeps trying over
and over until it gets a proper reply. This operation can be
performed more than once without any harm.
Implications:
o A non-delivery report is sent by MTS only if the message is not
delivered.
o The UA is responsible for notifying the MTS (through an explicit
deliveryVerify) to make sure that a delivery report is sent out.
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.