< draft-leiba-imap-idle-00.txt		draft-leiba-imap-idle-01.txt >
	Network Working Group B. Leiba		Network Working Group B. Leiba
	Internet Draft IBM T.J. Watson Research Center		Internet Draft IBM T.J. Watson Research Center
	Document: draft-leiba-imap-idle-00.txt February 1997		Document: draft-leiba-imap-idle-01.txt February 1997
	IMAP4 IDLE command		IMAP4 IDLE command
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	The IDLE command is sent from the client to the server when the		The IDLE command is sent from the client to the server when the
	client is ready to accept unsolicited mailbox update messages. The		client is ready to accept unsolicited mailbox update messages. The
	server requests a response to the IDLE command using the continuation		server requests a response to the IDLE command using the continuation
	("+") response. The IDLE command remains active until the client		("+") response. The IDLE command remains active until the client
	responds to the continuation, and as long as an IDLE command is		responds to the continuation, and as long as an IDLE command is
	active, the server is now free to send untagged EXISTS, EXPUNGE, and		active, the server is now free to send untagged EXISTS, EXPUNGE, and
	other messages at any time.		other messages at any time.
	The IDLE command is terminated by the receipt of a "DONE" continuation		The IDLE command is terminated by the receipt of a "DONE" continuation
	from the client; such response satisfies the server's continuation		from the client; such response satisfies the server's continuation
	request. At that point, the server MUST immediately send the tagged		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.		response to the IDLE command and prepare to process other commands.
	As in the base specification, the processing of any new command may		As in the base specification, the processing of any new command may
	cause the sending of unsolicited untagged responses, subject to the		cause the sending of unsolicited untagged responses, subject to the
	ambiguity limitations.		ambiguity limitations.
	Internet DRAFT IDLE February 26, 1997		Internet DRAFT IDLE February 26, 1997
	The server MAY consider a client inactive if it has an IDLE command		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		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		the client off implicitly at the end of its timeout period. Because
End of changes. 2 change blocks.
	2 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/