[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 4141

Network Working Group                   K. Toyoda / MGCS Internet
Draft                                    D. Crocker / Brandenburg
   draft-ietf-fax-esmtp-conneg-09.txt               December 2003

Expires: <06-04>



                  SMTP and MIME Extensions
                   For Content Conversion



     STATUS OF THIS MEMO

     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     RFC2026.  Internet-Drafts are working documents of the
     Internet Engineering Task Force (IETF), its areas and
     its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum
     of six months and may be updated, replaced,
     or obsoleted by other documents at any time.  It is
     inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be
     accessed at
     http://www.ietf.org/shadow.html.

     COPYRIGHT NOTICE

     Copyright (C) The Internet Society (2003).  All Rights
     Reserved.

     SUMMARY

     A message originator sometimes sends content in a form
     the recipient cannot process.  Such content needs to be
     converted to a related form, with the same or with
     restricted information, such as changing from color to
     black and white.  In a store-and-forward environment,
     it can be convenient to have this conversion performed
     by an intermediary.  This specification integrates two
     ESMTP extensions and three MIME content headers, to
     permit authorized, accountable content form conversion
     by intermediaries.




     CONTENTS

1.   Introduction
     1.1. Background
     1.2. Overview
     1.3. Conventions

2.   Service Specification
     2.1. Sending Permission
     2.2. Returning Capabilities
     2.3. Next-Hop Non-Support of Service

3.   Content Conversion Permission SMTP Extension
     3.1. Content Conversion Permission Service Extension
          Definition
     3.2. CONPERM Parameter to Mail-From
     3.3. Syntax

4.   Content Negotiation SMTP extension
     4.1. Content Negotiation Service Extension Definition
     4.2. CONNEG parameter to RCPT-TO
     4.3. Syntax

5.   MIME Content-Convert Header

6.   MIME Content-Previous Header

7.   MIME Content-Features Header

8.   Examples
     8.1. CONPERM Negotiation
     8.2. Example CONNEG Negotiation
     8.3. Content-Previous

9.   IANA Considerations

10.  Security Considerations

11.  Acknowledgements

12.  References

13.  Authors' Addresses

14.  Full Copyright Statement

Appendix A:   CONNEG with Direct SMTP




1.   INTRODUCTION

     Internet specifications typically define common
     capabilities that are to supported by all participants
     for a particular service.  This permits sending basic
     data without needing to know the additional
     capabilities supported by individual recipients.
     However, knowing those capabilities permits sending
     additional types of data and data of enhanced richness.
     Otherwise, a message originator is faced with sending
     content in a form the recipient cannot process or with
     sending multiple forms of data.  This specification
     enables MIME content conversion on behalf of a message
     originator and a message recipient.



1.1.      Background

     MIME enables distinguishing and labeling different
     types of content. However an originator cannot know
     whether a recipient is able to support (interpret) any
     particular data type. In order to permit basic use of
     MIME, a minimum set of data types are specified as its
     support base. How is an originator to know whether a
     recipient can support any other types?

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

     An alternative approach is for an originator to use the
     "best" form of data that it can, and hope that the
     recipient, or an intermediary, can translate this into
     a form that is supported by a limited recipient.  The
     current document 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.



1.2.      Overview

     An originator describes desirable content forms, in
     MIME content descriptors.  It further may give
     "permission", to any intermediary or the recipient, to
     convert the content to only 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 message content to a
     form that is both supported by the target system and is
     acceptable to the originator.

     A conversion service needs to balance between
     directions provided by the originator, directions
     provided by the recipient, and capabilities of the
     intermediary that is performing the conversions.  This
     is made more complex by needing to distinguish between
     such directions being merely advisory, versus having
     them intended as requirements.  Conversions that are
     specified as advisory are performed if possible, but
     they do not alter message delivery.  In contrast,
     conversion specifications that are treated as a
     requirement prohibit delivery if the recipient will be
     unable to process the content.

     These possibilities interact to form different
     processing scenarios, in the event 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.  Hence, information from the recipient is
     used to guide the details of conversion, but not to
     decide whether to deliver the message.

     This is intended to continue existing email practise 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 the 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 by the recipient, and

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

     Figure 1:  EXAMPLE RELAY ENVIRONMENT

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



1.3.      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.   SERVICE SPECIFICATION

     This service integrates two ESMTP extensions and three
     MIME content headers, 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.

     An originator specifies preferred content-types through
     the Content-Convert MIME content header. The content
     headers 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 preference's 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 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 the recipient's capabilities.  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 [DSN] to the originator.

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


     Originator Action:

          An originator specifies desired conversion
     results, through the MIME Content-Convert header.
     Intermediaries MAY interpret the presence of this
     header as authorization to perform conversions. When
     Content-Convert headers are the sole means for guiding
     conversions by intermediaries, then they serve only as
     advisories.  In particular, failure to satisfy the
     guidance of these headers does not affect final
     delivery.

          The originator MAY also specify transit-service
     enforcement of conversion limitations by using the
     ESMTP CONPERM service extension when posting a new
     message.  Conversions MUST be limited to those
     specified in MIME Content-Convert headers, in each MIME
     body-part for which conversions are authorized.  If
     conversion is needed, but an authorized conversion
     cannot be performed, then the message is returned to
     the originator.  If CONPERM is not used, then failure
     to perform an authorized conversion does not affect
     normal delivery handling.

     Figure 2: CONPERM USAGE

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


     Recipient Action:

          Recipient capabilities 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.  Therefore they
     are issued through the ESMTP MAIL-FROM request.  CONNEG
     response 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 CONNEG recipient capability
     information.  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.

          A record of conversions is placed into MIME
     Content-Previous headers.  The current form of the
     content is provided in MIME Content-Features headers.

          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 and other 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 required when 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 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 CONPERM or MAY re-
     initiate CONPERM use, when they have knowledge about
     possible variations in target device.



2.1.      Sending Permission

     A message originator that permits content conversion by
     intermediaries MAY use the CONPERM ESMTP service
     extension and Content-Convert MIME headers 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.

     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 support authorized conversions,
          through ESMTP CONPERM

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

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

     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.  Hence the recipient is given the original
     form of the content, along with an explicit list of
     conversions that the originator deems acceptable.

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



2.2.      Returning Capabilities

     A target recipient device or system communicates its
     content form capabilities to the SMTP service through a
     means outside the scope of this specification.  When an
     ESMTP server knows a target's capabilities, it MAY
     offer the CONNEG ESMTP service extension.

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

     (1)  MUST request CONNEG information

     (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

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

     (1)  Add a Content-Previous header and a Content-Features
          header to each MIME body-part that has been converted.

     (2)  Either:

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

          *    Separate the transfers, to provide the best conversions
               possible for subsets of the recipients.

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

     The conversions that are 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

     *    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 hanling is not subject to the CONPERM mechanism,
     then conversion failures do not affect message
     delivery.



2.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
     and does not support 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 that
          content negotiation could not be performed.

     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.




3.   CONTENT CONVERSION PERMISSION SMTP EXTENSION



3.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.



3.2.      CONPERM Parameter to Mail-From


     Parameter:

          CONPERM


     Arguments:

          There are no arguments.  Specification of
     permitted conversions is located in a Content-Convert
     header for each MIME body-part for 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.



3.3.      Syntax

     Content_Conversion_Permission =    "CONPERM"




4.   CONTENT NEGOTIATION SMTP EXTENSION



4.1.      Content Negotiation Service Extension Definition

     (1)  The name of the SMTP service extension is:

          "Content_Negotiation"

     (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 of the content
          capabilities of the device or system that embodies each
          target RCPT-TO address.



4.2.      CONNEG parameter to RCPT-TO


     Parameter:

          CONNEG


     Arguments:

          There are no arguments.


     Client Action:

          If 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, and it
     MUST convert the message content, if the current form
     of the content is not included in the recipient
     capabilities.

          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 message is subject to CONPERM
     processing:

          (1)  If the message is subject to CONPERM, the Client MAY
               continue to transmit the original content, according to
               CONPERM.

          (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-
     Converted header that indicates the previous body-part
     form and a Content-Features header, 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 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 is
     for RCPT-TO information other than CONNEG.  Additional
     response lines are for CONNEG.  In order 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, FAX].



4.3.      Syntax

     Content_Negotiation =    "CONNEG"
     Capability =             <<as per [SYN, FAX]>>




5.   MIME CONTENT-CONVERT HEADER

     Content-Convert is an optional header field that
     specifies permitted conversions for the associated
     content.  It MAY be used without the other mechanisms
     defined in this document.  If present, this header MUST
     be carried unmodified and delivered to the recipient.
     In its absence the content originator has provided 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 conversions, per
                              [SYN, FAX]>>

     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.




6.   MIME CONTENT-PREVIOUS HEADER


     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 that is associated with
     the MIME body-part having converted content.  There is
     a separate header for each, 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, per
                         [SYN, FAX], without alternatives>>

     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, for a body-part, from an already-
     existing Content-Features header in that body-part,
     before that header is replaced with the description of
     the current representation.




7.   MIME CONTENT-FEATURES HEADER

     When an intermediary has performed conversion, the
     intermediary MUST record details of the result of the
     conversion that was performed.  This information is
     placed in a Content-Features header associated with
     each MIME body-part having converted content.  There is
     a separate Content-Features header for each MIME body-
     part.

     The specification for this header is contained in
     [FEAT].




8.   EXAMPLES



8.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
     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




8.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)
     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




8.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) )




