path: root/doc/rfc/rfc4141.txt

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]
^L
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]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


1.1.  Background

   MIME enables the distinguishing and labeling of different types of
   content [IMF, MEDTYP].  However, an email originator cannot know
   whether a recipient is able to support (interpret) a particular data
   type.  To permit the basic use of MIME, a minimum set of data types
   is specified as its support base.  How will an originator know
   whether a recipient can support any other data types?

   A mechanism for describing MIME types is specified in [FEAT].
   [CONMSG] specifies a mechanism that permits an originator to query a
   recipient about the types it supports using email messages for the
   control exchange.  This permits a recipient to propagate information
   about its capabilities back to an originator.  For the control
   exchange, using end-to-end email messages introduces considerable
   latency and some unreliability.

   An alternative approach is for an originator to use the "best" form
   of data that it can, and to include the same types of permitted
   representation information used in [CONMSG].  Hopefully, the
   recipient, or an intermediary, can translate this into a form
   supported by a limited recipient.  This specification defines such a
   mechanism.  It defines a means of matching message content form to
   the capabilities of a recipient device or system, by using MIME
   content descriptors and the optional use of an SMTP-based negotiation
   mechanism [ESMTP1, ESMTP2].

1.2.  Overview

   An originator describes desirable content forms in MIME content
   descriptors.  It may give "permission", to any intermediary or the
   recipient, to convert the content to one of those forms.  Separately,
   an SMTP server may report the target's content capabilities back to
   the SMTP client.  The client is then able to convert the message
   content into a form that is both supported by the target system and
   acceptable to the originator.

   A conversion service needs to balance between directions provided by
   the originator, directions provided on behalf of the recipient, and
   capabilities of the intermediary that performs the conversions.  This
   is complicated by the need to determine whether the directions are
   advisory or whether they are intended to be requirements.
   Conversions specified as advisory are performed if possible, but they
   do not alter message delivery.  In contrast, conversion
   specifications that are treated as a requirement will prohibit
   delivery if the recipient will not be able to process the content.





Toyoda & Crocker            Standards Track                     [Page 3]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   These possibilities interact to form different processing scenarios,
   in the event that the intermediary cannot satisfy the desires of both
   the originator and the recipient:

                 Table 1: FAILURE HANDLING

            \  RECEIVER|          |          |
             +-------+ |  Advise  | Require  |
            ORIGINATOR\|          |          |
            -----------+----------+----------+
                       | Deliver  | Deliver  |
            Advise     | original | original |
                       | content  | content  |
            -----------+----------+----------+
                       | Return   | Return   |
            Require    | w/out    | w/out    |
                       | delivery | delivery |
            -----------+----------+----------+

   This table reflects a policy that determines failure handling solely
   based on the direction provided by the originator.  Thus, information
   on behalf of the recipient is used to guide the details of
   conversion, but not delivery of the message.

   This is intended to continue the existing email practice of
   delivering content that a recipient might not be able to process.
   Clearly, the above table could be modified to reflect a different
   policy.  However, that would limit backward compatibility experienced
   by users.

   This specification provides mechanisms to support a controlled,
   transit-time mail content conversion service, through a series of
   mechanisms.  These include:

      *  an optional ESMTP hop-by-hop service that uses the CONPERM SMTP
         service extensions, issued by the originator,

      *  an optional ESMTP hop-by-hop service that uses the CONNEG SMTP
         service extensions, issued on behalf of the recipient, and

      *  three MIME Content header fields (Content-Convert, Content-
         Previous and *  Content-Features) that specify appropriate
         content header fields and record conversions that have been
         performed.







Toyoda & Crocker            Standards Track                     [Page 4]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


              Figure 1:  EXAMPLE RELAY ENVIRONMENT

         +------------+                      +-----------+
         | Originator |                      | Recipient |
         +------------+                      +-----------+
              ||Posting                   Delivering/\
              \/                                    ||
          +--------+    +-----------------+    +--------+
          |  SMTP  |    |    SMTP Relay   |    |  SMTP  |
          | Client |--->| Server | Client |--->| Server |
          +--------+    +--------+--------+    +--------+

1.3.  Notational Conventions

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
   this document are to be interpreted as defined in "Key words for use
   in RFCs to Indicate Requirement Levels" [KEYWORDS].

2.  Applicability

   This specification defines a cooperative mechanism that facilitates
   early transformation of content.  The mechanism can be used to save
   bandwidth and to permit rendering on recipient devices that have
   limited capabilities.  In the first case, the assumption is that
   conversion will produce smaller content.  In the latter case, the
   assumption is that the recipient device can render content in a form
   derived from the original, but cannot render the original form.

   The mechanism can impose significant resource requirements on
   intermediaries performing conversions.  Further, the intermediary
   accepts responsibility for conversion prior to knowing whether it can
   perform the conversion.  Also note that conversion is not possible
   for content that has been digitally signed or encrypted, unless the
   converting intermediary can decode and re-code the content.

