Network Working Group                        K. Toyoda, MGCS
Internet Draft                       D. Crocker, Brandenburg
  draft-ietf-fax-esmtp-conneg-02.txt           June     2002
Expires: December 2002



                   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.


1.   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.  However direct email-based
     interactions are possible with proper configuration of the email
     originator and recipient servers, such as over an intranet.

     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 emulates a classic facsimile start-of-session
     capabilities negotiation, although it may be used for any email-
     based service.  This extension is primarily intended for "direct"
     SMTP transfers, although relayed scenarios are permitted through a
     series of SMTP servers.


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



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

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



4.   CONNEG PARAMETER TO RCPT-TO

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-TO command with a 504 reply.

            If the target can not support the capability due to a
            temporary problem, it MUST reject the RCPT-TO 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-TO.

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

     If the server rejects the RCPT-TO command with a 404 reply, the
     client may later reissue the RCPT-TO with the CONNEG parameter.

     If the server returns an EHLO 250 code without CONNEG
     capabilities, the client MUST work as "a Simple Mode of Facsimile
     Using Internet Mail" [RFC2305].


4.3 Server Action:

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

     If the target support the CONNEG parameter, but it can not return
     the recepient's capability temporarily, the target MUST reject the
     RCPT-TO command with a 404 reply. For example, if the target get
     the capability information from a directory, but its connection is
     offline, the target MUST reject the RCPT-TO command with a 404
     reply.

     If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the
     target 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 target does
     support the CONNEG parameter, then it MUST issue a 250 reply,
     followed by the capabilities of the target that is specified by
     the RCPT-TO address. Successful responses to CONNEG RCPT-TO
     requests will always be multiple SMTP lines.  The first line
     is the normal RCPT-TO 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, 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
     [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate
     services, such as the facsimile start-of-session capabilities
     negotiation as described in "Content Feature Schema for
     Internet Fax". [RFC2879]




5.   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 [RFC2506], [RFC2533], [RFC2534]
                    and [RFC2879] >>



6.   EXAMPLE

     An example of ESMTP sequence with successful RCPT-TO 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


     An example of successful RCPT-TO 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-TO 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) )


     An example of ESMTP sequence with parmanent failure RCPT-TO
     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



     An example of an ESMTP sequence with temporary failure RCPT-TO
     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



     An example of an ESMTP sequence with temporary failure RCPT-TO
     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



7.   IANA CONSIDERATIONS

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


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




9.   ACKNOWLEDGEMENTS

     Graham Klyne provided useful suggestions to an earlier
     draft.



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

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

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

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


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



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