9.   IANA CONSIDERATIONS

     This memo is not intended to create any new issues for
     IANA.




10.       SECURITY CONSIDERATIONS

     This service calls for recipients to disclose their
     capabilities.  Mechanisms for determining the
     requestor's and the respondent's authenticated identity
     are outside the scope of this specification.  It is
     intended that these mechanisms permit disclosure of
     information that can safely be public; hence there is
     no inherent need for security measures.

     Information that should receive restricted distribution
     is still able to be disclosed.  It is, therefore, 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.




11.       ACKNOWLEDGEMENTS

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




12.       REFERENCES


     Normative:

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

      [DISP]        Masinter, L., Holtman, K., Mutz, A. and
                    D. Wing, "Media Features for Display,
                    Print, and Fax", RFC 2534, March 1999.

     [DSN]          Moore, K., "SMTP Service Extension for
                    Delivery Status Notifications", RFC
                    1892, January 1996.

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

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

     [FAX]          McIntyre, L. and G. Klyne, "Content
                    Feature Schema for Internet Fax", RFC
                    2879, August 2000

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

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

     [TAG]          Holtman, K., Mutz, A. and T. Hardie,
                    "Media Feature Tag Registration
                    Procedure", RFC 2506, March 1999.

     [SETS]         Klyne, G., "A syntax for describing
                    media feature sets", RFC 2533, March
                    1999.

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


     Informative:

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




