From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001 From: Graham Wilson Date: Mon, 29 Nov 2004 16:40:04 +0000 Subject: Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file. svn path=/trunk/; revision=4013 --- RFC/rfc2177.txt | 227 -------------------------------------------------------- 1 file changed, 227 deletions(-) delete mode 100644 RFC/rfc2177.txt (limited to 'RFC/rfc2177.txt') diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt deleted file mode 100644 index ef28fad3..00000000 --- a/RFC/rfc2177.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -Network Working Group B. Leiba -Request for Comments: 2177 IBM T.J. Watson Research Center -Category: Standards Track June 1997 - - - IMAP4 IDLE command - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - The Internet Message Access Protocol [IMAP4] requires a client to - poll the server for changes to the selected mailbox (new mail, - deletions). It's often more desirable to have the server transmit - updates to the client in real time. This allows a user to see new - mail immediately. It also helps some real-time applications based on - IMAP, which might otherwise need to poll extremely often (such as - every few seconds). (While the spec actually does allow a server to - push EXISTS responses aysynchronously, a client can't expect this - behaviour and must poll.) - - This document specifies the syntax of an IDLE command, which will - allow a client to tell the server that it's ready to accept such - real-time updates. - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as described in RFC 2060 - [IMAP4]. - -3. Specification - - IDLE Command - - Arguments: none - - Responses: continuation data will be requested; the client sends - the continuation data "DONE" to end the command - - - -Leiba Standards Track [Page 1] - -RFC 2177 IMAP4 IDLE command June 1997 - - - - Result: OK - IDLE completed after client sent "DONE" - NO - failure: the server will not allow the IDLE - command at this time - BAD - command unknown or arguments invalid - - The IDLE command may be used with any IMAP4 server implementation - that returns "IDLE" as one of the supported capabilities to the - CAPABILITY command. If the server does not advertise the IDLE - capability, the client MUST NOT use the IDLE command and must poll - for mailbox updates. In particular, the client MUST continue to be - able to accept unsolicited untagged responses to ANY command, as - specified in the base IMAP specification. - - The IDLE command is sent from the client to the server when the - client is ready to accept unsolicited mailbox update messages. The - server requests a response to the IDLE command using the continuation - ("+") response. The IDLE command remains active until the client - responds to the continuation, and as long as an IDLE command is - active, the server is now free to send untagged EXISTS, EXPUNGE, and - other messages at any time. - - The IDLE command is terminated by the receipt of a "DONE" - continuation from the client; such response satisfies the server's - continuation request. At that point, the server MAY send any - remaining queued untagged responses and then MUST immediately send - the tagged response to the IDLE command and prepare to process other - commands. As in the base specification, the processing of any new - command may cause the sending of unsolicited untagged responses, - subject to the ambiguity limitations. The client MUST NOT send a - command while the server is waiting for the DONE, since the server - will not be able to distinguish a command from a continuation. - - The server MAY consider a client inactive if it has an IDLE command - running, and if such a server has an inactivity timeout it MAY log - the client off implicitly at the end of its timeout period. Because - of that, clients using IDLE are advised to terminate the IDLE and - re-issue it at least every 29 minutes to avoid being logged off. - This still allows a client to receive immediate mailbox updates even - though it need only "poll" at half hour intervals. - - - - - - - - - - - -Leiba Standards Track [Page 2] - -RFC 2177 IMAP4 IDLE command June 1997 - - - Example: C: A001 SELECT INBOX - S: * FLAGS (Deleted Seen) - S: * 3 EXISTS - S: * 0 RECENT - S: * OK [UIDVALIDITY 1] - S: A001 OK SELECT completed - C: A002 IDLE - S: + idling - ...time passes; new mail arrives... - S: * 4 EXISTS - C: DONE - S: A002 OK IDLE terminated - ...another client expunges message 2 now... - C: A003 FETCH 4 ALL - S: * 4 FETCH (...) - S: A003 OK FETCH completed - C: A004 IDLE - S: * 2 EXPUNGE - S: * 3 EXISTS - S: + idling - ...time passes; another client expunges message 3... - S: * 3 EXPUNGE - S: * 2 EXISTS - ...time passes; new mail arrives... - S: * 3 EXISTS - C: DONE - S: A004 OK IDLE terminated - C: A005 FETCH 3 ALL - S: * 3 FETCH (...) - S: A005 OK FETCH completed - C: A006 IDLE - -4. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. - Non-terminals referenced but not defined below are as defined by - [IMAP4]. - - command_auth ::= append / create / delete / examine / list / lsub / - rename / select / status / subscribe / unsubscribe - / idle - ;; Valid only in Authenticated or Selected state - - idle ::= "IDLE" CRLF "DONE" - - - - - - -Leiba Standards Track [Page 3] - -RFC 2177 IMAP4 IDLE command June 1997 - - -5. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - -6. Security Considerations - - There are no known security issues with this extension. - -7. Author's Address - - Barry Leiba - IBM T.J. Watson Research Center - 30 Saw Mill River Road - Hawthorne, NY 10532 - - Email: leiba@watson.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Leiba Standards Track [Page 4] - -- cgit v1.2.3