Internet Draft Dan Wing August 26, 1997 Neil Joffe Expires February 1998 Cisco Systems, Inc. Capabilities Exchange over SMTP draft-wing-smtp-capabilities-00.txt Status of this memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document describes an extension to SMTP [RFC821] which provides a mechanism for capabilities exchange so the sender knows the capabilities of the ultimate recipient or the ESMTP server itself. 2. Introduction This memo defines a mechanism to allow an ESMTP client to determine the capabilities (such as viewers, word processors, and color support) and preferences (such language) of a recipient, which allows the ESMTP client to send a message in a format that is usable by the recipient. 2.1. CAPABILITIES Extension The CAPABILITIES extension permits an ESMTP client to easily obtain a recipient's capabilities. These capabilities can be used by the client Wing, Joffe Expires February 1998 [Page 1] Internet Draft Capabilities Exchange over ESMTP August 1997 to send a message that can be read by the recipient, or to inform the mail user agent that the recipient will be unable to read the message. The CAPS esmtp-keyword for the RCPT command causes the server to advertise recipient capabilities. These capabilities can be: (a) those of the actual recipient (if known through some database, LDAP query, querying the next MTA in the SMTP path, or another implementation-specific mechanism), or (b) the recipient's capabilities (from (a)), plus those capabilities the ESMTP server is willing to accept and translate to the recipient's capabilities (text/8bit to text/quoted-printable, for example). This memo uses the mechanism described in [SMTP-EXT] to define an extension to the SMTP protocol for indicating recipient's capabilities to the ESMTP client. 2.2. Discussion of this draft This draft is being discussed on the "ietf-fax" mailing list. To subscribe, send a message to: ietf-fax-request@imc.org with the line: subscribe in the body of the message. Archives are available from http://www.imc.org/ietf-fax. 2.3. Requirements notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [REQ]. 3. Framework for capabilities extension The following service extension is defined for capabilities exchange. (1) The name of the capabilities extension is Capabilities; (2) the EHLO keyword value associated with the capabilities extension is CAPABILITIES; Wing, Joffe Expires February 1998 [Page 2] Internet Draft Capabilities Exchange over ESMTP August 1997 (3) no parameters are allowed with this extension; (4) no new SMTP verbs are associated with this extension; (5) one optional parameter for the RCPT command, using the esmtp-keyword "CAPS", (used to request the capabilities of the recipient), is defined in section 4, no parameters are added to the MAIL command; (6) the maximum length of RCPT TO is increased by 5 characters. 4. Behavior of RCPT TO: CAPS A RCPT command issued by a client may contain the optional esmtp- keyword "CAPS" to indicate that the ESMTP client wishes to receive recipient capabilities information in the RCPT response from the ESMTP server. The server should be aware of the nature of the recipient via some implementation-specific method (LDAP or other directory query, contacting the destination system directly, or some other implementation-specific method). 4.1. Responses to RCPT TO esmtp-keyword CAPS The response to the esmtp-keyword CAPS on a RCPT TO command is a multiline reply, consisting of the standard SMTP reply, followed by recipient capabilities in the format specified by [HTTP-HEAD] and [HTTP-NEG]. The response should be split on multiple lines to not exceed the 512 character limit for a reply line as specified in [RFC821, SMTP-UPD]. The ESMTP server only needs to indicate capabilities if the ESMTP server is responding with a positive (2xx) reply. Non-positive replies don't need to include capabilities and such capabilities are to be ignored by the ESMTP client if they are present. The positive response, in [ABNF] form is: caps-response = "250" SP rcpt-response / ( "250-" SP rcpt-response CR LF *( "250-" http-line / ttl-caps CR LF ) "250" SP http-line / ttl-caps CR LF ) Wing, Joffe Expires February 1998 [Page 3] Internet Draft Capabilities Exchange over ESMTP August 1997 where "rcpt-response" is the normal response issued by the ESMTP server when it receives a valid forward-path. As time to live for these capabilities are not described in [HTTP-NEG], the following are defined: ttl-caps = "ttl=" ttl-seconds ttl-seconds = 1*DIGIT The purpose of is to indicate how long the list of capabilties should be considered an authoritative list of capabilities. The ttl is decremented by the ESMTP server for the length of time since the data was last refreshed. A ttl of 0 indicates the capabilities list is out-of-date but newer authoritative capabilities are not obtainable at this time. 4.2. ESMTP server unable to obtain capabilities If the ESMTP server receives a request for recipient capabilities but cannot determine the capabilities of the recipient for some reason, the ESMTP server may reply with: (1) ttl=0, or (2) an expired capabilities list and ttl=0 This allows the ESMTP client to: (a) abort the transaction, or (b) send whatever data it wishes (case 1, above), or (c) send data meeting the capabilities listed in (case 2, above). 5. Examples 5.1. Simple capabilities exchange S: 220 gw.cisco.com ESMTP service ready C: EHLO joffe-pc.cisco.com S: 250-gw.cisco.com says hello S: 250 CAPABILITIES C: MAIL FROM: S: 250 sender okay C: RCPT TO: CAPS S: 250- recipient ok S: 250-Accept: audio/basic S: 250-Accept: text/* S: 250-Accept: image/tiff;application=f, image/tiff;application=fx, Wing, Joffe Expires February 1998 [Page 4] Internet Draft Capabilities Exchange over ESMTP August 1997 application/octet-stream; q=0.2 S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4 S: 250-Accept-Features: pix-x=1728, res=204x196 S: 250 ttl=500 C: DATA ... 5.2. ESMTP server isn't able to obtain capabilities for recipient S: 220 gw.cisco.com ESMTP service ready C: EHLO wing-pc.cisco.com S: 250-gw.cisco.com says hello S: 250 CAPABILITIES C: MAIL FROM: S: 250 sender okay C: RCPT TO: CAPS S: 250 recipient ok C: DATA ... 5.3. ESMTP server can only obtain expired capabilities information S: 220 gw.cisco.com ESMTP service ready C: EHLO wing-pc.cisco.com S: 250-gw.cisco.com says hello S: 250 CAPABILITIES C: MAIL FROM: S: 250 sender okay C: RCPT TO: S: 250- recipient ok S: 250-Accept: text/* S: 250-Accept: application/ms-word, application/powerpoint S: 250 ttl=0 C: DATA ... 6. Security Considerations As detailed in [HTTP-NEG], Accept- headers, in particular Accept-Language headers, may reveal information which the user would rather keep private. For this reason it may be desirable to restrict externally-accessible information on user preferences and capabilities. 7. Acknowledgments This document was produced by work initially started in the Internet Fax Wing, Joffe Expires February 1998 [Page 5] Internet Draft Capabilities Exchange over ESMTP August 1997 Working Group. The authors would like to thank Graham Klyne (Integralis Ltd.) and Larry Masinter (Xerox PARC) for their contributions to this work. 8. References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", Internet Draft, Work in Progress, draft-ietf-drums-abnf-03.txt, July 1997. [HTTP-NEG] K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP", Internet Draft, Work In Progress, draft-ietf-http-negotiation-03.txt, July 1997. [HTTP-HEAD] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC821] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD-11, RFC 822, August 1982. [SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", STD-10, RFC 1869, November 1995. [SMTP-UPD] J. Klensin, D. Mann, "Simple Mail Transfer Protocol", Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-06.txt, July 30, 1997. 9. Author's Addresses Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Wing, Joffe Expires February 1998 [Page 6] Internet Draft Capabilities Exchange over ESMTP August 1997 Phone: +1 408 457 5200 Fax: +1 408 457 5208 EMail: dwing@cisco.com Neil Joffe Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 4000 Email: njoffe@cisco.com X1. Notes and unresolved issues X1.1. What is ESMTP server's action if client exceeds capabilities? Wing, Joffe Expires February 1998 [Page 7]