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 >
Text File  |  1997-01-10  |  9KB  |  291 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                 David Rauschenbach
  5. Internet Draft                                    GoodServer Corporation
  6. draft-rauschenbach-pop3-framework-00.txt                    January 1997
  7. Expires July 1997
  8.  
  9.  
  10.                            POP3 Service Extensions
  11.  
  12. Status of This Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its
  16.    areas, and its working groups.  Note that other groups may also
  17.    distribute working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six
  20.    months and may be updated, replaced, or obsoleted by other
  21.    documents at any time.  It is inappropriate to use Internet-
  22.    Drafts as reference material or to cite them other than as
  23.    ``work in progress.''
  24.  
  25.    To learn the current status of any Internet-Draft, please check
  26.    the ``1id-abstracts.txt'' listing contained in the Internet-
  27.    Drafts Shadow Directories on ftp.is.co.za (Africa),
  28.    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  29.    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  30.  
  31. 1. Abstract
  32.  
  33.    This memo defines a framework for extending the POP3 service by
  34.    defining a means whereby a POP3 server can inform a client as to the
  35.    service extensions it supports.
  36.  
  37. 2. Introduction
  38.  
  39.    The Post Office Protocol version 3 (POP3) has been extremely
  40.    successful over the years. It is very possible that POP3's success
  41.    has been due to its simplicity and ease of implementation, especially
  42.    when compared to protocols such as IMAP4.
  43.   
  44.    Unfortunately POP3 has been extremely slow to evolve. Modern
  45.    messaging features, such as hierarchical folder management, are
  46.    becoming "minimum requirements" for a mail system. POP3 postoffices
  47.    are unable to effectively implement new extensions without a service
  48.    extension framework similar to what RFC 1651 provided for SMTP.
  49.   
  50.    This document aims to rectify the situation by providing a framework
  51.    for POP3 service extensions, while solidifying the POP3 extensions
  52.    that have been presented to date. It also provides an efficient
  53.    mechanism for feature interrogation.
  54.  
  55. Rauschenbach                                                    [Page 1]
  56.  
  57. draft-rauschenbach-pop3-framework-00.txt                    January 1997
  58.  
  59.  
  60. 3. Framework for POP3 Extensions
  61.  
  62.    The framework for service extensions described in this memo consists
  63.    of:
  64.  
  65.       (1) a new optional POP3 command (section 4)
  66.      
  67.       (2) a registry of POP3 service extensions (section 5)
  68.  
  69. 4. The XTND command
  70.  
  71.    A POP3 client supporting POP3 service extensions may start a POP3
  72.    session by issuing the XTND command. If the POP3 server supports POP3
  73.    service extensions it will give a successful response, otherwise it
  74.    will give an error response.
  75.  
  76. 4.1. Changes to RFC 1082
  77.  
  78.    RFC 1082 introduced the optional XTND command. It implicitly stated
  79.    that the XTND command should be followed by at least one argument,
  80.    the first of which is the extended command. This syntax is hereby
  81.    refined to allow the XTND command without any parameters.
  82.   
  83.    Additionally, RFC 1082 defines the XTND command as being valid only
  84.    in the TRANSACTION state. This requirement was being defined in terms
  85.    of the XTND BBOARDS [name] command, and is hereby relaxed for the
  86.    XTND command without parameters. Future extended commands may define
  87.    what transaction state they are allowed to execute in, which will
  88.    accomodate not only new commands but authentication mechanisms as
  89.    well.
  90.  
  91. 4.2 Command Syntax
  92.  
  93.    The syntax for this command, using the ABNF notation of RFC 822, is:
  94.  
  95.       xtnd-cmd     ::=3D "XTND" [xtnd-keyword *(xtnd-verb)] CR LF
  96.      
  97.       xtnd-keyword ::=3D (ALPHA / DIGIT) * (ALPHA / DIGIT / "-")
  98.  
  99.       xtnd-verb    ::=3D 1*<any (US-ASCII) CHAR except SP and all =
  100. control
  101.                        characters (US-ASCII 0-31 inclusive)>
  102.  
  103. 4.3 Successful Response
  104.  
  105.    If the POP3 server implements POP3 service extensions and is
  106.    therefore able to perform the XTND command without arguments, it will
  107.    return a multi-line response. This will consist of an initial +OK,
  108.    followed by a list of extended commands and optional command verbs,
  109.    and finally end with a line containing a termination octet and a
  110.    CRLF pair. Each line will contain at least one token (the command),
  111.    and may contain a second token (the command's supported verb).
  112.  
  113.  
  114. Rauschenbach                                                    [Page 2]
  115.  
  116. draft-rauschenbach-pop3-framework-00.txt                    January 1997
  117.  
  118.  
  119. 4.4 Error Response
  120.  
  121.    In the case of an error response, the POP3 client must assume that
  122.    the POP3 server does not support POP3 service extensions, and is only
  123.    guaranteed to support the mandatory commands defined in RFC 1939. The
  124.    POP3 client may then use the traditional hit-and-miss method for
  125.    determining what optional features are supported by the POP3 server,
  126.    by attempting each optional command and then continuing gracefully if
  127.    it is not supported.
  128.  
  129. 5. Initial Registry
  130.  
  131.    The initial registry of POP3 service extensions consists of these
  132.    entries:
  133.   
  134.    Service Ext     Keyword   Verb       Added Behavior
  135.    -------------   --------- ---------- -----------------------------
  136.    APOP digest     APOP                 defined in RFC 1939
  137.    Authenticate    AUTH                 defined in RFC 1734
  138.    Extend          XTND                 enumerates service extensions
  139.    Extend archive  XTND      ARCHIVE    defined in RFC 1082
  140.    Extend bboards  XTND      BBOARDS    defined in RFC 1082
  141.    Pass            PASS                 defined in RFC 1939
  142.    Top             TOP                  defined in RFC 1939
  143.    Unique id list  UIDL                 defined in RFC 1939
  144.    User            USER                 defined in RFC 1939
  145.   
  146.    Any command that starts with "X-" refers to a local POP3 service
  147.    extension, and may not be registered as a service extension.
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172. Rauschenbach                                                    [Page 3]
  173.  
  174. draft-rauschenbach-pop3-framework-00.txt                    January 1997
  175.  
  176.  
  177. 6. Usage Examples
  178.  
  179.    (1)  The following interaction:
  180.   
  181.         S: +OK POP3 server ready
  182.         C: XTND
  183.         S: -ERR Unrecognized command
  184.         ...
  185.      
  186.         indicates that the POP3 server does not support POP3 service
  187.         extensions, and only supports those POP3 commands which are
  188.         defined as mandatory in RFC 1939.
  189.   
  190.    (2)  The next two interactions:
  191.   
  192.         S: +OK POP3 server ready
  193.         C: XTND
  194.         S: -ERR no such bboard
  195.         ...
  196.      
  197.         S: +OK POP3 server ready
  198.         C: XTND BBOARDS
  199.         S: -ERR Command not supported in AUTHORIZATION state
  200.         ...
  201.      
  202.         also indicate that the POP3 server does not support POP3 service
  203.         extensions, however the server has implemented RFC 1082 in part
  204.         or in whole.
  205.   
  206.    (3)  Finally, a POP3 server that does support POP3 service extensions
  207.         would act as follows:
  208.       
  209.         S: +OK POP3 server ready
  210.         C: XTND
  211.         S: +OK Supported POP3 service extensions follow:
  212.         S: APOP
  213.         S: AUTH KERBEROS_V4
  214.         S: AUTH SKEY
  215.         S: PASS
  216.         S: TOP
  217.         S: UIDL
  218.         S: USER
  219.         S: XTND
  220.         S: XTND ARCHIVE
  221.         S: XTND BBOARDS
  222.         S: X-NNTP-GROUP
  223.         S: .
  224.         ...
  225.  
  226.  
  227.  
  228.  
  229.  
  230. Rauschenbach                                                    [Page 4]
  231.  
  232. draft-rauschenbach-pop3-framework-00.txt                    January 1997
  233.  
  234.  
  235. 7. References
  236.  
  237.    [IMAP4]   Crispin, M., "Internet Message Access Protocol - Version
  238.              4", RFC 1730, University of Washington, December 1994.
  239.   
  240.    [RFC1939] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC
  241.              1939, TWG, May 1996.
  242.   
  243.    [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
  244.              Carnegie Mellon, December 1994.
  245.   
  246.    [RFC1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
  247.              Carnegie Mellon, December 1994.
  248.   
  249.    [RFC1082] Rose, M., "Post Office Protocol - Version 3 Extended
  250.              Service Offerings", RFC 1082, TWG, November 1988.
  251.   
  252.    [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
  253.              Text Messages", RFC 822, University of Delaware, August
  254.              1982.
  255.   
  256.    [SKEY]    Haller, Neil M., "The S/Key One-Time Password System",
  257.              Bellcore, Morristown, New Jersey, October 1993,
  258.              thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
  259.  
  260. 8. Author's Address:
  261.  
  262.    David Rauschenbach
  263.    GoodServer Corporation
  264.    mailto:davidr@goodserver.com
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288. Rauschenbach                                                    [Page 5]
  289.  
  290.  
  291.