Network Working Group                        K. Toyoda, MGCS
Internet Draft                       D. Crocker, Brandenburg
  draft-ietf-fax-esmtp-conneg-03.txt             August 2002
Expires: January 2003



                   SMTP Service Extension
                   for Content Negotiation



     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 (2001).  All Rights
     Reserved.

     ABSTRACT

     This document defines a content negotiation service
     extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP
     client may request information about content
     capabilities of the target device or system that is
     serviced by an SMTP server.  The SMTP server may report
     the target's content capabilities back to the client.
     This process emulates a classic facsimile start-of-
     session capabilities negotiation, although it can be used
     for a broad range of email-based scenarios.  This service
     extension is primarily intended for "direct", one-hop,
     originator/recipient SMTP transfers, although relayed
     scenarios through multiple SMTP servers are permitted.


.   INTRODUCTION

     When a data source and a receiver have interactive access to
     each other, the receiver often informs the source of its
     capabilities, to permit optimized performance or functionality for
     the interaction.  Classic telephone-based facsimile is an example,
     as are voice over IP and ESMTP, among Internet applications.  The
     store-and-forward nature of Internet mail is usually assumed to
     preclude such capabilities exchanges, although the sender in a
     store-and-forward scenario could benefit from knowing precise
     details about the receiver.  In some configurations, direct
     email-based interactions -- with the originating ESMTP client
     and the destination ESMTP server able to have direct TCP
     connect -- are possible, such as over an intranet. In addition
     an end-to-end exchange can ESMTP for hop-by-hop enforcement.

     This document defines an SMTP-based service extension [ESMTP1,
     ESMTP2] for content negotiation, whereby an SMTP client may
     request information about content capabilities of the target
     device or system that is serviced by an SMTP server.  The SMTP
     server may report the target's content capabilities back to the
     client. This process can be used to emulate a classic facsimile
     start-of-session capabilities negotiation, as well as being used
     for other email-based services.  The extension is primarily
     intended for "direct" SMTP transfers, although relayed scenarios
     are permitted through a series of SMTP servers and are discussed
     in Appendix B.


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



