[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-07.txt               May 2003
Expires: <11-03>


                   SMTP Service Extensions
                 For Fax 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 (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-types, to
     permit authorized, accountable content form conversion
     by intermediaries.



     CONTENTS

1.   Introduction
2.   Conventions
3.   Service Specification
     3.1. Sending Permission
     3.2. Returning Capabilities
     3.3. Next-Hop Non-Support of Service
4.   Content Conversion Permission SMTP Extension
     4.1. Content Conversion Permission Service Extension
          Definition
     4.2. CONPERM Parameter to Mail-From
     4.3. Syntax
5.   Content Negotiation SMTP extension
     5.1. Content Negotiation Service Extension Definition
     5.2. CONNEG parameter to RCPT-TO
     5.3. Syntax
6.   MIME Content-Convert Header
7.   MIME Content-Previous Header
8.   MIME Content-Features Header
9.   Examples
     9.1. CONPERM Negotiation
     9.2. Example CONNEG Negotiation
     9.3. Content-Previous
10.  IANA Considerations
11.  Security Considerations
12.  Acknowledgements
13.  References
14.  Authors' Addresses
15.  Full Copyright Statement
Appendix A:   CONNEG with Direct SMTP



1.   INTRODUCTION

     A message originator sometimes sends content in a form
     the recipient cannot process.   This specification
     enables MIME content conversion on behalf of a message
     originator and a message recipient. It defines a means
     of matching message content form to the capabilities of
     a recipient device or system, through an SMTP-based
     negotiation mechanism.  An SMTP client is given
     permission by an email originator, to request and use
     information about content capabilities of the target
     device or system that is serviced by an SMTP server.
     An SMTP server reports the target's content
     capabilities back to the SMTP client.  The client is
     then able to convert message content to a form that is
     supported by the target device or system.

     This specification provides mechanisms to support such
     a conversion service, through an ESMTP hop-by-hop
     service.  It uses two SMTP service extensions (CONPERM
     and CONNEG) and three MIME Content headers (Content-
     Convert, Content-Converted and Content-Features).

     An example email relay environment is shown here:

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

     SMTP host permission to perform specified content
     conversions is communicated by message senders, through
     the ESMTP CONPERM service extension and MIME Content-
     Convert headers.  Target device or system capabilities
     are communicated in SMTP sessions through the ESMTP
     CONNEG service extension.

     Conversions are performed by the first ESMTP host that
     can obtain both the sender's permission and the
     recipient's capabilities.   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.

     Note:  The specification does not provide for
            sending an MDN back to the originator, when a
            conversion is performed.  If there is no use
            of CONPERM/CONNEG, then conversions are
            performed by the recipient.  Therefore it is
            acceptable to ensure that the recipient, rather
            than the originator, is informed of conversions.
            This is achieved with Content-Previous and Content-
            Features.  Informing the Originator of conversions
            could generate a substantial increase in email
            control traffic.  Note that any conversion done by
            a recipient does not currently result in
            notification of the originator.

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



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

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

     The MIME headers occur in each MIME body-part to which
     they apply.  That is, each MIME body-part contains its
     own record of conversion permission and history.

     Originator Action:

          The originator MAY indicate authorization for
     intermediaries to perform conversions, by using the
     ESMTP CONPERM service extension when posting a new
     message. Authorized conversions MUST be specified in
     MIME Content-Convert headers, in each MIME body-part
     for which conversions are authorized.

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

                                           +-----------+
                                           | 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 send the
     original content to those recipients, via 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.


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


3.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 this
     specification, 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

     (4)  MUST add a Content-Previous header and a Content-
          Features header to each MIME body-part that has
          been converted.

     When performing conversions, the Client MUST either:

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

     (2)  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 sender

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


3.3.      Next-Hop Non-Support of Service

     If a Client is participating in this service, 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 this service 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
     to:

     (1)  Treat the addressee as a conversion failure, and

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



4.   CONTENT CONVERSION PERMISSION SMTP EXTENSION


4.1.      Content Conversion Permission Service Extension
          Definition

     (1)  The name of the SMTP service extension is

          "Content_Conversion_Permission"

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

          "CONPERM"

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

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


4.2.      CONPERM Parameter to Mail-From

     Parameter:

          CONPERM

     Arguments:

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


4.3.      Syntax

     Content_Conversion_Permission =    "CONPERM"



5.   CONTENT NEGOTIATION SMTP EXTENSION


5.1.      Content Negotiation Service Extension Definition

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

          "Content_Negotiation"

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


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

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


5.3.      Syntax

     Content_Negotiation =    "CONNEG"

     Capability =             <<as per [SYN, FAX]>>



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



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



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



9.   EXAMPLES


9.1.      CONPERM Negotiation

     S: 220 example.com IFAX
     C: EHLO example.com
     S: 250- example.com
     S: 250-DSN
     S: 250 CONPERM
     C: MAIL FROM:May@some.example.com CONPERM
     S: 250 <May@some.example.com> sender 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: image-tiff-fx
        Per:
        (  image-file-structure=TIFF-minimal
           dpi=400
           image-coding=JBIG
           size-x=2150/254
           paper-size=letter
        )
        with MIME body-parts including:
        Content-Convert:
           (&(image-file-structure=TIFF-minimal)
             (MRC-mode=0)
             (color=Binary)
             (|(&(dpi=204)
                 (dpi-xyratio=[204/98,204/196]) )
               (&(dpi=200)
                 (dpi-xyratio=[200/100,1]) )
               (&(dpi=400)
                 (dpi-xyratio=1) ) )
             (|(image-coding=[MH,MR,MMR])
               (&(image-coding=JBIG)
                 (image-coding-constraint=JBIG-T85)
                 (JBIG-stripe-size=128) ) )
             (size-x<=2150/254)
             (paper-size=[letter,A4])
             (ua-media=stationery) )
        >>
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye


9.2.      Example CONNEG Negotiation

     S: 220 example.com IFAX
     C: EHLO example.com
     S: 250- example.com
     S: 250-DSN
     S: 250 CONNEG
     C: MAIL FROM:<May@some.example.com>
     S: 250 <May@some.example.com> sender 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: image/tiff-fx
          Per:
          (  image-file-structure=TIFF-minimal
             dpi=200
             image-coding=MMR
             size-x=2150/254
             paper-size=letter
           )
        >>
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye


9.3.      Content-Previous

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



10.  IANA CONSIDERATIONS

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



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

     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 or disclosing ESMTP client
     to determine whether additional security measures
     should be applied to the use of this ESMTP option.



12.  ACKNOWLEDGEMENTS

     Graham Klyne and Eric Burger provided extensive,
     diligent reviews and suggestions.



13.  REFERENCES

     Normative:

     [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



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



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

     The figure below shows these relationships:

      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/