SMTP and MIME Extensions for Content Conversion
RFC 4141
Document | Type | RFC - Proposed Standard (November 2005; Errata) | |
---|---|---|---|
Authors | Dave Crocker , Kiyoshi Toyoda | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4141 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | dcrocker@bbiw.net |
Network Working Group K. Toyoda Request for Comments: 4141 PCC Category: Standards Track D. Crocker Brandenburg November 2005 SMTP and MIME Extensions for Content Conversion Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and- forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. Toyoda & Crocker Standards Track [Page 1] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Notational Conventions. . . . . . . . . . . . . . . . . . 5 2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Service Specification. . . . . . . . . . . . . . . . . . . . . 5 3.1. Sending Permission. . . . . . . . . . . . . . . . . . . . 9 3.2. Returning Capabilities. . . . . . . . . . . . . . . . . . 10 3.3. Next-Hop Non-Support of Service . . . . . . . . . . . . . 12 4. Content Conversion Permission SMTP Extension . . . . . . . . . 12 4.1. Content Conversion Permission Service Extension Definition. . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. CONPERM Parameter to Mail-From. . . . . . . . . . . . . . 13 4.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Content Negotiation SMTP Extension . . . . . . . . . . . . . . 13 5.1. Content Negotiation Service Extension Definition. . . . . 13 5.2. CONNEG Parameter to RCPT-TO . . . . . . . . . . . . . . . 14 5.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. MIME Content-Features Header Field . . . . . . . . . . . . . . 16 7. MIME Content-Convert Header Field. . . . . . . . . . . . . . . 16 8. MIME Content-Previous Header Field . . . . . . . . . . . . . . 16 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. CONPERM Negotiation . . . . . . . . . . . . . . . . . . . 17 9.2. Example CONNEG Negotiation. . . . . . . . . . . . . . . . 18 9.3. Content-Previous. . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. CONNEG with Direct SMTP. . . . . . . . . . . . . . . . 22 Appendix B. USING Combinations of the Extensions . . . . . . . . . 23 Appendix C. MIME Content-Type Registrations. . . . . . . . . . . . 24 1. Introduction Internet specifications typically define common capabilities for a particular service that are supported by all participants. This permits the sending of basic data without knowing which additional capabilities individual recipients support. However, knowing those capabilities permits the sending of additional types of data and data of enhanced richness. Otherwise, a message originator will send content in a form the recipient cannot process or will send multiple forms of data. This specification extends the work of [CONMSG], which permits a recipient to solicit alternative content forms from the originator. The current specification enables MIME content conversion by intermediaries, on behalf of a message originator and a message recipient. Toyoda & Crocker Standards Track [Page 2] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 1.1. Background MIME enables the distinguishing and labeling of different types ofShow full document text