.   CONTENT NEGOTIATION SERVICE EXTENSION

     (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 command

     (4)  The server responds with a report of the content
          capabilities of the device or system that embodies the
          target RCPT address.



.   CONNEG PARAMETER TO RCPT

4.1  Parameter

     Keyword:

          CONNEG

     Argument:

          REQUIRED
            The client requires support for the capability. If the
            target does not support the CONNEG parameter, the target
            MUST reject the RCPT command with a 504 reply.

            If the target can not support the capability due to a
            temporary problem, it MUST reject the RCPT command with
            a 404 reply.

          OPTIONAL
            The client requests the target to use the capability. If
            the target can not support the capability at this time, the
            target MUST process the address and message as if the
            requested CONNEG capabilities had not been specified.

          If the argument does not exist, the default is "REQUIRED".

          When a capability is REQUIRED by the client but can not
          currently be supported by the target, an error response will
          have significant performance impact to overall SMTP
          processing.  Use of the OPTIONAL parameter will ensure high
          SMTP performance.


4.2 Client Action

     If the server issued a 250-CONNEG, as part of its
     EHLO response for the current session, the client MAY
     issue the CONNEG parameter with RCPT.

     If the client issues the CONNEG parameter with
     RCPT, then it MUST honor the capabilities specified
     in the CONNEG RCPT reply, and transform data that is
     sent, so that the server can accept the data. The
     client SHOULD transform the data to the "highest" level
     of capability of the server.

     If the server rejects the RCPT command with a 404 reply, the
     client may later reissue the RCPT with the CONNEG parameter
     in a different SMTP session.

     If the server returns an EHLO 250 code without CONNEG
     capabilities, the client MUST NOT issue a CONNEG parameter
     with RCPT.

     Methods of using of this option with multiple addressees, for
     the same content, are discussed in Appendix A.


4.3 Server Action

     If the client specifies "CONNEG=REQUIRED" in the RCPT,
     but the server does not support the CONNEG parameter, the server
     MUST reject the RCPT command with a 504 reply.

     If the server supports the CONNEG parameter, but can not return
     the recepient's capability temporarily, the server MUST reject the
     RCPT command with a 404 reply. For example, if the server gets
     the capability information from a directory, but its connection is
     offline, the server MUST reject the RCPT command with a 404
     reply.

     If the client specifies "CONNEG=OPTIONAL" in the RCPT,
     but the server does not support the CONNEG parameter or can not
     return the recipient's capability temporarily, the server MUST
     process the address and message as if the requested CONNEG
     capabilities had not been specified.

     Regardless of the value of the parameter, if the server does
     support the CONNEG parameter and the address is acceptable,
     then it MUST issue a 250 reply, followed by the capabilities
     of the server that is specified by  the RCPT address.
     Successful responses to CONNEG RCPT requests will always be
     multiple SMTP lines.  The first line is the normal RCPT response,
     and subsequent lines beginning with the exact string
     "250-CONNEG " and "250 CONNEG " are the CONNEG responses.
     The last line begins with "250 CONNEG ".

     If the SMTP server supports ENHANCEDSTATUSCODES [RFC1893], the
     response strings for a success are "250-2.1.5 CONNEG" and
     "250 2.1.5 CONNEG". The response strings for indicating a
     permanent failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG".
     The response strings for a temporary failure are "404-4.3.3
     CONNEG" and "404 5.3.3 CONNEG".

     All CONNEG-capable clients and CONNEG-capable servers MUST
     be able to successfully process CONNEG lines that are up to 512
     characters long, as required by RFC2821. If the length of CONNEG
     lines is greater than 512 characters, the server MUST insert
     line breaks and make next CONNEG line.

     The contents of the capability listing MUST conform to
     the specifications in "Content Feature Schema for Internet Fax".
     [RFC2879]




.   SYNTAX

     Command with "CONNEG":
      "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
                   / Forward-Path) (SP "CONNEG =" ("REQUIRED" /
                 "OPTIOANL") CRLF

     Reply:
      ( ("250-" CRLF) *("250-CONNEG" capability CRLF)
        ("250 CONNEG" capability CRLF) )/
      ( ("250-2.1.5" CRLF)
          *("250-2.1.5 CONNEG" capability CRLF)
           ("250 2.1.5 CONNEG" capability CRLF) )/
      ("504" CRLF) /
      ("504 5.3.3" CRLF) /
      ("404" CRLF) /
      ("404 4.3.3" CRLF) /

      capability  =  <<as per [RFC2879]>>



.   EXAMPLES

6.1  Success Response

     An example of ESMTP sequence with successful RCPT response

     S: 220 ifax1.jp IFAX

     C: EHLO ifax1.jp

     S: 250-ifax1.jp
     S: 250-DSN
     S: 250 CONNEG

     C: MAIL FROM:<May@ifax2.jp>

     S: 250 <May@ifax2.jp> sender ok

     C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED

     S: 250-<June@ifax1.jp> recipient ok
     S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
     S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
     S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
     S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
     S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
     S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
     S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
     S: (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
           )
        >>

     S: 250 message accepted

     C: QUIT

     S: 221 goodbye


6.2  Long Response

     An example of successful RCPT response when the length of
     capability is greater than 512 characters.

     S: 250-2.1.5<June@ifax1.jp> recipient ok
     S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) ...
     S: 250-2.1.5 CONNEG   .....
     S: 250 2.1.5 CONNEG   (color=Binary)


     An example of succssful RCPT response when CONNEG-capable
     server supports ENHANCEDSTATUSCODES.

     S: 250-2.1.5<June@ifax1.jp> recipient ok
     S: 250 2.1.5 CONNEG (&(image-file-structure=TIFF-minimal)
     S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
     S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
     S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
     S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
     S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
     S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
     S: (ua-media=stationery) )