3.  Service Specification

   This service integrates two ESMTP extensions and three MIME content
   header fields, in order to permit authorized, accountable content
   form conversion by intermediaries.  Intermediaries are ESMTP hosts
   (clients and servers) along the transmission path between an
   originator and a recipient.






Toyoda & Crocker            Standards Track                     [Page 5]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   An originator specifies preferred content-types through the Content-
   Convert MIME content header field.  The content header fields occur
   in each MIME body-part to which they apply.  That is, each MIME
   body-part contains its own record of conversion guidance and history.

   The originator's preferences are raised to the level of requirement
   through the ESMTP CONPERM service extension.  The CONPERM mechanism
   is only needed when an originator requires that conversion
   limitations be enforced by the mail transfer service.  If an
   acceptable content type cannot be delivered, then no delivery is to
   take place.

   Target system capabilities are communicated in SMTP sessions through
   the ESMTP CONNEG service extension.  This information is used to
   restrict the range of conversions that may be performed, but does not
   affect delivery.

   When CONPERM is used, conversions are performed by the first ESMTP
   host that can obtain both the originator's permission and information
   about the capabilities supported by the recipient.  If a relay or
   client is unable to transmit the message to a next-hop that supports
   CONPERM or to perform appropriate conversion, then it terminates
   message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the
   originator, with status code 5.6.3 (Conversion required but not
   supported).

   When an SMTP relay or server performs content conversion, it records
   which specific conversions are made into Content-Previous and
   Content-Features MIME header fields associated with each converted
   MIME body-part.

   If a message is protected by strong content authentication or privacy
   techniques, then an intermediary that converts message content MUST
   ensure that the results of its processing are similarly protected.
   Otherwise it MUST NOT perform conversion.

   Originator Action:

           An originator specifies desired conversion results through
      the MIME Content-Convert header field.  If the originator includes
      a Content-Convert header field, then it must also include a
      Content-Feature header field, to indicate the current form of the
      content.  Intermediaries MAY interpret the presence of this header
      field as authorization to perform conversions.  When Content-
      Convert header fields are the sole means for guiding conversions
      by intermediaries, then they serve only as advisories.  Failure to
      satisfy the guidance of these header fields does not affect final
      delivery.



Toyoda & Crocker            Standards Track                     [Page 6]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


           When posting a new message, the originator MAY specify
      transit-service enforcement of conversion limitations by using the
      ESMTP CONPERM service extension.  In each of the MIME body-parts
      for which conversion is authorized, conversions MUST be limited to
      those specified in MIME Content-Convert header fields.  If
      conversion is needed, but an authorized conversion cannot be
      performed, then the message will be returned to the originator.
      If CONPERM is not used, then failure to perform an authorized
      conversion will not affect normal delivery handling.

                          Figure 2: CONPERM USAGE

               +------------+
               | Originator |
               +------------+
                SMTP  ||
                 or   || CONPERM
               SUBMIT \/
                  +--------+            +----------------+
                  |  SMTP  |   SMTP     |    SMTP Relay  |
                  | Client |----------->| Server |       |
                  +--------+  CONPERM   +--------+-------+

   Recipient Action:

           With the ESMTP mail transfer service, capabilities that can
      be supported on behalf of the recipient SHOULD be communicated to
      intermediaries by the ESMTP CONNEG service extension.

                      Figure 3: CONNEG USAGE

                                        +-----------+
                                        | Recipient |
                                        +-----------+
                                  Capabilities||
                                              \/
               +----------------+         +--------+
               |   SMTP Relay   |  CONNEG |  SMTP  |
               |       | Client |<--------| Server |
               +-------+--------+         +--------+


   Intermediary Actions:

           An intermediary MAY be given CONPERM direction when receiving
      a message, and MAY be given CONNEG guidance before sending the
      message.  CONPERM and CONNEG operate on a per-message basis and
      are issued through the ESMTP MAIL-FROM request.  CONNEG response



