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.
Datatracker
Report a datatracker bug
draft-ietf-fax-esmtp-conneg-09
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4141.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |