rfc2524.txt

RFC 的详细文档！

        invoke the submit ES-OPERATIONS if it were not for the
        prevailing controls.

   In the absence of this result, it may be assumed that the EMSD-UA is
   not holding any messages for submission due to the prevailing
   controls.


   Errors

   See Section 3.4.3.


3.3.3  submissionVerify

   The submissionVerify ES-OPERATIONS enables the EMSD-SA to verify if
   the EMSD-UA has received the result of its submission.

   submissionVerify  ES-OPERATION

       ARGUMENT SubmissionVerifyArgument
       RESULT SubmissionVerifyResult
       ERRORS
       {
           submissionVerifyError,
           resourceError,
           protocolViolation
       } ::= 6;

   The duplicate operation detection is not required for this operation.


   Arguments

   This operation's arguments are:


   SubmissionVerifyArgument ::= SEQUENCE



Banan                        Informational                     [Page 28]

RFC 2524                          EMSD                     February 1999


     -- Identifier of this message. This is the same identifier that
     -- was provided to the originator in the Submission Result.
     -- See comment regarding assignment of message identifiers,
     -- at the definition of EMSDMessageId.
     {
        message-id                                  EMSDMessageId
     };


   Message-id

   This argument contains an EMSD-SA-identifier that distinguishes the
   message from all other messages.  It shall be generated by the EMSD-
   SA, and shall have the same value as the message-submission-
   identifier supplied to the originator of the message when the message
   was submitted.


   Results

   SubmissionVerifyResult ::= SEQUENCE
   {
           status  SubmissionStatus
   };

   SubmissionStatus::= ENUMERATED
   {
           send-message            (1),
           drop-message            (2)
   };


   Send-message

   This result indicates that EMSD-SA is supposed to send the message
   out.


   Drop-message

   This result indicates that EMSD-SA is supposed to drop the message.


   Errors

   See Section 3.4.3.





Banan                        Informational                     [Page 29]

RFC 2524                          EMSD                     February 1999


3.4  EMSD Common Information Objects

3.4.1  SecurityElements

   SecurityElement ::= SEQUENCE

   {
     credentials                          Credentials,
     contentIntegrityCheck                ContentIntegrityCheck OPTIONAL
   };

   Credentials ::= CHOICE
   {
     simple                          [0]     IMPLICIT SimpleCredentials

     -- Strong Credentials are for future study
     -- strong                       [1]     IMPLICIT StrongCredentials
     -- externalProcedure            [2]     EXTERNAL
   };

   SimpleCredentials ::= SEQUENCE
   {
     eMSDAddress                     EMSDAddress OPTIONAL,
     password                [0]     IMPLICIT OCTET STRING
                             SIZE (0..ub-password-length)) OPTIONAL
   };

   -- StrongCredentials ::= NULL
   -- for now.
   -- ContentIntegrityCheck is a 16-bit checksum of content
   ContentIntegrityCheck ::= INTEGER (0..65535);

3.4.2  Message Segmentation and Reassembly

   Small messages can benefit from the efficiencies of connectionless
   feature of ESROS (See Efficient Short Remote Operations, RFC-2188
   [1]).

   Very large messages are transferred using protocols (e.g., SMTP) that
   rely on Connection Oriented Transport Service (e.g., TCP).

   When a message is too large to fit in a single connectionless PDU but
   is not large enough to justify the overhead of connection
   establishment, it may be more efficient for the message to be
   segmented and reassembled while the connectionless service of ESROS
   is used.  If the underlying Remote Operation Service is capable of
   efficient segmentation/reassembly over connectionless (CL) services,




Banan                        Informational                     [Page 30]

RFC 2524                          EMSD                     February 1999


   then use of the segmenting/reassembly mechanism introduced in this
   section is not necessary.  This feature is accommodated in this layer
   by:

   SegmentInfo ::= CHOICE

   {
     first           [APPLICATION 2]         IMPLICIT FirstSegment,
     other           [APPLICATION 3]         IMPLICIT OtherSegment
   };

   FirstSegment ::= SEQUENCE
   {
     sequence-id                             INTEGER,
     number-of-segments                      INTEGER
     -- number-of-segments must not exceed ub-total-number-of-segments
   };

   OtherSegment ::= SEQUENCE
   {
     sequence-id                             INTEGER,
     segment-number                          INTEGER
   };

   Segmentation and reassembly only applies to Message-submission and
   Message-delivery.

   The sender of the message is responsible for segmenting the message
   content into segments that fit in CL PDUs.  The segmented content is
   sent in a sequence of message-segments each carrying a segment of the
   content.  sequence-Id is a unique identifier that is present in all
   message-segments.  In addition to sequence identifier, the first
   message-segment specifies the total number of segments (number-of-
   segments).  Other message-segments have a segment sequence number
   (segment-number).  The receiver is responsible for sequencing (based
   on segment-number) and reassembling the entire message.


   Segmenting over the Connectionless ESRO Service

   The sender of the message maps the original message into an ordered
   sequence of message-segments.  This sequence shall not be interrupted
   by other messages over the same ESROS association.

   All message-segments in the sequence shall be assigned a sequence
   identifier by sender.  The sequence identifier shall be incremented
   by one by the sender after transmission of a complete message
   sequence.



Banan                        Informational                     [Page 31]

RFC 2524                          EMSD                     February 1999


   The first message-segment specifies the total number of segments.
   All message-segments in the sequence except the first one shall be
   sequentially numbered, starting at 1 (first message-segment has
   implicit segment number of 0).

   Each message-segment is transmitted by issuing a Message-submission
   or Message-delivery ES-OPERATIONS. All segments of a segmented
   message are identified by the same sequence-id.  For a given message,
   the receiver should not impose any restriction on the order of
   arrival of message-segments.

   There is no requirement that any message-segment content be of
   maximum length allowed by ESROS for connectionless transmission;
   however, no more than ub-total-number-of-segments segments can be
   derived from a single message.

   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



Banan                        Informational                     [Page 32]

RFC 2524                          EMSD                     February 1999


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



Banan                        Informational                     [Page 33]

RFC 2524                          EMSD                     February 1999


   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.







Banan