Toyoda & Crocker            Standards Track                     [Page 7]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


      information is provided on a per-recipient basis, through the
      response to ESMTP RCPT-TO.

           Conversion MUST be performed by the first CONPERM
      intermediary that obtains the CONNEG capability information.  The
      MIME Content-Type MUST conform to the result of the converted
      content, as per [MEDTYP].  When an intermediary obtains different
      capability information for different recipients of the same
      message, it MAY either:

         *  Create a single, converted copy of the content that can be
            supported by all of the recipients, or

         *  Create multiple converted copies, matching the capabilities
            of subsets of the recipients.  Each version is then sent
            separately to an appropriate subset of the recipients, using
            separate, standard SMTP sessions with separate, standard
            RFC2821.Rcpt-To lists of addresses.

           A record of conversions is placed into MIME Content-Previous
      header fields.  The current form of the content is described in
      MIME Content-Features header fields.

           A special case of differential capabilities occurs when an
      intermediary receives capability information about some
      recipients, but no information about others.  An example of this
      scenario can occur when sending a message to some recipients
      within one's own organization, along with recipients located
      elsewhere.  The intermediary might have capability information
      about the local recipients, but will not have any for distant
      recipients.  This is treated as a variation of the handling that
      is required for situations in which the permissible conversions
      are the null set -- that is, no valid conversions are possible for
      a recipient.

      Rather than simply failing transmission to the recipients for
      which there is no capability information, the intermediary MAY
      choose to split the list of addressees into subsets of separate,
      standard RFC2821.Rcpt-To lists and separate, standard SMTP
      sessions, and then continue the transmission of the original
      content to those recipients via the continued use of the CONPERM
      mechanism.  Hence, the handling for such recipients is performed
      as if no CONNEG transaction took place.

           Once an intermediary has performed conversion, it MAY
      terminate use of CONPERM.  However, some relay environments, such
      as those re-directing mail to a new target device, will benefit
      from further conversion.  Intermediaries MAY continue to use



Toyoda & Crocker            Standards Track                     [Page 8]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


      CONPERM or MAY re-initiate CONPERM use when they have knowledge of
      possible variations in a target device.

         NOTE: A new, transformed version of content may have less
         information than the earlier version.  Of course, a sequence of
         transformations may lose additional information at each step.
         Perhaps surprisingly, this can result in more loss than might
         be necessary.  For example, transformation x could change
         content form A to content form B; then transformation y changes
         B to C.  However, it is possible that transformation y might
         have accepted form A directly and produced form D, which has
         more of the original information than C.

         NOTE: An originator MAY validate any conversions that are made
         by requesting a positive [DSNSMTP].  If the DSN request
         includes the "RET" parameter, the delivery agent SHOULD return
         an exact copy of the delivered (converted) message content.
         This will permit the originator to inspect the results of any
         conversion(s).

3.1.  Sending Permission

   A message originator that permits content conversion by
   intermediaries MAY use the CONPERM ESMTP service extension and
   Content-Convert MIME header fields to indicate what conversions are
   permitted by intermediaries.  Other mechanisms, by which a message
   originator communicates this permission to the SMTP message transfer
   service, are outside the scope of this specification.

         NOTE: This option requires that a server make an open-ended
         commitment to ensure that acceptable conversions are performed.
         In particular, it is possible that an intermediary will be
         required to perform conversion, but be unable to do so.  The
         result will be that the intermediary will be required to
         perform conversion, but it will be performed in undelivered
         mail.

   When an ESMTP client is authorized to participate in the CONPERM
   service, it MUST interact with the next SMTP hop server about:

      *  The server's ability to enforce authorized conversions, through
         ESMTP CONPERM

      *  The capabilities supported for the target device or system,
         through ESMTP CONNEG






Toyoda & Crocker            Standards Track                     [Page 9]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   Successful use of CONPERM does not require that conversion take place
   along the message transfer path.  Rather, it requires that conversion
   take place when a next-hop server reports capabilities that can be
   supported on behalf of the recipient (through CONNEG) and that those
   capabilities do not include support for the current representation of
   the content.

            NOTE: It is acceptable to have every SMTP server --
            including the last-hop server -- support CONPERM, with none
            offering CONNEG.  In this case, the message is delivered to
            the recipient in its original form.  Any possible
            conversions to be performed are left to the recipient.
            Thus, the recipient is given the original form of the
            content, along with an explicit list of conversions deemed
            acceptable by the originator.

   An SMTP server MAY offer ESMTP CONPERM, without being able to perform
   conversions, if it knows conversions can be performed along the
   remainder of the transfer path, or by the target device or system.

