SMTP and MIME Extensions for Content Conversion
RFC 4141
|
| Document |
Type |
|
RFC - Proposed Standard
(November 2005; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4141 (Proposed Standard)
|
|
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]
Show full document text