idnits 2.17.1 draft-rauschenbach-pop3-framework-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IMAP4' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC1939' is defined on line 189, but no explicit reference was found in the text == Unused Reference: 'RFC1734' is defined on line 192, but no explicit reference was found in the text == Unused Reference: 'RFC1731' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC1082' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'SKEY' is defined on line 205, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 1734 (Obsoleted by RFC 5034) ** Downref: Normative reference to an Unknown state RFC: RFC 1082 ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEY' Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Rauschenbach 3 Internet Draft GoodServer Corporation 4 draft-rauschenbach-pop3-framework-00.txt January 1997 5 Expires July 1997 7 POP3 Service Extensions 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 1. Abstract 30 This memo defines a framework for extending the POP3 service by 31 defining a means whereby a POP3 server can inform a client as to the 32 service extensions it supports. 34 2. Introduction 36 The Post Office Protocol version 3 (POP3) has been extremely 37 successful over the years. It is very possible that POP3's success 38 has been due to its simplicity and ease of implementation, especially 39 when compared to protocols such as IMAP4. 41 Unfortunately POP3 has been extremely slow to evolve. Modern 42 messaging features, such as hierarchical folder management, are 43 becoming "minimum requirements" for a mail system. POP3 postoffices 44 are unable to effectively implement new extensions without a service 45 extension framework similar to what RFC 1651 provided for SMTP. 47 This document aims to rectify the situation by providing a framework 48 for POP3 service extensions, while solidifying the POP3 extensions 49 that have been presented to date. It also provides an efficient 50 mechanism for feature interrogation. 52 3. Framework for POP3 Extensions 54 The framework for service extensions described in this memo consists 55 of: 57 (1) a new optional POP3 command (section 4) 59 (2) a registry of POP3 service extensions (section 5) 61 4. The XTND command 63 A POP3 client supporting POP3 service extensions may start a POP3 64 session by issuing the XTND command. If the POP3 server supports POP3 65 service extensions it will give a successful response, otherwise it 66 will give an error response. 68 4.1. Changes to RFC 1082 70 RFC 1082 introduced the optional XTND command. It implicitly stated 71 that the XTND command should be followed by at least one argument, 72 the first of which is the extended command. This syntax is hereby 73 refined to allow the XTND command without any parameters. 75 Additionally, RFC 1082 defines the XTND command as being valid only 76 in the TRANSACTION state. This requirement was being defined in terms 77 of the XTND BBOARDS [name] command, and is hereby relaxed for the 78 XTND command without parameters. Future extended commands may define 79 what transaction state they are allowed to execute in, which will 80 accomodate not only new commands but authentication mechanisms as 81 well. 83 4.2 Command Syntax 85 The syntax for this command, using the ABNF notation of RFC 822, is: 87 xtnd-cmd ::=3D "XTND" [xtnd-keyword *(xtnd-verb)] CR LF 89 xtnd-keyword ::=3D (ALPHA / DIGIT) * (ALPHA / DIGIT / "-") 91 xtnd-verb ::=3D 1* 95 4.3 Successful Response 97 If the POP3 server implements POP3 service extensions and is 98 therefore able to perform the XTND command without arguments, it will 99 return a multi-line response. This will consist of an initial +OK, 100 followed by a list of extended commands and optional command verbs, 101 and finally end with a line containing a termination octet and a 102 CRLF pair. Each line will contain at least one token (the command), 103 and may contain a second token (the command's supported verb). 105 4.4 Error Response 107 In the case of an error response, the POP3 client must assume that 108 the POP3 server does not support POP3 service extensions, and is only 109 guaranteed to support the mandatory commands defined in RFC 1939. The 110 POP3 client may then use the traditional hit-and-miss method for 111 determining what optional features are supported by the POP3 server, 112 by attempting each optional command and then continuing gracefully if 113 it is not supported. 115 5. Initial Registry 117 The initial registry of POP3 service extensions consists of these 118 entries: 120 Service Ext Keyword Verb Added Behavior 121 ------------- --------- ---------- ----------------------------- 122 APOP digest APOP defined in RFC 1939 123 Authenticate AUTH defined in RFC 1734 124 Extend XTND enumerates service extensions 125 Extend archive XTND ARCHIVE defined in RFC 1082 126 Extend bboards XTND BBOARDS defined in RFC 1082 127 Pass PASS defined in RFC 1939 128 Top TOP defined in RFC 1939 129 Unique id list UIDL defined in RFC 1939 130 User USER defined in RFC 1939 132 Any command that starts with "X-" refers to a local POP3 service 133 extension, and may not be registered as a service extension. 135 6. Usage Examples 137 (1) The following interaction: 139 S: +OK POP3 server ready 140 C: XTND 141 S: -ERR Unrecognized command 142 ... 144 indicates that the POP3 server does not support POP3 service 145 extensions, and only supports those POP3 commands which are 146 defined as mandatory in RFC 1939. 148 (2) The next two interactions: 150 S: +OK POP3 server ready 151 C: XTND 152 S: -ERR no such bboard 153 ... 155 S: +OK POP3 server ready 156 C: XTND BBOARDS 157 S: -ERR Command not supported in AUTHORIZATION state 158 ... 160 also indicate that the POP3 server does not support POP3 service 161 extensions, however the server has implemented RFC 1082 in part 162 or in whole. 164 (3) Finally, a POP3 server that does support POP3 service extensions 165 would act as follows: 167 S: +OK POP3 server ready 168 C: XTND 169 S: +OK Supported POP3 service extensions follow: 170 S: APOP 171 S: AUTH KERBEROS_V4 172 S: AUTH SKEY 173 S: PASS 174 S: TOP 175 S: UIDL 176 S: USER 177 S: XTND 178 S: XTND ARCHIVE 179 S: XTND BBOARDS 180 S: X-NNTP-GROUP 181 S: . 182 ... 184 7. References 186 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 187 4", RFC 1730, University of Washington, December 1994. 189 [RFC1939] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC 190 1939, TWG, May 1996. 192 [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, 193 Carnegie Mellon, December 1994. 195 [RFC1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 196 Carnegie Mellon, December 1994. 198 [RFC1082] Rose, M., "Post Office Protocol - Version 3 Extended 199 Service Offerings", RFC 1082, TWG, November 1988. 201 [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet 202 Text Messages", RFC 822, University of Delaware, August 203 1982. 205 [SKEY] Haller, Neil M., "The S/Key One-Time Password System", 206 Bellcore, Morristown, New Jersey, October 1993, 207 thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps 209 8. Author's Address: 211 David Rauschenbach 212 GoodServer Corporation 213 mailto:davidr@goodserver.com