RFC 3335 (rfc3335) - Page 3 of 29

MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet

RFC 3335                 MIME-based Secure EDI            September 2002


   8.0   Acknowledgments .............................................26
   9.0   References ..................................................26
   Appendix IANA Registration Form ...................................28
   Authors' Addresses ................................................28
   Full Copyright Statement ..........................................29

1.0 Introduction

   Previous work on Internet EDI focused on specifying MIME content
   types for EDI data ([2] RFC 1767).  This document expands on RFC 1767
   to specify use of a comprehensive set of data security features,
   specifically data privacy, data integrity/authenticity, non-
   repudiation of origin and non-repudiation of receipt.  This document
   also recognizes contemporary RFCs and is attempting to "re-invent" as
   little as possible.  While this document focuses specifically on EDI
   data, any other data type is also supported.

   With an enhancement in the area of "receipts", as described below
   (5.2), secure Internet MIME based EDI can be accomplished by using
   and complying with the following RFCs:

      -RFC 821 SMTP
      -RFC 822 Text Message Formats
      -RFC 1767 EDI Content Type
      -RFC 1847 Security Multiparts for MIME
      -RFC 1892 Multipart/Report
      -RFC 2015, 3156, 2440 MIME/PGP

      -RFC 2045 to 2049 MIME RFCs
      -RFC 2298 Message Disposition Notification
      -RFC 2630, 2633 S/MIME v3 Specification

   Our intent here is to define clearly and precisely how these are used
   together, and what is required by user agents to be compliant with
   this document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.












Harding, et. al.            Standards Track