6.3  Failure Response

     An example of ESMTP sequence with parmanent failure RCPT
     response.

     S: 220 ifax1.jp IFAX

     C: EHLO ifax1.jp

     S: 250-ifax1.jp
     S: 250-DSN

     C: MAIL FROM:<May@ifax2.jp>

     S: 250 <May@ifax2.jp> sender ok

     C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED

     S: 504 <June@ifax1.jp> recipient ok

     C: QUIT

     S: 221 goodbye


6.4  Temporary Failure Response

     An example of an ESMTP sequence with temporary failure RCPT
     response when the value of parameter is "REQUIRED":

     S: 220 ifax1.jp IFAX

     C: EHLO ifax1.jp

     S: 250-ifax1.jp
     S: 250-DSN
     S: 250 CONNEG

     C: MAIL FROM:<May@ifax2.jp>

     S: 250 <May@ifax2.jp> sender ok

     C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED

     S: 404 <June@ifax1.jp> recipient ok

     C: QUIT

     S: 221 goodbye
     .
     .
     .
     retry according to implementation


6.5  Temporary Failure with Optional handling

     An example of an ESMTP sequence with temporary failure RCPT
     response when the value of parameter is "OPTIONAL":

     S: 220 ifax1.jp IFAX

     C: EHLO ifax1.jp

     S: 250-ifax1.jp
     S: 250-DSN
     S: 250 CONNEG

     C: MAIL FROM:<May@ifax2.jp>

     S: 250 <May@ifax2.jp> sender ok

     C: RCPT TO:<June@ifax1.jp> CONNEG = OPTIONAL

     S: 250 <June@ifax1.jp> recipient ok

     C: DATA

     S: 354 okay, send data

     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
          Per "A Simple Mode of Facsimile Using Internet Mail"
          RFC2305
        >>

     S: 250 message accepted

     C: QUIT

     S: 221 goodbye



.   IANA CONSIDERATIONS

     On publicatiom of this document by the RFC Editor, the IANA
     shall register the Content_Negotiation ESMTP extension defined
     in section 3.



.   SECURITY CONSIDERATIONS

     This ESMTP option calls for a respondent to disclose
     its capabilities.  Mechanisms for determining the
     requestor's authenticated identity are outside the
     scope of this specification.  It is intended that this
     mechanism permit disclosure of public information;
     hence there is no particular need for security
     measures.

     However there is nothing to prevent disclosure of
     sensitive information that should receive restricted
     distribution.  It is, therefore, the responsibility of
     the disclosing ESMTP server to determine whether
     additional security measures should be applied to the
     use of this ESMTP option.

     A man-in-the-middle attack might change the capabilities reported
     for a given recipient. For example: Suppose the sender knows the
     recipient has the ability to view color documents so they mark
     some things in red in what is otherwise a black and white
     document. But someone interferes with the returned capabilities,
     indicating that the recipient only supports black and white. The
     document is duly downgraded, with the result that the recipient
     doesn't see what the sender marked.

     An indirect exposure can occur when the report of a capability
     implies use of specific software.  If that software is known to
     have security weaknesses, the capabilities report effectively
     advertises the associated opportunity to exploit the security
     weakness.

     For target SMTP servers that require security mechanisms to be in
     force at the start of the session, the target SHOULD refrain from
     including the CONNEG parameter in an EHLO response until the
     requisite security mechanisms are in force.

     For digitally signed content, the use of this option poses a
     special challenge.  Digitally signing content relies on that
     content to be in a particular form.  Use of this option changes
     that form.  Hence an SMTP client that uses this option on
     digitally signed content MUST be able to recompute the digital
     signature of the content.



 9.  ACKNOWLEDGEMENTS

     Graham Klyne provided useful suggestions to an earlier
     draft.



.  NORMATIVE REFERENCES

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

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

     [RFC2305] Toyoda, K., Ohno, H., Murai, J. and  D. Wing,
               "A Simple Mode of Facsimile Using Internet Mail",
               RFC 2305, March 1998.



