Network Working Group David Rauschenbach Internet Draft GoodServer Corporation draft-rauschenbach-pop3-framework-00.txt January 1997 Expires July 1997 POP3 Service Extensions 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 memo defines a framework for extending the POP3 service by defining a means whereby a POP3 server can inform a client as to the service extensions it supports. 2. Introduction The Post Office Protocol version 3 (POP3) has been extremely successful over the years. It is very possible that POP3's success has been due to its simplicity and ease of implementation, especially when compared to protocols such as IMAP4. Unfortunately POP3 has been extremely slow to evolve. Modern messaging features, such as hierarchical folder management, are becoming "minimum requirements" for a mail system. POP3 postoffices are unable to effectively implement new extensions without a service extension framework similar to what RFC 1651 provided for SMTP. This document aims to rectify the situation by providing a framework for POP3 service extensions, while solidifying the POP3 extensions that have been presented to date. It also provides an efficient mechanism for feature interrogation. Rauschenbach [Page 1] draft-rauschenbach-pop3-framework-00.txt January 1997 3. Framework for POP3 Extensions The framework for service extensions described in this memo consists of: (1) a new optional POP3 command (section 4) (2) a registry of POP3 service extensions (section 5) 4. The XTND command A POP3 client supporting POP3 service extensions may start a POP3 session by issuing the XTND command. If the POP3 server supports POP3 service extensions it will give a successful response, otherwise it will give an error response. 4.1. Changes to RFC 1082 RFC 1082 introduced the optional XTND command. It implicitly stated that the XTND command should be followed by at least one argument, the first of which is the extended command. This syntax is hereby refined to allow the XTND command without any parameters. Additionally, RFC 1082 defines the XTND command as being valid only in the TRANSACTION state. This requirement was being defined in terms of the XTND BBOARDS [name] command, and is hereby relaxed for the XTND command without parameters. Future extended commands may define what transaction state they are allowed to execute in, which will accomodate not only new commands but authentication mechanisms as well. 4.2 Command Syntax The syntax for this command, using the ABNF notation of RFC 822, is: xtnd-cmd ::=3D "XTND" [xtnd-keyword *(xtnd-verb)] CR LF xtnd-keyword ::=3D (ALPHA / DIGIT) * (ALPHA / DIGIT / "-") xtnd-verb ::=3D 1* 4.3 Successful Response If the POP3 server implements POP3 service extensions and is therefore able to perform the XTND command without arguments, it will return a multi-line response. This will consist of an initial +OK, followed by a list of extended commands and optional command verbs, and finally end with a line containing a termination octet and a CRLF pair. Each line will contain at least one token (the command), and may contain a second token (the command's supported verb). Rauschenbach [Page 2] draft-rauschenbach-pop3-framework-00.txt January 1997 4.4 Error Response In the case of an error response, the POP3 client must assume that the POP3 server does not support POP3 service extensions, and is only guaranteed to support the mandatory commands defined in RFC 1939. The POP3 client may then use the traditional hit-and-miss method for determining what optional features are supported by the POP3 server, by attempting each optional command and then continuing gracefully if it is not supported. 5. Initial Registry The initial registry of POP3 service extensions consists of these entries: Service Ext Keyword Verb Added Behavior ------------- --------- ---------- ----------------------------- APOP digest APOP defined in RFC 1939 Authenticate AUTH defined in RFC 1734 Extend XTND enumerates service extensions Extend archive XTND ARCHIVE defined in RFC 1082 Extend bboards XTND BBOARDS defined in RFC 1082 Pass PASS defined in RFC 1939 Top TOP defined in RFC 1939 Unique id list UIDL defined in RFC 1939 User USER defined in RFC 1939 Any command that starts with "X-" refers to a local POP3 service extension, and may not be registered as a service extension. Rauschenbach [Page 3] draft-rauschenbach-pop3-framework-00.txt January 1997 6. Usage Examples (1) The following interaction: S: +OK POP3 server ready C: XTND S: -ERR Unrecognized command ... indicates that the POP3 server does not support POP3 service extensions, and only supports those POP3 commands which are defined as mandatory in RFC 1939. (2) The next two interactions: S: +OK POP3 server ready C: XTND S: -ERR no such bboard ... S: +OK POP3 server ready C: XTND BBOARDS S: -ERR Command not supported in AUTHORIZATION state ... also indicate that the POP3 server does not support POP3 service extensions, however the server has implemented RFC 1082 in part or in whole. (3) Finally, a POP3 server that does support POP3 service extensions would act as follows: S: +OK POP3 server ready C: XTND S: +OK Supported POP3 service extensions follow: S: APOP S: AUTH KERBEROS_V4 S: AUTH SKEY S: PASS S: TOP S: UIDL S: USER S: XTND S: XTND ARCHIVE S: XTND BBOARDS S: X-NNTP-GROUP S: . ... Rauschenbach [Page 4] draft-rauschenbach-pop3-framework-00.txt January 1997 7. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994. [RFC1939] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC 1939, TWG, May 1996. [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. [RFC1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, Carnegie Mellon, December 1994. [RFC1082] Rose, M., "Post Office Protocol - Version 3 Extended Service Offerings", RFC 1082, TWG, November 1988. [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", RFC 822, University of Delaware, August 1982. [SKEY] Haller, Neil M., "The S/Key One-Time Password System", Bellcore, Morristown, New Jersey, October 1993, thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps 8. Author's Address: David Rauschenbach GoodServer Corporation mailto:davidr@goodserver.com Rauschenbach [Page 5]