FM / rfc

/opt/cpanel/ea-libc-client/share/docs/rfc/

/opt/cpanel/ea-libc-client/share/docs/rfc

Name	Size	Mode	Actions
README	2337	0644	edit dl rm
rfc1732.txt	9276	0644	edit dl rm
rfc1733.txt	6205	0644	edit dl rm
rfc2061.txt	5867	0644	edit dl rm
rfc2062.txt	14042	0644	edit dl rm
rfc2087.txt	8542	0644	edit dl rm
rfc2088.txt	4052	0644	edit dl rm
rfc2177.txt	6770	0644	edit dl rm
rfc2180.txt	24750	0644	edit dl rm
rfc2193.txt	16248	0644	edit dl rm
rfc2195.txt	10468	0644	edit dl rm
rfc2221.txt	9251	0644	edit dl rm
rfc2342.txt	19489	0644	edit dl rm
rfc2683.txt	56300	0644	edit dl rm
rfc2971.txt	14670	0644	edit dl rm
rfc3348.txt	11868	0644	edit dl rm
rfc3501.txt	227638	0644	edit dl rm
rfc3502.txt	13379	0644	edit dl rm
rfc3503.txt	16937	0644	edit dl rm
rfc3516.txt	14598	0644	edit dl rm
rfc3656.txt	35509	0644	edit dl rm
rfc3691.txt	8436	0644	edit dl rm
rfc4314.txt	56599	0644	edit dl rm
rfc4315.txt	16629	0644	edit dl rm
rfc4422.txt	73206	0644	edit dl rm
rfc4466.txt	33752	0644	edit dl rm
rfc4467.txt	36714	0644	edit dl rm
rfc4468.txt	28614	0644	edit dl rm
rfc4469.txt	21822	0644	edit dl rm
rfc4505.txt	16599	0644	edit dl rm
rfc4549.txt	75417	0644	edit dl rm
rfc4551.txt	50265	0644	edit dl rm
rfc4616.txt	20270	0644	edit dl rm
rfc4731.txt	15431	0644	edit dl rm
rfc4752.txt	22133	0644	edit dl rm
rfc4790.txt	55591	0644	edit dl rm
rfc4959.txt	12284	0644	edit dl rm
rfc4978.txt	17554	0644	edit dl rm
rfc5032.txt	8921	0644	edit dl rm
rfc5051.txt	14965	0644	edit dl rm
rfc5092.txt	65197	0644	edit dl rm
rfc5161.txt	12220	0644	edit dl rm
rfc5162.txt	51620	0644	edit dl rm
rfc5234.txt	26359	0644	edit dl rm

Edit: /opt/cpanel/ea-libc-client/share/docs/rfc/rfc2177.txt (6770B)

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]

cmd: