Network Working Group Dan Wing Internet Draft Neil Joffe November 3, 1997 Cisco Systems, Inc. Expires May 1998 SMTP Service Extension for Capabilities Exchange draft-ietf-fax-smtp-capabilities-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents .br 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), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Note: although this work has been discussed in the IETF-FAX working group, it does not purport to represent the consensus of the group. 0. Administrivia 0.1. Changes since previous versions Changes from draft-wing-smtp-capabilities-00.txt to draft-ietf-fax-smtp-capabilities-00.txt: * Filename changed from -wing- to -ietf-fax-. * More example methods to get recipient capabilities in section 2.1. * Reference fax requirements document and fax profile for internet mail document. 1. Abstract Wing, Joffe Expires May 1998 [Page 1] Internet Draft SMTP Capabilities Exchange November 1997 This document describes an extension to SMTP [SMTP] which provides a mechanism for capabilities exchange so the sender of a message can know selected capabilities of its ultimate recipient, or of the message transmission path to that recipient. 2. Introduction This memo defines a mechanism to allow an SMTP client to determine the capabilities (such as viewers, word processors, and color support) and preferences (such as language) of a recipient, which allows the SMTP client to send a message in a format that is usable by the recipient. This memo was motivated by an analysis of the requirements for using the Internet to deliver fax messages, described in [FAX-REQ] and [FAX-PROFILE]. While capabilities exchange is necessary for fax, it can be useful in other messaging scenerios such as delivery to cellular telephones via SMS, security [SMIME-40BIT], and to send normal messages that will be usable by the recipient. 2.1. CAPABILITIES Extension The CAPABILITIES extension permits an SMTP client to easily obtain a list of a recipient's capabilities. These capabilities can be used by the client to send a message that is known to be readable, processable, or understood 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 a mechanism such as [ACAP], [DIR-EMAIL], [DS-EMAIL], [SALUTATION], querying the next MTA in the SMTP path, or some other implementation-specific mechanism), or (b) the recipient's capabilities (from (a)), plus those capabilities the SMTP 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 SMTP client. 2.2. Discussion of this draft Wing, Joffe Expires May 1998 [Page 2] Internet Draft SMTP Capabilities Exchange November 1997 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [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; (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 SMTP client wishes to receive recipient capabilities information in the RCPT response from the SMTP 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, [DIR-EMAIL], or some other Wing, Joffe Expires May 1998 [Page 3] Internet Draft SMTP Capabilities Exchange November 1997 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 in section 6 and 8.2 of [HTTP-NEG] and section 14 of [HTTP-1.1]. 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 SMTP server only needs to indicate capabilities if the SMTP 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 SMTP client if they are present. The positive response, in [ABNF] form is: caps-response = rsp-code SP rcpt-response CR LF / ( rsp-code "-" rcpt-response CR LF 1*( rsp-code "-" caps-line CR LF ) rsp-code SP caps-line CR LF ) rsp-code = "2" 2DIGIT rcpt-response = caps-line = [status-code SP] features-line CR LF features-line = http-line / ( ttl-caps ttl-seconds ) status-code = of section 4 of [SMTP-ENH-ERR] if SMTP server implements [SMTP-ENH-ERR]> http-line = ttl-caps = "ttl=" ttl-seconds ttl-seconds = 1*DIGIT (XXX - ttl-caps and ttl-seconds aren't defined in [HTTP-NEG], but they should probably be moved there, as they're more appropriate there The purpose of is to indicate how long the list of capabilties should be considered an authoritative list of capabilities. The ttl is Wing, Joffe Expires May 1998 [Page 4] Internet Draft SMTP Capabilities Exchange November 1997 decremented by the SMTP 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. SMTP server unable to obtain capabilities If the SMTP server receives a request for recipient capabilities but cannot determine the capabilities of the recipient for some reason, the SMTP server may reply with: (1) ttl=0, or (2) an expired capabilities list and ttl=0 This allows the SMTP 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). 4.3. Behavior when client exceeds recipient's capabilities The SMTP server MAY verify that the SMTP client did not exceed the recipient capabilities advertised by the server. If the SMTP server determines that the SMTP client exceeded the advertised capabilities, the SMTP server can reject the message after the end-of-mail-data indicator. See the discussion in section 2.4.1 in [SMTP-UPD] for more information. 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/* Wing, Joffe Expires May 1998 [Page 5] Internet Draft SMTP Capabilities Exchange November 1997 S: 250-Accept: image/tiff;application=f, image/tiff;application=fx, 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 S: 354 Send your data ... 5.2. SMTP server isn't able to obtain capabilities for recipient S: 220 gw.cisco.com SMTP 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 S: 354 Send your data ... 5.3. SMTP server can only obtain expired capabilities information S: 220 gw.cisco.com SMTP 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 S: 354 Send your data ... 6. Security Considerations As detailed in section 14 of [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. Wing, Joffe Expires May 1998 [Page 6] Internet Draft SMTP Capabilities Exchange November 1997 7. Acknowledgments This document was produced by work initially started in the Internet Fax 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 [ACAP] J. Myers, C. Newman, "ACAP -- Application Configuration Access Protocol", Internet Draft, Work in Progress, draft-ietf-acap-spec-??.txt. [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", Internet Draft, Work in Progress, draft-ietf-drums-abnf-??.txt. [DIR-EMAIL] B. Greenblatt, "Directory Entries From Email Address", Internet Draft, Work in Progress, draft-greenblatt-defema-??.txt. [DS-EMAIL] P. Leach, "Locating DS Entries by E-mail Address", Internet Draft, Work in Progress, draft-leach-asid-ds-email-??.txt. [FAX-PROFILE] ?, "FAX Profile for Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-profile-??.txt [FAX-REQ] L. Masinter, "Requirements for Internet FAX", Internet Draft, Work in Progress, draft-ietf-fax-requirements-??.txt. [HTTP-1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [HTTP-NEG] K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP", Internet Draft, Work In Progress, draft-ietf-http-negotiation-??.txt. [REQ] Wing, Joffe Expires May 1998 [Page 7] Internet Draft SMTP Capabilities Exchange November 1997 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP-14, RFC 2119, March 1997. [SALUTATION] The Salutation Consortium, "Salutation Architecture Specification", December 1996. [SMIME-40BIT] Bruce Schneier, "Counterpane Systems Releases Windows 95-compatible S/MIME 40-bit RC2 Cracking ScreenSaver", http://www.counterpane.com/smime.html. [SMTP] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD-10, 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-??.txt. [SMTP-ENH-ERR] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. 9. Author's Addresses Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA 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 Wing, Joffe Expires May 1998 [Page 8] Internet Draft SMTP Capabilities Exchange November 1997 Wing, Joffe Expires May 1998 [Page 9]