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