rfc3335.txt

RFC 的详细文档！

      Both the "signed-receipt-protocol" and the "signed-receipt-micalg"
      option parameters are REQUIRED when requesting a signed receipt.

   2) The "importance" attribute of "Optional" is defined in the MDN RFC
      2298 and has the following meaning:

      Parameters with an importance of "Optional" permit a UA that does
      not understand the particular options parameter to still generate
      a MDN in response to a request for a MDN.  A UA that does not
      understand the "signed-receipt-protocol" parameter, or the
      "signed-receipt-micalg" will obviously not return a signed
      receipt.

      The importance of "Optional" is used for the signed receipt
      parameters because it is RECOMMENDED that an MDN be returned to
      the requesting trading partner even if the recipient could not
      sign it.

      The returned MDN will contain information on the disposition of
      the message as well as why the MDN could not be signed.  See the
      Disposition field in section 5.3 for more information.






Harding, et. al.            Standards Track                    [Page 15]

RFC 3335                 MIME-based Secure EDI            September 2002


      Within an EDI trading relationship, if a signed receipt is
      expected and is not returned, then the validity of the transaction
      is up to the trading partners to resolve.  In general, if a signed
      receipt is required in the trading relationship and is not
      received, the transaction will likely not be considered valid.

5.2.1 Additional Signed Receipt Considerations

   The "rules" stated in Section 2.2.3 for signed receipts are as
   follows:

   1) When a receipt is requested, explicitly specifying that the
      receipt be signed, then the receipt MUST be returned with a
      signature.

   2) When a receipt is requested, explicitly specifying that the
      receipt be signed, but the recipient cannot support either the
      requested protocol format, or requested MIC algorithms, then
      either a signed or unsigned receipt SHOULD be returned.

   3) When a signature is not explicitly requested, or if the signed
      receipt request parameter is not recognized by the UA, then no
      receipt, an unsigned receipt, or a signed receipt MAY be returned
      by the recipient.

   NOTE: For Internet EDI, it is RECOMMENDED that when a signature is
   not explicitly requested, or if parameters are not recognized, that
   the UA send back at a minimum, an unsigned receipt.  If a signed
   receipt however was always returned as a policy, whether requested or
   not, then any false unsigned receipts can be repudiated.

   When a request for a signed receipt is made, but there is an error in
   processing the contents of the message, a signed receipt MUST still
   be returned.  The request for a signed receipt SHALL still be
   honored, though the transaction itself may not be valid.  The reason
   for why the contents could not be processed MUST be set in the
   "disposition-field".

   When a request for a signed receipt is made, the
   "Received-content-MIC" MUST always be returned to the requester.
   The"Received-content-MIC" MUST be calculated as follows:

   - For any signed messages, the MIC to be returned is calculated on
     the RFC1767 MIME header and content.  Canonicalization as specified
     in RFC 1848 MUST be performed before the MIC is calculated, since
     the sender requesting the signed receipt was also REQUIRED to
     canonicalize.




Harding, et. al.            Standards Track                    [Page 16]

RFC 3335                 MIME-based Secure EDI            September 2002


   - For encrypted, unsigned messages, the MIC to be returned is
     calculated on the decrypted RFC 1767 MIME header and content.  The
     content after decryption MUST be canonicalized before the MIC is
     calculated.

   - For unsigned, unencrypted messages, the MIC MUST be calculated over
     the message contents prior to Content-Transfer-Encoding and without
     the MIME or any other RFC 822 headers, since these are sometimes
     altered or reordered by MTAs.

5.3 Message Disposition Notification Format

   The format of a message disposition notification is specified in RFC
   2298.  For use in Internet EDI, the following format will be used:

   - content-type - per RFC 1892 and the RFC 2298 specification

   - reporting-ua-field - per RFC 2298 specification

   - MDN-gateway-field - per RFC 2298 specification

   - original-recipient-field - per RFC 2298 specification

   - final-recipient-field - per RFC 2298 specification

   - original-message-id-field - per RFC 2298 specification

   - disposition-field  - the following "disposition-mode" values SHOULD
                          be used for Internet EDI:

     "automatic-action" - The disposition described by the disposition
                          type was a result of an automatic action,
                          rather than an explicit instruction by the
                          user for this message.

     "manual-action"    - The disposition described by the disposition
                          type was a result of an explicit instruction
                          by the user rather than some sort of
                          automatically performed action.

     "MDN-sent-automatically" - The MDN was sent because the UA had
                                previously been configured to do so.

     "MDN-sent-manually" - The user explicitly gave permission for this
                           particular MDN to be sent.
                           "MDN-sent-manually" is meaningful with
                           "manual-action", but not with
                           "automatic-action".



