next up previous contents
Next: EMSD FORMAT STANDARDS Up: Internet DRAFT EMSD - Previous: DUPLICATE OPERATION DETECTION SUPPORT   Contents

Subsections

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.

MTS Behavior

The MTS is event-driven.

If it received an event from ESROS, then it could be any of the following types:

For an ESROS event responsibility is passed to the MTS performer (Section 5.1.1).

If the MTS received an event:

then responsibility is passed to the MTS invoker (Section 5.1.5).


MTS Performer

The MTS performer is responsible for processing the following operations, received from ESROS:

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.

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.

Delivery-control

This operation can be processed immediately. After it is processed, the appropriate result is returned.

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.


MTS Invoker

The MTS invoker is responsible for processing the following operations, received from ESROS:

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.


UA Behavior

The User Agent is event-driven.

If it received an event from ESROS, then it could be any of the following types:

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).


UA Performer

The performer on the UA side is responsible for processing the following operations:

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.

UA Invoker

The invoker on the UA side is responsible for processing the following operations:

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.

next up previous contents
Next: EMSD FORMAT STANDARDS Up: Internet DRAFT EMSD - Previous: DUPLICATE OPERATION DETECTION SUPPORT   Contents