13.       AUTHORS' ADDRESSES

     Kiyoshi Toyoda
     Network Technology Development Center
     Panasonic Communications Co., Ltd.
     2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan

     tel: +81-3-5434-7161
     fax: +81-3-5434-7156
     toyoda.kiyoshi@jp.panasonic.com


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

     Tel: +1.408.246.8253
     dcrocker@brandenburg.com




14.       FULL COPYRIGHT STATEMENT

     Copyright (C) The Internet Society (2003).  All Rights
     Reserved.

     This document and translations of it may be copied and
     furnished to others, and derivative works that comment
     on or otherwise explain it or assist in its
     implementation may be prepared, copied, published and
     distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and
     derivative works.  However, this document itself may
     not be modified in any way, such as by removing the
     copyright notice or references to the Internet Society
     or other Internet organizations, except as needed for
     the purpose of developing Internet standards in which
     case the procedures for copyrights defined in the
     Internet Standards process must be followed, or as
     required to translate it into languages other than
     English.

     The limited permissions granted above are perpetual and
     will not be revoked by the Internet Society or its
     successors or assigns.

     This document and the information contained herein is
     provided on an "AS IS" basis and THE INTERNET SOCIETY
     AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.




APPENDIX A:   CONNEG WITH DIRECT SMTP

     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 it 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.  Therefore it
     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:

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

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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/