3.2.  Returning Capabilities

   A target recipient device or system arranges announcements of its
   content form capabilities to the SMTP service through a means outside
   the scope of this specification.  Note that enabling a server to
   issue CONNEG information on behalf of the recipient may require a
   substantial mechanism between the recipient and server.  When an
   ESMTP server knows a target's capabilities, it MAY offer the CONNEG
   ESMTP service extension.

            NOTE: One aspect of that mechanism, between the recipient
            and an ESMTP server offering the CONNEG ESMTP service
            extension could include offering capabilities beyond those
            directly supported by the recipient.  In particular, the
            server -- or other intermediaries between the server and the
            recipient -- could support capabilities that they can
            convert to a recipient's capability.  As long as the result
            is acceptable to the set specified in the relevant Content-
            Convert header fields of the message being converted, the
            details of these conversions are part of the
            recipient/server mechanism, and fall outside the scope of
            the current specification.

   If a next-hop ESMTP server responds that it supports CONNEG when a
   message is being processed according to the CONPERM mechanism, then
   the SMTP client:

      1) MUST request CONNEG information



Toyoda & Crocker            Standards Track                    [Page 10]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


      2) MUST perform the requisite conversions, if possible, before
         sending the message to the next-hop SMTP server

      3) MUST fail message processing, if any conversion for the message
         fails, and MUST return a failure DSN to the originator with
         status code 5.6.5  (Conversion failed).

   When performing conversions, as specified in Content-Convert MIME
   header fields, the Client MUST:

      1) Add a Content-Previous header field and a Content-Features
         header field to each MIME body-part that has been converted,
         removing any existing Content-Features header fields.

      2) Either:

            *  Send a single copy to the next-hop SMTP server, using the
               best capabilities supported by all recipients along that
               path, or

            *  Separate the transfers into multiple, standard
               RFC2821.Rcpt-To and ESMTP sessions, in order to provide
               the best conversions possible for subsets of the
               recipients.

   If the transfers are to be separated, then the current session MUST
   be terminated, and new sessions conducted for each subset.

   The conversions to be performed are determined by the intersection of
   three lists:

      *  Conversions permitted by the originator

      *  Content capabilities of the target

      *  Conversions that can be performed by the SMTP client host

   Failed Conversion

      If the result of this intersection is the null set of
      representations, for an addressee, then delivery to that addressee
      MUST be handled as a conversion failure.

      If handling is subject to the CONPERM mechanism and:

         *  the next-hop SMTP host does not indicate that it can
            represent the target's capabilities through CONNEG, but




Toyoda & Crocker            Standards Track                    [Page 11]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


         *  does respond that it can support CONPERM, then the client
            SMTP MUST send the existing content, if all other SMTP
            transmission requirements are satisfied.

      If handling is not subject to the CONPERM mechanism, then
      conversion failures do not affect message delivery.

3.3.  Next-Hop Non-Support of Service

   If a Client is participating in the CONPERM mechanism, but the next-
   hop SMTP server does not support CONPERM or CONNEG, then the SMTP
   client

      1) MUST terminate the session to the next-hop SMTP server, without
         sending the message

      2) MUST return a DSN notification to the originator, with status
         code 5.6.3 (Conversion required but not supported).  [DSNSMTP,
         DSNFMT, SYSCOD]

   If a Client is participating in the CONPERM mechanism and the next-
   hop SMTP server supports CONNEG, but provides no capabilities for an
   individual RCPT-TO addressee, then the SMTP client's processing for
   that recipient MUST be either to:

      1) Treat the addressee as a conversion failure, or

      2) Separate the addressee from the address list that is processed
         according to CONNEG, and continue to process the addressee
         according to CONPERM.

4.  Content Conversion Permission SMTP Extension

4.1.  Content Conversion Permission Service Extension Definition

   1) The name of the SMTP service extension is

      "Content-Conversion-Permission"

   2) The EHLO keyword value associated with this extension is

      "CONPERM"

   3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM
      command.

   4) The server responds with acceptance or rejection of support for
      CONPERM, for this message.



Toyoda & Crocker            Standards Track                    [Page 12]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


4.2.  CONPERM Parameter to Mail-From

   Parameter:

      CONPERM

   Arguments:

           There are no arguments.  Specification of permitted
      conversions is located in a Content-Convert header field for each
      MIME body-part in which conversion is permitted.

   Client Action:

           If the server issued a 250-CONPERM as part of its EHLO
      response for the current session, and the client is participating
      in the CONPERM service for this message -- such as by having
      received the message with a CONPERM requirement -- then the client
      MUST issue the CONPERM parameter in the MAIL-FROM.  If the server
      does not issue 250-CONPERM, and the client is participating in the
      CONPERM service for this message, then the client MUST treat the
      transmission as permanently rejected.

   Server Action:

           If the client specifies CONPERM in the MAIL-FROM, but the
      server does not support the CONPERM parameter, the server MUST
      reject the MAIL-FROM command with a 504-CONPERM reply.

           If the client issues the CONPERM parameter in the MAIL-FROM,
      then the server MUST conform to this specification.  Either it
      MUST relay the message according to CONPERM, or it MUST convert
      the message according to CONNEG information.