.  AUTHORS' ADDRESSES

     Kiyoshi Toyoda
     Matsushita Graphic Communication Systems,Inc
     2-3-8 Shimomeguro, Meguro-Ku
     Tokyo 153  JAPAN

     +81.3.5434.7161
     ktoyoda@rdmg.mgcs.mei.co.jp


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

     +1.408.246.8253
     dcrocker@brandenburg.com



.  FULL COPYRIGHT STATEMENT

     Copyright (C) The Internet Society (2001).  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.   USAGE FOR MULTIPLE RECIPIENTS

     ESMTP permits specification of multiple recipients for the same
     content.  This option specified here can produce information that
     different recipients have different content capabilities.  How
     this differential information is used will depend upon the
     requirements of the sender.  This specification does not mandate
     particular choices. Three scenarios are possible:

     (1) Single Recipient

     For each recipient, conduct a separate ESMTP session.  This
     ensures that each content transfer can be tailored to the
     capabilities of each recipient.  This also consumes the largest
     amount of bandwidth and the largest number of cross-network SMTP
     protocol exchanges

     (2) Common Content

     For a single ESMTP session, issue RCPT commands that obtain
     content capabilities information for each recipient.  With the
     DATA command, send the best content form that can be processed by
     ALL of the recipients.  Some recipients will receive content that
     is below their best capabilities.  However this approach also
     consumes the least bandwidth and has the fewest cross-network
     protocol exchanges

     (3) Partial Batching

     This scenario begins the same as the "Common Content" scenario.
     Content capabilities information is obtained during a single ESMTP
     session, with all of the RCPT commands issued together.  The
     difference for this scenario is that the client SMTP then
     terminates the session with an RSET and begins one or more new,
     separate sessions.  Addressees are processed in batches, according
     to the similarity of their capabilities.  This option balances
     consumption of bandwidth with optimization of content, at the cost
     of a terminated session.


B.   SCENARIOS FOR RELAYING

     ESMTP is a direct transfer mechanism, using a single TCP
     connection.  It supports Internet mail store-and-forward through
     such characteristics as global addressing and ESMTP enforcement of
     global features.  Use of the ESMTP Conneg option is
     straightforward when the originating ESMTP client is able to
     directly connect to the destination ESMTP server.  The nature of
     this option is to return address-specific information that will
     affect content transmission.  Hence the use of this option in the
     presence of the in-direct effects of store-and-forward is not
     obvious.

     This Appendix discusses some styles of use for the ESMTP Conneg
     option when messages are being relayed.  The Appendix is intended
     only to provide discussion.  It is neither intended to be
     exhaustive nor restrictive.  Other scenarios are likely and
     encouraged.


B.1  Relay Server Modes

     The key challenge for use of the ESMTP Conneg option is the
     requirement the receiving ESMTP server be able to return
     capabilities on behalf of a target addressee.  This requirement
     translates into two, basic styles of operation for the receiving
     ESMTP server:

     (1) Server Knows Addressee Capabilities

     Here the receiving server has the necessary details about an
     addressee, at the time the sending server issues the RCPT
     response.  Typically, this information will be obtained through a
     direct, real-time query mechanism, either to a directory
     containing addressee information or to a service run directly on
     behalf of the individual addressee and possibly on the addressee's
     system.

     One form of query to the addressee's system is to stack a
     cascading sequence of ESMTP sessions and RCPT commands
     together, all the way to the destination ESMTP server. Although
     theoretically possible, this attempt to turn a multi-hop scenario
     into a real-time, pseudo-direct query is not practical.  It
     will most likely result in response delays for the RCPT command
     that are not acceptable, particularly over the public Internet.

     (2) Server Ensures Conversion

     Fundamental to the use of a capabilities exchange is the
     requirement that the receiver of capabilities information be able
     to convert content into a form that is more capable than the
     default form, when the receiver indicates that it can support the
     superior form.  That is, use of this option presumes that the
     sender is holding a "more capable" form of the content and will
     map it to a "less capable form" if the receiver does not support
     the superior form.

     Hence another style of relaying configuration is to have a relay
     SMTP respond to an RCPT capability query by indicating that it
     supports the most capable form.  The sender will pass the best
     version it can.  The receiver has then taken responsibility for
     performing later conversions, as necessary, to the next hop in the
     sequence.  That is, the receiving ESMTP server inherits the same
     level of responsibility already being held by the sending ESMTP
     client.

