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:<forward-path> 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 = <normal response to RCPT command by this SMTP server
in the absence of the esmtp-keyword CAPABILITIES>
caps-line = [status-code SP] features-line CR LF
features-line = http-line / ( ttl-caps ttl-seconds )
status-code = <This is <status-code> of section 4 of [SMTP-ENH-ERR]
if SMTP server implements [SMTP-ENH-ERR]>
http-line = <Accept-Features, as described in [HTTP-NEG]>
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 <ttl> 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:<njoffe@cisco.com>
S: 250 <njoffe@cisco.com> sender okay
C: RCPT TO:<masinter@parc.xerox.com> CAPS
S: 250-<masinter@parc.xerox.com> 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:<dwing@cisco.com>
S: 250 <dwing@cisco.com> sender okay
C: RCPT TO:<adelman@adelman.com> CAPS
S: 250 <adelman@adelman.com> 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:<dwing@cisco.com>
S: 250 <dwing@cisco.com> sender okay
C: RCPT TO:<benefits@cisco.com>
S: 250-<benefits@cisco.com> 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]
