[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
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*<any (US-ASCII) CHAR except SP and all =
control
                       characters (US-ASCII 0-31 inclusive)>

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]