

Network Working Group                        K. Toyoda, MGCS
Internet Draft                       D. Crocker, Brandenburg
  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
Expires: May 2002



                   SMTP Service Extension
           for Content Negotiation of Internet Fax
     
     
     
     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.
     
     SUMMARY
     
     This document defines a content negotiation SMTP
     service extension [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.  This service
     extension is primarily intended for "direct" SMTP
     transfers, although relayed scenarios are permitted.



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



3.   CONNEG PARAMETER TO RCPT-TO
     
     Parameter:
          
          CONNEG
     
     Arguments:
          
          There are no arguments.
     
     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.
     
     Server Action:
          
          If the client specifies CONNEG 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 does support the CONNEG parameter,
     then it MUST issue a 250 reply, followed by its
     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 exact strings 
     are "250-2.1.5 CONNEG " and "250 2.1.5 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.
          
          The contents of the capability listing MUST
     conform to the specifications in "Content Feature
     Schema for Internet Fax". [RFC2879]



4.   SYNTAX
     
     Command with "CONNEG":
      "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
                   / Forward-Path) (SP "CONNEG") 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) )

      capability  =  <<as per [RFC2879]>>



5.   EXAMPLE
     

     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
     
     S: 250-<June@ifax1.jp> 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     (&(dpi=400)
     S: 250-CONNEG       (dpi-xyratio=1) ) )
     S: 250-CONNEG   (|(image-coding=[MH,MR,MMR])
     S: 250-CONNEG      (&(image-coding=JBIG)
     S: 250-CONNEG        (image-coding-constraint=JBIG-T85)
     S: 250-CONNEG        (JBIG-stripe-size=128) ) )
     S: 250-CONNEG   (paper-size=[letter,A4,B4])
     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
           )
        >>
     
     S: 250 message accepted
     
     C: QUIT
     
     S: 221 goodbye


     An example when CONNEG-capable server supports 
     ENHANCEDSTATUSCODES.
     

     S: 220 ifax1.jp IFAX
     
     C: EHLO ifax1.jp
     
     S: 250-ifax1.jp
     S: 250-DSN
     S: 250-ENHANCEDSTATUSCODES
     S: 250 CONNEG
          
     C: MAIL FROM:<May@ifax2.jp>
     
     S: 250 2.1.5<May@ifax2.jp> sender ok
     
     C: RCPT TO:<June@ifax1.jp> CONNEG
     
     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   (MRC-mode=0)
     S: 250-2.1.5 CONNEG   (color=Binary)
     S: 250-2.1.5 CONNEG   (|(&(dpi=204)
     S: 250-2.1.5 CONNEG       (dpi-xyratio=[204/98,204/196]) )
     S: 250-2.1.5 CONNEG     (&(dpi=200)
     S: 250-2.1.5 CONNEG       (dpi-xyratio=[200/100,1]) )
     S: 250-2.1.5 CONNEG     (&(dpi=400)
     S: 250-2.1.5 CONNEG       (dpi-xyratio=1) ) )
     S: 250-2.1.5 CONNEG   (|(image-coding=[MH,MR,MMR])
     S: 250-2.1.5 CONNEG      (&(image-coding=JBIG)
     S: 250-2.1.5 CONNEG        (image-coding-constraint=JBIG-T85)
     S: 250-2.1.5 CONNEG        (JBIG-stripe-size=128) ) )
     S: 250-2.1.5 CONNEG   (paper-size=[letter,A4,B4])
     S: 250 2.1.5 CONNEG   (ua-media=stationery) )
     


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



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



8.   ACKNOWLEDGEMENTS
     
     Graham Klyne provided useful suggestions to an earlier
     draft.



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



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



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