4.3.  Syntax

   Content-Conversion-Permission =    "CONPERM"

5.  Content Negotiation SMTP Extension

5.1.  Content Negotiation Service Extension Definition

   1) The name of the SMTP service extension is:

      "Content-Negotiation"






Toyoda & Crocker            Standards Track                    [Page 13]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   2) The EHLO keyword value associated with this extension is:

      "CONNEG"

   3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO
      command.

   4) The server responds with a report indicating the content
      capabilities that can be received on behalf of the recipient
      device or system, associated with the target RCPT-TO address.

5.2.  CONNEG Parameter to RCPT-TO

   Parameter:

      CONNEG

   Arguments:

      There are no arguments.

   Client Action:

           If a message is subject to CONPERM requirements and the
      server issues a 250-CONNEG, as part of its EHLO response for the
      current session, the client MUST issue the CONNEG parameter in the
      RCPT-TO request.  If the message is not subject to CONPERM
      requirements, and the server issues a 250-CONNEG, the client MAY
      issue the CONNEG parameter with RCPT-TO.

           If the client issues the CONNEG parameter with RCPT-TO, then
      it MUST honor the capabilities returned in the CONNEG RCPT-TO
      replies for that message.  In addition, it MUST convert the
      message content, if the current form of the content is not
      included in the capabilities listed, on behalf of the recipient.

           The conversions that are performed are determined by the
      intersection of the:

         *  Conversions permitted by the originator

         *  Content capabilities of the target

         *  Conversions that can be performed by the SMTP client host

      If the result of this intersection is the null set of
      representations, then the Client processing depends upon whether
      the next-hop server has offered CONPERM, as well as CONNEG:



Toyoda & Crocker            Standards Track                    [Page 14]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


         1) If the message will be subject to CONPERM at the next hop,
            the Client MAY transmit the original content to the next hop
            and continue CONPERM requirements.

         2) Otherwise, the Client MUST treat the conversion as failed.

           If the result of the intersection is not null, the client
      SHOULD convert the data to the "highest" level of capability of
      the server.  Determination of the level that is highest is left to
      the discretion of the host performing the conversion.

           Each converted MIME body-part MUST have a Content-Previous
      header field that indicates the previous body-part form and a
      Content-Features header field, indicating the new body-part form.

   Server Action:

           If the client specifies CONNEG in the RCPT-TO, but the server
      does not support the CONNEG parameter, the server MUST reject the
      RCPT-TO addressees with 504 replies.

           If the server does support the CONNEG parameter, and it knows
      the capabilities of the target device or system, then it MUST
      provide that information through CONNEG.  The server MAY provide a
      broader list than is supported by the recipient if the server can
      ensure that the form of content delivered can be processed by the
      recipient, while still satisfying the constraints of the author's
      Content-Convert specification(s).

           The response to a CONNEG RCPT-TO request will be multi-line
      RCPT-TO replies.  For successful (250) responses, at least the
      first line of the response must contain RCPT-TO information other
      than CONNEG.  Additional response lines are for CONNEG.  To avoid
      problems due to variations in line buffer sizes, the total
      parametric listing must be provided as a series of lines, each
      beginning with "250-CONNEG", except for the last line, which is
      "250 CONNEG".

           The contents of the capability listing MUST conform to the
      specifications in [SYN] and cover the same range of specifications
      permitted in [CONMSG].

5.3.  Syntax

      Content-Negotiation =    "CONNEG"
      Capability =             { <filter> specification,
                                 as per [SYN] }




Toyoda & Crocker            Standards Track                    [Page 15]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


6.  MIME Content-Features Header Field

   The Content-Features header field describes the characteristics of
   the current version of the content for the MIME body-part in which
   the header field occurs.  There is a separate Content-Features header
   field for each MIME body-part.  The specification for this header
   field is contained in [FEAT].

7.  MIME Content-Convert Header Field

   Content-Convert is a header field that specifies preferred
   conversions for the associated content.  It MAY be used without the
   other mechanisms defined in this document.  If present, this header
   field MUST be carried unmodified and delivered to the recipient.  In
   its absence, the content originator provides no guidance about
   content conversions, and intermediaries SHOULD NOT perform content
   conversion.

   In the extended ABNF notation, the Content-Convert header field is
   defined as follows:

      Convert =                "Content-convert" ":"
                               permitted

      Permitted =              "ANY" / "NONE" / permitted-list

      permitted-list =         { explicit list of permitted
                                  final forms, using <filter>
                                  syntax in [SYN] }

   If the permitted conversions are specified as "ANY", then the
   intermediary may perform any conversions it deems appropriate.

   If the permitted conversions are specified as "NONE", then the
   intermediary SHOULD NOT perform any conversions to this MIME body-
   part, even when the target device or system does not support the
   original form of the content.

   If a Content-Convert header field is present, then a Content-Features
   header field MUST also be present to describe the current form of the
   Content.