B.2  Some End-to-End Scenarios

     This section suggests methods of using ESMTP Conneg for achieving
     an end-to-end service that uses knowledge of recipient
     capabilities for modifying the content or the handling of the
     content.  This section is intended only to explore possible
     scenarios.  Others are feasible and likely. The choice of scenario
     to support will depend upon particular service policies chosen for
     a relay.  This specification provides no constraint or guidance
     about which policies to choose.

     (1) Basic Tranfer betweeen Organizations

     Again noting that alternative configurations and support
     environments are permitted, a simple example of combining the two
     modes of receiving server style can be helpful.  The scenario to
     consider is sending from one organization's email system to
     another organization's email system, across the Internet.

     This scenario presumes two, independent email services, one for
     each organization.  In this simple example, the user has a local
     ESMTP server and it talks with the organization's Internet email
     gateway.  Hence there are four ESMTP servers.  The originating
     server takes the message from the originating user.  It then
     relays the message to the originating organization's ESMTP
     gateway.  This gateway, in turn, relays the message to the
     destination organization's gateway, which finally delivers it to
     the recipient's server.

     In this simple example, the originating ESMTP server includes a
     CONNEG option on the RCPT command to the originating
     organization's Internet gateway and the gateway always responds
     that it supports the highest capabilities.  It is then given the
     most capable form of the content.

     The originating gateway then performs a RCPT CONNEG exchange with
     the destination organization's gateway.  This gateway can operate
     in the same "Ensure Conversion" mode as the originating gateway,
     or it can perform a real-time query about the addressee's
     capabilities.  The former mode defers resolving recipient
     capabilities until the final step.  The real-time query requires
     both that the query mechanism be timely, in order to avoid RCPT
     response delays, and that it be accurate, with correct information
     about the addressee.

     The final exchange is, of course, "direct".  The recipient's ESMTP
     server is presumed to have easy access to the necessary
     capabilities information.

     (2) Integration with Multipart/Alternative

     Basic support for Conneg will typically involve a Conneg client
     that has a single, high-quality version of content and then maps
     is "down" to the best quality that can be supported by the
     responding Conneg server.  That is, the sending system will do a
     conversion.  In another mode of operation the Conneg client
     already holds a number of different mappings of content at
     different levels of quality.  The client will use the Conneg
     response to choose the content quality that is "closest" to the
      capabilities of the receiver.

     MIME's Multipart/Alternative provides a means for a content
     originator to send a fixed set of content quality choices.  An
     ESMTP relay in the sequence can then choose to use Conneg as a
     means of selecting one of the alternatives to transmit, rather
     than transmitting the full set.  Such a scenario is particularly
     useful when the communication path changes from high-bandwidth to
     low.

     (3) Content Staging on Retrieval Server

     Rather than converting content to a lower quality, an ESMTP Conneg
     client might choose to use a Conneg response for choosing not to
     send the content directly.  It might, instead, remove the content
     from the message and store the content on a retrieval server (for
     access through HTTP, FTP or the like.)  It can then put a citation
     into the message, which points to the stored content.

     For the retrieval server, access security, as well as life-time
     management of the content on the retrieval server, should be
     considered. A full discussion of these considerations is out of
     the scope of this memo."

     (4) Alternate Addressing

     If an ESMTP Conneg client has access to multiple addresses for the
     same recipient, it might use Conneg to determine which is most
     capabable for particular content and send the content to that one.

     This scenario requires a number of infrastucture features for
     which there currently are no standards.