Harding, et. al.            Standards Track                    [Page 17]

RFC 3335                 MIME-based Secure EDI            September 2002


   - disposition-field - the following "disposition-type" values SHOULD
                         be used for Internet EDI:

     "processed" - The message has been processed in some manner (e.g.,
                   printed, faxed, forwarded, gatewayed) without being
                   displayed to the user.  The user may or may not see
                   the message later.

     "failed" -  A failure occurred that prevented the proper generation
                 of an MDN.  More information about the cause of the
                 failure may be contained in a Failure field.  The
                 "failed" disposition type is not to be used for the
                 situation in which there is some problem in processing
                 the message other than interpreting the request for an
                 MDN.  The "processed" or other disposition type with
                 appropriate disposition modifiers is to be used in such
                 situations.

   - disposition-field - the following "disposition-modifier" values
                         SHOULD be used for Internet EDI:

     "error" -  An error of some sort occurred that prevented successful
                processing of the message.  Further information is
                contained in an Error field.

     "warning" - The message was successfully processed but some sort of
                 exceptional condition occurred.  Further Information is
                 contained in a Warning field.

5.3.1 Message Disposition Notification Extensions

   The following "extension field" will be added in order to support
   signed receipts for RFC 1767 MIME content type and multipart MIME
   content types that include the RFC 1767 MIME content type.  The
   extension field" defined below follows the "disposition-field" in the
   MDN.

   The "Received-content-MIC" extension field is set when the integrity
   of the received message is verified.  The MIC is the base64 encoded
   quantity computed over the received message with a hash function.
   For details of "what" the "Received-content-MIC" should be calculated
   over, see Section 5.2.1.  The algorithm used to calculate the
   "Received-content-MIC" value MUST be the same as the "micalg" value
   used by the sender in the multipart/signed message.  When no
   signature is received, or the mic-alg parameter is not supported then
   it is RECOMMENDED that the SHA1 algorithm be used to calculate the
   MIC on the received message or message contents.




Harding, et. al.            Standards Track                    [Page 18]

RFC 3335                 MIME-based Secure EDI            September 2002


   This field is set only when the contents of the message are processed
   successfully.  This field is used in conjunction with the recipient's
   signature on the MDN in order for the sender to verify "non-
   repudiation of receipt".

   - extension field = "Received-content-MIC"  ":"  MIC

     where:

     <MIC> = <base64MicValue> "," <micalg>

     <base64MicValue> = the result of one way hash function, base64
                        encoded.

     < micalg> = the micalg value defined in RFC1847, an IANA
                 registered MIC algorithm ID token.

5.3.2 Disposition Mode, Type, and Modifier Use

   Guidelines for use of the "disposition-mode", "disposition-type", and
   "disposition-modifier" fields within Internet EDI are discussed in
   this section.  The "disposition-mode", "disposition-type', and
   "disposition-modifier' fields are described in detail in RFC 2298.
   The "disposition-mode', "disposition-type" and "disposition-modifier"
   values SHOULD be used as follows:

5.3.2.1 Successful Processing

   When the request for a receipt or signed receipt, and the received
   message contents are successfully processed by the receiving EDI UA,
   a receipt or MDN SHOULD be returned with the "disposition-type" set
   to there is no explicit way for a user to control the sending of the
   MDN, then the first part of the "disposition-mode" should be set to
   "automatic-action".  When the MDN is being sent under user
   configurable control, then the first part of the "disposition-mode"
   should be set to "manual-action".  Since a request for a signed
   receipt should always be honored, the user MUST not be allowed to
   configure the UA to not send a signed receipt when the sender
   requests one.

   The second part of the "disposition-mode" is set to "MDN-sent-
   manually" if the user gave explicit permission for the MDN to be
   sent.  Again, the user MUST not be allowed to explicitly refuse to
   send a signed receipt when the sender requests one.  The second part
   of the "disposition-mode" is set to "MDN-sent-automatically" whenever
   the EDI UA sends the MDN automatically, regardless of whether the
   sending was under a user's, administrator's, or under software
   control.



Harding, et. al.            Standards Track                    [Page 19]

RFC 3335                 MIME-based Secure EDI            September 2002


   Since EDI content is generally handled automatically by the EDI UA, a
   request for a receipt or signed receipt will generally return the
   following in the "disposition-field":

     Disposition: automatic-action/MDN-sent-automatically; processed

   Note this specification does not restrict the use of the
   "disposition-mode" to just automatic actions.  Manual actions are
   valid as long as it is kept in mind that a request for a signed
   receipt MUST be honored.

