Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_s_z/draft-wing-smtp-capabilities-00.txt

Text File | 1997-08-26 | 11KB | 391 lines

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:
     [e-mail]
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:<forward-path> 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 <ttl> 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:<[e-mail]>
  S: 250 <[e-mail]> sender okay
  C: RCPT TO:<[e-mail]> CAPS
  S: 250-<[e-mail]> 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:<[e-mail]>
  S: 250 <[e-mail]> sender okay
  C: RCPT TO:<[e-mail]> CAPS
  S: 250 <[e-mail]> 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:<[e-mail]>
  S: 250 <[e-mail]> sender okay
  C: RCPT TO:<[e-mail]>
  S: 250-<[e-mail]> 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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Neil Joffe
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706  USA

   Phone: [phone]
   Email: [e-mail]


X1.  Notes and unresolved issues

X1.1.  What is ESMTP server's action if client exceeds capabilities?


































Wing, Joffe              Expires February 1998                  [Page 7]