8.  MIME Content-Previous Header Field

   When an intermediary has performed conversion of the associated
   content, the intermediary MUST record details of the previous
   representation, from which the conversion was performed.  This
   information is placed in a Content-Previous header field that is part



Toyoda & Crocker            Standards Track                    [Page 16]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   of the MIME body-part with the converted content.  There is a
   separate header field for each converted MIME body-part.

   When an intermediary has performed conversion, the intermediary MUST
   record details of the result of the conversion by creating or
   revising the Content-Features header field for the converted MIME
   body-part.

   In the extended [ABNF] notation, the Content-Previous header field is
   defined as follows:

      previous =          "Content-Previous" [CFWS] ":"
                          [CFWS]
                          date by type

      date =              "Date " [CFWS] date-time [CFWS] ";"
                          [CFWS]

      by =                "By " [CFWS] domain [CFWS] ";"
                          [CFWS]

      type =              { content characteristics, using
                            <filter> syntax in [SYN] }

   The Date field specifies the date and time at which the indicated
   representation was converted into a newer representation.

   The By field specifies the domain name of the intermediary that
   performed the conversion.

   An intermediary MAY choose to derive the Content-Previous header
   field, for a body-part, from an already-existing Content-Features
   header field in that body-part, before that header field is replaced
   with the description of the current representation.

9.  Examples

9.1.  CONPERM Negotiation

   S: 220 example.com IFAX
   C: EHLO example.com
   S: 250- example.com
   S: 250-DSN
   S: 250 CONPERM
   C: MAIL FROM:May@some.example.com CONPERM
   S: 250 <May@some.example.com> originator ok
   C: RCPT TO:<June@some.example.com>
   S: 250-<June@some.example.com> recipient ok



Toyoda & Crocker            Standards Track                    [Page 17]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   C: DATA
   S: 354 okay, send data
   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
      Per:
      (  image-file-structure=TIFF-minimal
         dpi=400
         image-coding=JBIG
         size-x=2150/254
         paper-size=letter
      )
      with MIME body-parts including:
      Content-Convert:
         (&(image-file-structure=TIFF-minimal)
           (MRC-mode=0)
           (color=Binary)
           (|(&(dpi=204)
               (dpi-xyratio=[204/98,204/196]) )
             (&(dpi=200)
               (dpi-xyratio=[200/100,1]) )
             (&(dpi=400)
               (dpi-xyratio=1) ) )
           (|(image-coding=[MH,MR,MMR])
             (&(image-coding=JBIG)
               (image-coding-constraint=JBIG-T85)
               (JBIG-stripe-size=128) ) )
           (size-x<=2150/254)
           (paper-size=[letter,A4])
           (ua-media=stationery) )
      >>
   S: 250 message accepted
   C: QUIT
   S: 221 goodbye

9.2.  Example CONNEG Negotiation

   S: 220 example.com IFAX
   C: EHLO example.com
   S: 250- example.com
   S: 250-DSN
   S: 250 CONNEG
   C: MAIL FROM:<May@some.example.com>
   S: 250 <May@some.example.com> originator ok
   C: RCPT TO:<June@ifax1.jp> CONNEG
   S: 250-<June@some.example.com> recipient ok
   S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
   S: 250-CONNEG   (MRC-mode=0)
   S: 250-CONNEG   (color=Binary)
   S: 250-CONNEG   (|(&(dpi=204)



Toyoda & Crocker            Standards Track                    [Page 18]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
   S: 250-CONNEG     (&(dpi=200)
   S: 250-CONNEG       (dpi-xyratio=[200/100,1]) ) )
   S: 250-CONNEG   (image-coding=[MH,MR,MMR])
   S: 250-CONNEG   (size-x<=2150/254)
   S: 250-CONNEG   (paper-size=[letter,A4])
   S: 250 CONNEG   (ua-media=stationery) )
   C: DATA
   S: 354 okay, send data
   C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
        Per:
        (  image-file-structure=TIFF-minimal
           dpi=400
           image-coding=JBIG
           size-x=2150/254
           paper-size=letter
         )
      >>
   S: 250 message accepted
   C: QUIT
   S: 221 goodbye