5.3.2.2 Unprocessed Content

   The request for a signed receipt requires the use of two
   "disposition-notification-options", which specify the protocol format
   of the returned signed receipt, and the MIC algorithm used to
   calculate the mic over the message contents.  The "disposition-field"
   values that should be used in the case where the message content is
   being rejected or ignored, for instance if the EDI UA determines that
   a signed receipt cannot be returned because it does not support the
   requested protocol format, so the EDI UA chooses not to process the
   message contents itself, should be specified in the MDN
   "disposition-field" as follows:

   Disposition: "disposition-mode";
     failed/Failure: unsupported format

   The syntax of the "failed" "disposition-type" is general, allowing
   the sending of any textual information along with the "failed"
   "disposition-type".  For use in Internet EDI, the following "failed"
   values are defined:

   "Failure: unsupported format" "Failure: unsupported MIC-algorithms"

5.3.2.3 Content Processing Errors

   When errors occur processing the received message content, the
   "disposition-field" should be set to the "processed" "disposition-
   type" value and the "error" "disposition-modifier" value.  For use in
   Internet EDI, the following "error" "disposition-modifier" values are
   defined:

   "Error: decryption-failed" - the receiver could not decrypt the
                                message contents.

   "Error: authentication-failed" - the receiver could not authenticate
                                    the sender.




Harding, et. al.            Standards Track                    [Page 20]

RFC 3335                 MIME-based Secure EDI            September 2002


   "Error: integrity-check-failed" - the receiver could not verify
                                     content integrity.

   "Error: unexpected-processing-error" - a catch-all for any additional
                                          processing errors.

   An example of how the "disposition-field" would look when content
   processing errors are detected is as follows:

   Disposition: "disposition-mode";
     processed/Error: decryption-failed

5.3.2.4 Content Processing Warnings

   Situations arise in EDI where even if a trading partner cannot be
   authenticated correctly, the trading partners still agree to continue
   processing the EDI transactions.  Transaction reconciliation is done
   between the trading partners at a later time.  In the content
   processing warning situations as described above, the "disposition-
   field" SHOULD be set to the "processed" "disposition-type" value, and
   the "warning" "disposition-modifier" value.  For use in Internet EDI,
   the following "warning" "disposition-modifier" values are defined:

   "Warning: authentication-failed, processing continued"

   An example of how the "disposition-field" would look when content
   processing warnings are detected is as follows:

   Disposition: "disposition-mode"; processed/Warning:
                 authentication-failed, processing continued

5.4 Message Disposition Notification Processing

5.4.1 Large File Processing

   Large EDI Interchanges sent via SMTP can be automatically fragmented
   by some message transfer agents.  A subtype of message/partial, is
   defined in RFC 2045 [1] to allow large objects to be delivered as
   separate pieces of mail and to be automatically reassembled by the
   receiving user agent.  Using message/partial, can help alleviate
   fragmentation of large messages by different message transfer agents,
   but does not completely eliminate the problem.  It is still possible
   that a piece of a partial message, upon re-assembly, may prove to
   contain a partial message as well.  This is allowed by the Internet
   standards, and it is the responsibility of the user agent to
   reassemble the fragmented pieces.





Harding, et. al.            Standards Track                    [Page 21]

RFC 3335                 MIME-based Secure EDI            September 2002


   It is RECOMMENDED that the size of the EDI Interchange sent via SMTP
   be configurable so that if fragmentation is needed, then
   message/partial can be used to send the large EDI Interchange in
   smaller pieces.  RFC 2045 [1] defines the use of Content-Type:
   message/partial.

   Note: Support of the message/partial content type for use in Internet
   EDI is OPTIONAL and in the absence of knowledge that the recipient
   supports partial it SHOULD NOT be used.

   The receiving UA is required to re-assemble the original message
   before sending the message disposition notification to the original
   sender of the message.  A message disposition notification is used to
   specify the disposition of the entire message that was sent, and
   should not be returned by a processing UA until the entire message is
   received, even if the received message requires re-assembling.

5.4.2 Example

   The following is an example of a signed receipt returned by a UA
   after successfully processing a MIME EDI content type.  The sending
   trading partner has requested a return signed receipt.

   This example follows the S/MIME application/pkcs-7-signature format.

   NOTE: This example is provided as an illustration only, and is not
   considered part of the protocol specification.  If an example
   conflicts with the protocol definitions specified above or in the
   other referenced RFCs, the example is wrong.

        To: <recipient email>
        Subject:
        From: <sender email>
        Date: <date>
        Mime-Version: 1.0
        Content-Type: multipart/signed; boundary="separator";
          micalg=sha1; protocol="application/pkcs7-signature"

        --separator