idnits 2.17.1 draft-tornkvist-pop3-00.txt: 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-18) 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 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...fied by a PO...' == Line 15 has weird spacing: '...ment is an I...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... and may be...' == (36 more instances...) -- 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 (10 September 1998) is 9352 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Tornkvist 2 INTERNET-DRAFT SERC, Melbourne 3 Expires in six months 10 September 1998 4 6 Abstract 8 This memo describes an optional extension to the Post Office Protocol 9 version 3 (POP3), which introduces a possibility for a POP3 client to 10 be notified by a POP3 server whenever the clients maildrop is 11 accessed. 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Table of Contents 33 1. Introduction ................................................ 1 34 2. Operation ................................................... 2 35 3. NTFY sent by the client ..................................... 2 36 4. NTFY sent by the server ..................................... 3 37 5. Alteration to the RSET command .............................. 3 38 6. Alteration to the UPDATE state .............................. 4 39 7. Author's address ............................................ 4 41 1. Introduction 43 The Post Office Protocol version 3, as described in RFC 1939, is a 44 simple and low-cost method of enabling mail access. The host making 45 use of the POP3 service is referred to here as the "client", and the 46 host providing the service as the "server". When a client wants to 47 retrieve mail from a server he establish a TCP connection to the 48 server and then uses various POP3 commands to access the mail-drop. 49 Thus every time a client wants to check for new mail he has to poll 50 the server. For a mail-drop which seldom receives new mails this is 51 obvious not economical. It may also be a security issue since 52 repeated attempts to access the server are more vulnerable to 53 interception. This memo tries to remedy this by introducing the 54 concept of notification. This memo describes how a client can 55 request that the server notify the client when any changes have been 56 made to the clients mail-drop. 58 2. Operation 60 A new POP3 command named NTFY is added. It is used both by the client 61 and the server. When a client wants to be notified by the server he 62 sends a NTFY command together with a host name and port number. When 63 the client's mail-drop has been modified the server establishes a 64 connection to the specified host name and port number. The server 65 begin by sending a NTFY command together with the name of the mail- 66 drop. After this both the client and the server enter the 67 AUTHORIZATION state, as described in RFC 1939. Thus, the client has 68 to continue the exchange of commands to identify and authenticate 69 itself accordingly. 71 As soon as a server tries to establish a TCP connection to be used 72 for notification, it also removes the request for notification. It 73 is up to the client to issue a new NTFY command if he wants to be 74 notified again. The client can only issue the NTFY command in the 75 TRANSACTION state. 77 A request for notification will not be activated until the POP3 78 session enters the UPDATE state. During the TRANSACTION state it is 79 possible to cancel the request for notification by using the RSET 80 command. 82 3. NTFY sent by the client 84 This command can only be sent when the client is in the TRANSACTION 85 state. 87 NTFY hostname port-number 89 Arguments: 90 a hostname argument that fully specifies the host 91 to where the notification shall be delivered, and 92 a port number to be used 94 Restrictions: 95 may only be given in the TRANSACTION state 97 Discussion: 98 The POP3 server issues a positive response if requests 99 for notification can be serviced. However, the request 100 for notification will not be valid until the POP3 101 session enters the UPDATE state. 103 Possible Responses: 104 +OK 105 -ERR 107 Examples: 108 C: NTFY campari.rmit.edu.au 9411 109 S: +OK 111 4. NTFY sent by the server 113 When a client is to be notified about changes made to his mail-drop, 114 the server establish a TCP connection to the specified host and port 115 number. As soon this is done, the request for notification is erased 116 from the server. This is done regardless of if the connection was 117 successful or not. 119 NTFY name [timestamp] 121 Arguments: 122 a name specifying the mail-drop in question and 123 an optional timestamp if APOP authentication 124 is to be used 126 Restrictions: 127 only one attempt to contact the client will be made 129 Discussion: 130 As soon the server has sent this command, both the 131 client and the server are supposed to enter the 132 AUTHORIZATION state. 134 Examples: 135 S: NTFY pop5432 <1896.697170952@campari.rmit.edu.au> 137 5. Alteration to the RSET command 139 A server which support this extension shall erase a request for 140 notification as a result to the RSET command. 142 6. Alteration to the UPDATE state 144 A server which has received a request for notification shall not make 145 it valid until the UPDATE state has been entered. 147 7. Author's address 149 Torbjorn Tornkvist 150 SERC (Software Engineering Research Center) 151 110 Victoria St, Carlton 152 Victoria 3053 153 AUSTRALIA 155 Phone: +61 3 9925 4089 156 Fax: +61 3 9925 4094 157 Email: tobbe@serc.rmit.edu.au