9.3.  Content-Previous

   Content-Previous:
      Date  Tue, 1 Jul 2001 10:52:37 +0200;
      By    relay.example.com;
      (&(image-file-structure=TIFF-minimal)
        (MRC-mode=0)
        (color=Binary)
        (&(dpi=400)
          (dpi-xyratio=1) )
        (&(image-coding=JBIG)
          (image-coding-constraint=JBIG-T85)
          (JBIG-stripe-size=128) )
        (size-x=2150/254)
        (paper-size=A4)
        (ua-media=stationery) )

10.  Security Considerations

   This service calls for disclosure of capabilities, on behalf of
   recipients.  Mechanisms for determining the requestor's and the
   respondent's authenticated identity are outside the scope of this
   specification.  These mechanisms are intended to permit disclosure of
   information that is safe for public distribution; hence, there is no
   inherent need for security measures.




Toyoda & Crocker            Standards Track                    [Page 19]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   Information that should have restricted distribution is still able to
   be disclosed.  Therefore, it is the responsibility of the disclosing
   ESMTP server or disclosing ESMTP client to determine whether
   additional security measures should be applied to the use of this
   ESMTP option.

   Use of the ESMTP CONNEG option permits content transformation by an
   intermediary, along the mail transfer path.  When the contents are
   encrypted, the intermediary cannot perform the conversion, because it
   is not expected to have access to the relevant secret keying
   material.  When the contents are signed, but not encrypted,
   conversion will invalidate the signature.  This specification
   provides for potentially unbounded computation by intermediary MTAs,
   depending on the nature and amount of conversion required.  Further,
   this computation burden might provide an opportunity for denial-of-
   service attacks, given that Internet mail typically permits
   intermediaries to receive messages from all Internet sources.

   This specification provides for content conversion by unspecified
   intermediaries.  Use of this mechanism carries significant risk.
   Although intermediaries always have the ability to perform damaging
   transformations, use of this specification could result in more
   exploration of that potential and, therefore, more misbehavior.  Use
   of intermediaries is discussed in [RFC3238].

   CONPERM/CONNEG provide a cooperative mechanism, rather than enabling
   intermediary actions that were not previously possible.
   Intermediaries already make conversions on their own initiative.
   Hence, the mechanism introduces essentially no security concerns,
   other than divulging recipient preferences.

11.  Acknowledgements

   Graham Klyne and Eric Burger provided extensive, diligent reviews and
   suggestions.  Keith Moore, Giat Hana, and Joel Halpern provided
   feedback that resulted in improving the specification's integration
   into established email practice.

12.  References

12.1.  Normative References

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Toyoda & Crocker            Standards Track                    [Page 20]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   [CONMSG]   Klyne, G., Iwazaki, R., and D. Crocker, "Content
              Negotiation for Messaging Services based on Email", RFC
              3297, July 2002.

   [DSNSMTP]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)", RFC
              3461, January 2003.

   [DSNFMT]   Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464, January
              2003.

   [SYSCOD]   Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
              3463, January 2003.

   [ESMTP1]   Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
              November 1995.

   [ESMTP2]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [FEAT]     Klyne, G., "Indicating Media Features for MIME Content",
              RFC 2912, September 2000.

   [IMF]      Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [SYN]      Klyne, G., "A Syntax for Describing Media Feature Sets",
              RFC 2533, March 1999.

   [MEDTYP]   IANA, "MIME Media Types",
              <http://www.iana.org/assignments/media-types>

   [CFWS]     Alvestrand, H., "Content Language Headers", RFC 3282, May
              2002.

12.2.  Informative References

   [RFC3238]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
              Considerations for Open Pluggable Edge Services", RFC
              3238, January 2002.









Toyoda & Crocker            Standards Track                    [Page 21]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


Appendix A.  CONNEG with Direct SMTP

   This Appendix is descriptive.  It only provides discussion of usage
   issues permitted or required by the normative text

   In some configurations, it is possible to have direct, email-based
   interactions, where the originator's system conducts a direct,
   interactive TCP connection with the recipient's system.  This
   configuration permits a use of the content form negotiation service
   that conforms to the specification here, but permits some
   simplifications.  This single SMTP session does not have the
   complexity of multiple, relaying sessions and therefore does not have
   the requirement for propagating permissions to intermediaries.

   The Originator's system provides user-level functions for the
   originator, and it contains the SMTP Client for sending messages.
   Hence, the formal step of email "posting" is a process that is
   internal or virtual, within the Originating system.  The recipient's
   service contains the user-level functions for the recipient, and
   contains the SMTP server for receiving messages.  Hence, the formal
   steps of email "delivering" and "receipt" are internal or virtual,
   within the Receiving system.

                    Figure 4: DIRECT CONNEG

         Originating system          Receiving system
        +------------------+       +------------------+
        |  +------------+  |       |   +-----------+  |
        |  | Originator |  |       |   | Recipient |  |
        |  +------------+  |       |   +-----------+  |
        |       ||Posting  |       |      /\Receiving |
        |       \/         |       |      ||          |
        |   +---------+    |       |    +--------+    |
        |   |  SMTP   |<---|-------|----|  SMTP  |    |
        |   | Client  |----|-------|--->| Server |    |
        |   +---------+    |       |    +--------+    |
        +------------------+       +------------------+

   In this case, CONPERM is not needed because the SMTP Client is part
   of the originating system and already has the necessary permission.
   Similarly, the SMTP server will be certain to know the recipient's
   capabilities, because the server is part of the receiving system.

   Therefore, Direct Mode email transmission can achieve content
   capability and form matching by having:






Toyoda & Crocker            Standards Track                    [Page 22]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


      *  Originating systems that conform to this specification and a
         communication process between originator and recipient that is
         the same as would take place between a last-hop SMTP Relay and
         the Delivering SMTP server to which it is connected.

      *  That is, the Client and Server MUST employ CONNEG and the
         Client MUST perform any requisite conversions.

Appendix B.  Using Combinations of the Extensions

   This specification defines a number of mechanisms.  It is not
   required that they all be used together.  For example, the difference
   between listing preferred conversions -- versus specifying enforced
   limitations to conversions -- is discussed in the Introduction.  This
   Appendix further describes scenarios that might call for using fewer
   than the complete set defined in this specification.  It also
   summarizes the conditions which mandate that an intermediary perform
   conversion.

   This Appendix is descriptive.  It only provides discussion of usage
   issues permitted or required by the normative text

   The available mechanisms are:

      1. CONPERM Parameter to Mail-From
      2. CONNEG parameter to RCPT-TO
      3. MIME Content-Convert Header Field
      4. MIME Content-Previous Header Field
      5. MIME Content-Features Header Field

B.1.  Specifying Suggested Conversion Constraints

   Use of the MIME Content-Convert header field specifies the
   originator's preferences, should conversion be performed.  This does
   not impose any requirements on the conversion; it is merely advisory.

B.2.  Specifying Required Conversion Constraints

   When the MIME Content-Convert specification is coupled with the ESMTP
   CONPERM option, then the originator's specification of preferred
   conversions rises to the level of requirement.  No other conversions
   are permitted, except those specified in the Content-Convert header
   field.

      Note that the presence of both mechanisms does not require that
      conversions be performed.  Rather, it constrains conversions,
      should they occur.




Toyoda & Crocker            Standards Track                    [Page 23]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


B.3.  Accepting All Forms of Content

   Although it is unlikely that any device will always able to process
   every type of existing content, some devices can be upgraded easily
   (e.g., adding plug-in).  Hence, such a device is able to process all
   content effectively.

   For such devices, it is better to refrain from issuing a CONNEG
   assertion.  Instead, the CONPERM request should be propagated to the
   target device.

B.4.  When Conversion is Required

   A node is required to perform conversion when:

      1. At least one MIME Content-Covert header field is present in the
         message,

      2. ESMTP CONPERM is in force at the node processing the message,

      3. ESMTP CONNEG is also in force at the same node,

      4. The current content form is not cited in the CONNEG list,

      5. At least one content form is present, both in the Content-
         Convert list and the CONNEG list, and

      6. The intermediary is able to convert from the current form to
         one of the forms listed in both Content-Convert and CONNEG.

Appendix C.  MIME Content-Type Registrations

C.1.  Content-Convert

   Header field name:
      Content-Convert

   Applicable protocol:
      Mail (RFC 2822)

   Status:
      Proposed Standard

   Author/Change controller:
      IETF

   Specification document(s):
      RFC 4141.



Toyoda & Crocker            Standards Track                    [Page 24]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


   Related information:
      None.

C.2.  Content-Previous

   Header field name:
      Content-Previous

   Applicable protocol:
      Mail (RFC 2822)

   Status:
      Proposed Standard

   Author/Change controller:
      IETF

   Specification document(s):
      RFC 4141, Section 8

   Related information:
      None.

Authors' Addresses

   Kiyoshi Toyoda
   Panasonic Communications Co., Ltd.
   4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan

   EMail: toyoda.kiyoshi@jp.panasonic.com


   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086  USA

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net












Toyoda & Crocker            Standards Track                    [Page 25]
^L
RFC 4141     SMTP & MIME Extensions for Content Conversion November 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Toyoda & Crocker            Standards Track                    [Page 26]
^L