As per Relevance of the word response, we have this rfc below:
Network Working Group B.
Request for Comments: 2177 IBM T.J. Watson Research
Category: Standards Track June 1997
IMAP4 IDLE
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
The Internet Message Access Protocol [IMAP4] requires a client
poll the server for changes to the selected mailbox (new mail
deletions). It's often more desirable to have the server
updates to the client in real time. This allows a user to see
mail immediately. It also helps some real-time applications based
IMAP, which might otherwise need to poll extremely often (such
every few seconds). (While the spec actually does allow a server
push EXISTS responses aysynchronously, a client can't expect
behaviour and must poll.)
This document specifies the syntax of an IDLE command, which
allow a client to tell the server that it's ready to accept
real-time updates
2. Conventions Used in this
In examples, "C:" and "S:" indicate lines sent by the client
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.
IDLE
Arguments:
Responses: continuation data will be requested; the client
the continuation data "DONE" to end the
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
command at this
BAD - command unknown or arguments
The IDLE command may be used with any IMAP4 server
that returns "IDLE" as one of the supported capabilities to
CAPABILITY command. If the server does not advertise the
capability, the client MUST NOT use the IDLE command and must
for mailbox updates. In particular, the client MUST continue to
able to accept unsolicited untagged responses to ANY command,
specified in the base IMAP specification
The IDLE command is sent from the client to the server when
client is ready to accept unsolicited mailbox update messages.
server requests a response to the IDLE command using the
("+") response. The IDLE command remains active until the
responds to the continuation, and as long as an IDLE command
active, the server is now free to send untagged EXISTS, EXPUNGE,
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'
continuation request. At that point, the server MAY send
remaining queued untagged responses and then MUST immediately
the tagged response to the IDLE command and prepare to process
commands. As in the base specification, the processing of any
command may cause the sending of unsolicited untagged responses
subject to the ambiguity limitations. The client MUST NOT send
command while the server is waiting for the DONE, since the
will not be able to distinguish a command from a continuation
The server MAY consider a client inactive if it has an IDLE
running, and if such a server has an inactivity timeout it MAY
the client off implicitly at the end of its timeout period.
of that, clients using IDLE are advised to terminate the IDLE
re-issue it at least every 29 minutes to avoid being logged off
This still allows a client to receive immediate mailbox updates
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
S: * FLAGS (Deleted Seen
S: * 3
S: * 0
S: * OK [UIDVALIDITY 1]
S: A001 OK SELECT
C: A002
S: +
...time passes; new mail arrives...
S: * 4
C:
S: A002 OK IDLE
...another client expunges message 2 now...
C: A003 FETCH 4
S: * 4 FETCH (...)
S: A003 OK FETCH
C: A004
S: * 2
S: * 3
S: +
...time passes; another client expunges message 3...
S: * 3
S: * 2
...time passes; new mail arrives...
S: * 3
C:
S: A004 OK IDLE
C: A005 FETCH 3
S: * 3 FETCH (...)
S: A005 OK FETCH
C: A006
4. Formal
The following syntax specification uses the augmented Backus-
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined
[IMAP4].
command_auth ::= append / create / delete / examine / list / lsub /
rename / select / status / subscribe /
/
;; Valid only in Authenticated or Selected
idle ::= "IDLE" CRLF "DONE
Leiba Standards Track [Page 3]
RFC 2177 IMAP4 IDLE command June 1997
5.
[IMAP4] Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, December 1996.
6. Security
There are no known security issues with this extension
7. Author's
Barry
IBM T.J. Watson Research
30 Saw Mill River
Hawthorne, NY 10532
Email: leiba@watson.ibm.
Leiba Standards Track [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
