RFC 3335 (rfc3335) - Page 3 of 29
MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet
Alternative Format: Original Text Document
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
