home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-rauschenbach-pop3-framework-00.txt
< prev
next >
Wrap
Text File
|
1997-01-10
|
9KB
|
291 lines
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]