tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2524

 
 
 

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

Part 3 of 4, p. 40 to 62
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 40 
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.

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
      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.

Top      Up      ToC       Page 43 
   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

Top      Up      ToC       Page 44 
      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.

Top      Up      ToC       Page 45 
    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.

Top      Up      ToC       Page 46 
    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.

Top      Up      ToC       Page 47 
    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.

Top      Up      ToC       Page 48 
    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.

Top      Up      ToC       Page 49 
    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

Top      Up      ToC       Page 50 
   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.

Top      Up      ToC       Page 51 
    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

Top      Up      ToC       Page 52 
        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

Top      Up      ToC       Page 53 
   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.

Top      Up      ToC       Page 54 
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,

Top      Up      ToC       Page 55 
     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,

Top      Up      ToC       Page 56 
     -- 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

Top      Up      ToC       Page 57 
                              [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

Top      Up      ToC       Page 58 
     -- 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.

Top      Up      ToC       Page 59 
   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.

Top      Up      ToC       Page 60 
   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.

Top      Up      ToC       Page 61 
   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.

Top      Up      ToC       Page 62 
     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 RFC Part