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