From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001
From: Graham Wilson <graham@mknod.org>
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