< draft-gahrns-imap-practice-00.txt		draft-gahrns-imap-practice-01.txt >
	Network Working Group M. Gahrns		Network Working Group M. Gahrns
	Internet Draft Microsoft		Internet Draft Microsoft
	Document: draft-gahrns-imap-practice-00.txt March 1997		Document: draft-gahrns-imap-practice-01.txt April 1997
	IMAP4 Implementation Practice		IMAP4 Multi-Accessed Mailbox Practice
	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.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by		months. Internet Drafts may be updated, replaced, or obsoleted by
	skipping to change at line 29 ¶		skipping to change at line 29 ¶
	"working draft" or "work in progress".		"working draft" or "work in progress".
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		1id-abstracts.txt listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or		Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
	munnari.oz.au.		munnari.oz.au.
	A revised version of this draft document will be submitted to the		A revised version of this draft document will be submitted to the
	RFC editor as a Proposed Standard for the Internet Community.		RFC editor as a Proposed Standard for the Internet Community.
	Discussion and suggestions for improvement are requested. This		Discussion and suggestions for improvement are requested. This
	document will expire before September 1997. Distribution of this		document will expire before October 1997. Distribution of this draft
	draft is unlimited.		is unlimited.
	1. Abstract		1. Abstract
	IMAP4[rfc2060] is rich client/server protocol that allows a client		IMAP4[rfc2060] is rich client/server protocol that allows a client
	to access and manipulate electronic mail messages on a server.		to access and manipulate electronic mail messages on a server.
	Within the protocol framework, it is possible to have differing		Within the protocol framework, it is possible to have differing
	results for particular client/server interactions. If a protocol		results for particular client/server interactions. If a protocol
	does not allow for this, it is often unduly restrictive.		does not allow for this, it is often unduly restrictive.
	For example, when multiple clients are accessing a mailbox and one		For example, when multiple clients are accessing a mailbox and one
	skipping to change at line 54 ¶		skipping to change at line 54 ¶
	With this flexibility comes greater client responsibility. It is		With this flexibility comes greater client responsibility. It is
	not sufficient for a client to be written based upon the behavior of		not sufficient for a client to be written based upon the behavior of
	a particular IMAP server. Rather the client must be based upon the		a particular IMAP server. Rather the client must be based upon the
	behavior allowed by the protocol.		behavior allowed by the protocol.
	By documenting common IMAP4 server practice for the case of		By documenting common IMAP4 server practice for the case of
	simultaneous client access to a mailbox, we hope to ensure the		simultaneous client access to a mailbox, we hope to ensure the
	widest amount of inter-operation between IMAP4 clients and servers.		widest amount of inter-operation between IMAP4 clients and servers.
			Gahrns 1
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	The behavior described in this document reflects the practice of		The behavior described in this document reflects the practice of
	some existing servers or behavior that the consensus of the IMAP		some existing servers or behavior that the consensus of the IMAP
	mailing list has deemed to be reasonable. The behavior described		mailing list has deemed to be reasonable. The behavior described
	within this document is believed to be [RFC2060] compliant. However,		within this document is believed to be [RFC2060] compliant. However,
	this document is not meant to define IMAP4 compliance, nor is it and		this document is not meant to define IMAP4 compliance, nor is it and
	exhaustive list of valid IMAP4 behavior. [RFC2060] must always be		exhaustive list of valid IMAP4 behavior. [RFC2060] must always be
	consulted to determine IMAP4 compliance, especially for server		consulted to determine IMAP4 compliance, especially for server
	behavior not described within this document.		behavior not described within this document.
	2. Conventions used in this document		2. Conventions used in this document
	skipping to change at line 75 ¶		skipping to change at line 78 ¶
	In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3		In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3
	different clients (client #1, client #2 and client #3) that are		different clients (client #1, client #2 and client #3) that are
	connected to a server. "S1:", "S2:" and "S3:" indicated lines sent		connected to a server. "S1:", "S2:" and "S3:" indicated lines sent
	by the server to client #1, client #2 and client #3 respectively.		by the server to client #1, client #2 and client #3 respectively.
	A shared mailbox, is a mailbox that can be used by multiple users.		A shared mailbox, is a mailbox that can be used by multiple users.
	A multi-accessed mailbox, is a mailbox that has multiple clients		A multi-accessed mailbox, is a mailbox that has multiple clients
	simultaneously accessing it.		simultaneously accessing it.
	A client is said have accessed a mailbox after a successful SELECT		A client is said to have accessed a mailbox after a successful
	or EXAMINE command.		SELECT or EXAMINE command.
	SHOULD and MAY are terms that are defined in accordance with [RFC-		SHOULD and MAY are terms that are defined in accordance with [RFC-
	2060].		2060].
	3. Deletion/Renaming of a multi-accessed mailbox		3. Deletion/Renaming of a multi-accessed mailbox
	When multiple clients are accessing a mailbox, care must be taken		If an external agent or multiple clients are accessing a mailbox,
	when handling the deletion or renaming of the mailbox by one of the		care must be taken when handling the deletion or renaming of the
	clients. Following are some strategies an IMAP server may choose to		mailbox. Following are some strategies an IMAP server may choose to
	use when dealing with this.		use when dealing with this.
	3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed		3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
	mailbox		mailbox
	In some cases, this behavior may not be practical. For example, if		In some cases, this behavior may not be practical. For example, if
	a large number of clients are accessing a shared mailbox, the window		a large number of clients are accessing a shared mailbox, the window
	in which no clients have the mailbox accessed may be small or non-		in which no clients have the mailbox accessed may be small or non-
	existent, effectively rendering the mailbox undeletable or		existent, effectively rendering the mailbox undeletable or
	unrenamable.		unrenamable.
	Example:		Example:
	<Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries		<Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
	to DELETE the mailbox and is refused>		to DELETE the mailbox and is refused>
	C1: A001 DELETE FOO		C1: A001 DELETE FOO
	S1: A001 NO Mailbox FOO is in use by another user.		S1: A001 NO Mailbox FOO is in use by another user.
			Gahrns 2
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	3.2. The server MAY allow the DELETE command of a multi-accessed		3.2. The server MAY allow the DELETE command of a multi-accessed
	mailbox, but keep the information in the mailbox available for		mailbox, but keep the information in the mailbox available for
	those clients that currently have access to the mailbox.		those clients that currently have access to the mailbox.
	When all clients have finished accessing the mailbox, it is		When all clients have finished accessing the mailbox, it is
	permanently removed. For clients that do not already have access to		permanently removed. For clients that do not already have access to
	the mailbox, the 'ghosted' mailbox would not be available. For		the mailbox, the 'ghosted' mailbox would not be available. For
	example, it would not be returned to these clients in a subsequent		example, it would not be returned to these clients in a subsequent
	LIST or LSUB command and would not be a valid mailbox argument to		LIST or LSUB command and would not be a valid mailbox argument to
	any other IMAP command until the reference count of clients		any other IMAP command until the reference count of clients
	accessing the mailbox reached 0.		accessing the mailbox reached 0.
	In some cases, this behavior may not be desirable. For example if		In some cases, this behavior may not be desirable. For example if
	someone created a mailbox with offensive or sensitive information,		someone created a mailbox with offensive or sensitive information,
	one might prefer to have the mailbox deleted and all access to the		one might prefer to have the mailbox deleted and all access to the
	information contained within removed immediately, rather than		information contained within removed immediately, rather than
	continuing to allow access until the client closes the mailbox.		continuing to allow access until the client closes the mailbox.
	Furthermore, this behavior, prevents 'recycling' of the same mailbox		Furthermore, this behavior, may prevent 'recycling' of the same
	name until all clients have finished accessing the original mailbox.		mailbox name until all clients have finished accessing the original
			mailbox.
	Example:		Example:
	<Client #1 and Client #2 have mailbox FOO accessed. Client #1		<Client #1 and Client #2 have mailbox FOO accessed. Client #1
	DELETEs mailbox FOO>		DELETEs mailbox FOO>
	C1: A001 DELETE FOO		C1: A001 DELETE FOO
	S1: A001 OK Mailbox FOO is deleted.		S1: A001 OK Mailbox FOO is deleted.
	<Client #2 is still able to operate on the deleted mailbox>		<Client #2 is still able to operate on the deleted mailbox>
	skipping to change at line 156 ¶		skipping to change at line 163 ¶
	<Nor is client #3 able to create a mailbox with the name FOO, while		<Nor is client #3 able to create a mailbox with the name FOO, while
	the reference count is non zero>		the reference count is non zero>
	C3: C002 CREATE FOO		C3: C002 CREATE FOO
	S3: C002 NO Mailbox FOO is still in use. Try again later.		S3: C002 NO Mailbox FOO is still in use. Try again later.
	<Client #2 closes its access to the mailbox, no other clients have		<Client #2 closes its access to the mailbox, no other clients have
	access to the mailbox FOO and reference count becomes 0>		access to the mailbox FOO and reference count becomes 0>
	C2: B002 CLOSE		C2: B002 CLOSE
			Gahrns 3
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	S2: B002 OK CLOSE Completed		S2: B002 OK CLOSE Completed
	<Now that the reference count on FOO has reached 0, the mailbox name		<Now that the reference count on FOO has reached 0, the mailbox name
	can be recycled>		can be recycled>
	C3: C003 CREATE FOO		C3: C003 CREATE FOO
	S3: C003 OK CREATE Completed		S3: C003 OK CREATE Completed
	3.3. The server MAY allow the DELETE/RENAME of a multi-accessed		3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
	mailbox, but disconnect all other clients who have the mailbox		mailbox, but disconnect all other clients who have the mailbox
	accessed by sending a untagged BYE response.		accessed by sending a untagged BYE response.
	skipping to change at line 205 ¶		skipping to change at line 217 ¶
	<Client #1 and Client #2 have mailbox FOO accessed. Client #1		<Client #1 and Client #2 have mailbox FOO accessed. Client #1
	RENAMEs the mailbox.>		RENAMEs the mailbox.>
	C1: A001 RENAME FOO BAR		C1: A001 RENAME FOO BAR
	S1: A001 OK RENAME completed.		S1: A001 OK RENAME completed.
	<Client #2 is still able to do operations that do not reference the		<Client #2 is still able to do operations that do not reference the
	mailbox name>		mailbox name>
			Gahrns 4
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	C2: B001 FETCH 2:4 (FLAGS)		C2: B001 FETCH 2:4 (FLAGS)
	S2: * 2 FETCH . . .		S2: * 2 FETCH . . .
	S2: * 3 FETCH . . .		S2: * 3 FETCH . . .
	S2: * 4 FETCH . . .		S2: * 4 FETCH . . .
	S2: B001 OK FETCH completed		S2: B001 OK FETCH completed
	<Client #2 is not able to do operations that reference the mailbox		<Client #2 is not able to do operations that reference the mailbox
	name>		name>
	C2: B002 STATUS FOO (MESSAGES)		C2: B002 STATUS FOO (MESSAGES)
	S2: B002 NO [NEWNAME FOO BAR] Mailbox has been renamed		S2: B002 NO [NEWNAME FOO BAR] Mailbox has been renamed
	4. Expunging of messages on a multi-accessed mailbox		4. Expunging of messages on a multi-accessed mailbox
	When multiple clients are accessing a mailbox, care must be taken		If an external agent or multiple clients are accessing a mailbox,
	when handling the EXPUNGE of messages. Other clients accessing the		care must be taken when handling the EXPUNGE of messages. Other
	mailbox may be in the midst of issuing a command that depends upon		clients accessing the mailbox may be in the midst of issuing a
	message sequence numbers. Because an EXPUNGE response can not be		command that depends upon message sequence numbers. Because an
	sent while responding to a FETCH, STORE or SEARCH command, it is not		EXPUNGE response can not be sent while responding to a FETCH, STORE
	possible to immediately notify the client of the EXPUNGE. This can		or SEARCH command, it is not possible to immediately notify the
	result in ambiguity if the client issues a FETCH, STORE or SEARCH		client of the EXPUNGE. This can result in ambiguity if the client
	operation on a message that has been EXPUNGED.		issues a FETCH, STORE or SEARCH operation on a message that has been
			EXPUNGED.
	4.1. Fetching of EXPUNGED messages		4.1. Fetching of expunged messages
	Following are some strategies an IMAP server may choose to use when		Following are some strategies an IMAP server may choose to use when
	dealing with a FETCH command on expunged messages.		dealing with a FETCH command on expunged messages.
	Consider the following scenario:		Consider the following scenario:
	- Client #1 and Client #2 have mailbox FOO selected.		- Client #1 and Client #2 have mailbox FOO selected.
	- There are 7 messages in the mailbox.		- There are 7 messages in the mailbox.
	- Messages 4:7 are marked for deletion.		- Messages 4:7 are marked for deletion.
	- Client #1 issues an EXPUNGE, to expunge messages 4:7		- Client #1 issues an EXPUNGE, to expunge messages 4:7
	skipping to change at line 252 ¶		skipping to change at line 268 ¶
	until it is able to send an EXPUNGE response to each client.		until it is able to send an EXPUNGE response to each client.
	In some cases, the behavior of keeping "ghosted" messages may not be		In some cases, the behavior of keeping "ghosted" messages may not be
	desirable. For example if a message contained offensive or		desirable. For example if a message contained offensive or
	sensitive information, one might prefer to instantaneously remove		sensitive information, one might prefer to instantaneously remove
	all access to the information, regardless of whether another client		all access to the information, regardless of whether another client
	is in the midst of accessing it.		is in the midst of accessing it.
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
			Gahrns 5
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	<Client #2 is still able to access the expunged messages because the		<Client #2 is still able to access the expunged messages because the
	server has kept a 'ghosted' copy of the messages until it is able to		server has kept a 'ghosted' copy of the messages until it is able to
	notify client #2 of the EXPUNGE>		notify client #2 of the EXPUNGE>
	C2: B001 FETCH 4:7 RFC822		C2: B001 FETCH 4:7 RFC822
	S2: * 4 FETCH RFC822 . . . (RFC822 info returned)		S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
	S2: * 5 FETCH RFC822 . . . (RFC822 info returned)		S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
	S2: * 6 FETCH RFC822 . . . (RFC822 info returned)		S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
	S2: * 7 FETCH RFC822 . . . (RFC822 info returned)		S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
	S2: B001 OK FETCH Completed		S2: B001 OK FETCH Completed
	<Client #2 issues a command where it can get notified of the		<Client #2 issues a command where it can get notified of the
	EXPUNGE>		EXPUNGE>
	skipping to change at line 278 ¶		skipping to change at line 298 ¶
	S2: * 4 EXPUNGE		S2: * 4 EXPUNGE
	S2: * 4 EXPUNGE		S2: * 4 EXPUNGE
	S2: * 3 EXISTS		S2: * 3 EXISTS
	S2: B002 OK NOOP Complete		S2: B002 OK NOOP Complete
	<Client #2 no longer has access to the expunged messages>		<Client #2 no longer has access to the expunged messages>
	C2: B003 FETCH 4:7 RFC822		C2: B003 FETCH 4:7 RFC822
	S2: B003 NO Messages 4:7 are no longer available.		S2: B003 NO Messages 4:7 are no longer available.
	4.1.2 The server MAY allow the EXPUNGE of a multi-access mailbox,		4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
	and on subsequent FETCH commands return a tagged NO, and FETCH		and on subsequent FETCH commands return FETCH responses only for
	responses only for the non-expunged messages.		non-expunged messages and a tagged NO.
	If all of the messages in the subsequent FETCH command have been
	expunged, the server SHOULD return only a tagged NO.
	After receiving a tagged NO FETCH response, the client SHOULD issue		After receiving a tagged NO FETCH response, the client SHOULD issue
	a NOOP command so that it will be informed of any pending EXPUNGE		a NOOP command so that it will be informed of any pending EXPUNGE
	responses. The client may then either reissue the failed FETCH		responses. The client may then either reissue the failed FETCH
	command, or by examining the EXPUNGE response from the NOOP and the		command, or by examining the EXPUNGE response from the NOOP and the
	FETCH response from the FETCH, determine that the FETCH failed		FETCH response from the FETCH, determine that the FETCH failed
	because of pending expunges.		because of pending expunges.
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
	skipping to change at line 305 ¶		skipping to change at line 322 ¶
	messages. A FETCH response is returned only for then non-expunged		messages. A FETCH response is returned only for then non-expunged
	messages along with a tagged NO>		messages along with a tagged NO>
	C2: B001 FETCH 3:5 ENVELOPE		C2: B001 FETCH 3:5 ENVELOPE
	S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)		S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
	S2: B001 NO Some of the requested messages no longer exist		S2: B001 NO Some of the requested messages no longer exist
	<Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP		<Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
	to be informed of any pending EXPUNGE responses>		to be informed of any pending EXPUNGE responses>
			Gahrns 6
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	C2: B002 NOOP		C2: B002 NOOP
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * 3 EXISTS		S2: * 3 EXISTS
	S2: B002 OK NOOP Completed.		S2: B002 OK NOOP Completed.
	<By receiving a FETCH response for message 3, and an EXPUNGE		<By receiving a FETCH response for message 3, and an EXPUNGE
	response that indicates messages 4:7 have been expunged, the client		response that indicates messages 4:7 have been expunged, the client
	does not need to re-issue the FETCH>		does not need to re-issue the FETCH>
	4.1.3 The server MAY allow the EXPUNGE of a multi-access mailbox, and		4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
	on subsequent FETCH commands return a tagged OK, "NIL FETCH		on subsequent FETCH commands return the usual FETCH responses for
	Responses" for expunged messages, and FETCH responses for non		non-expunged messages, "NIL FETCH Responses" for expunged
	-expunged messages.		messages, and a tagged OK response.
	If all of the messages in the subsequent FETCH command have been		If all of the messages in the subsequent FETCH command have been
	expunged, the server SHOULD return only a tagged NO. In this case,		expunged, the server SHOULD return only a tagged NO. In this case,
	the client SHOULD issue a NOOP command so that it will be informed		the client SHOULD issue a NOOP command so that it will be informed
	of any pending EXPUNGE responses. The client may then either		of any pending EXPUNGE responses. The client may then either
	reissue the failed FETCH command, or by examining the EXPUNGE		reissue the failed FETCH command, or by examining the EXPUNGE
	response from the NOOP, determine that the FETCH failed because of		response from the NOOP, determine that the FETCH failed because of
	pending expunges.		pending expunges.
	"NIL FETCH responses" are a representation of empty data as		"NIL FETCH responses" are a representation of empty data as
	skipping to change at line 355 ¶		skipping to change at line 375 ¶
	* 1 FETCH (BODY[<section>]<partial> "")		* 1 FETCH (BODY[<section>]<partial> "")
	In some cases, a client may not be able to distinguish between "NIL		In some cases, a client may not be able to distinguish between "NIL
	FETCH responses" received because a message was expunged and those		FETCH responses" received because a message was expunged and those
	received because the data actually was NIL. For example, a * 5		received because the data actually was NIL. For example, a * 5
	FETCH (FLAGS ()) response could be received if no flags were set on		FETCH (FLAGS ()) response could be received if no flags were set on
	message 5, or because message 5 was expunged. In a case of potential		message 5, or because message 5 was expunged. In a case of potential
	ambiguity, the client SHOULD issue a command such as NOOP to force		ambiguity, the client SHOULD issue a command such as NOOP to force
	the sending of the EXPUNGE responses to resolve any ambiguity.		the sending of the EXPUNGE responses to resolve any ambiguity.
			Gahrns 7
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
	<Client #2 attempts to access a mix of expunged and non-expunged		<Client #2 attempts to access a mix of expunged and non-expunged
	messages. Normal data is returned for non-expunged message, "NIL		messages. Normal data is returned for non-expunged message, "NIL
	FETCH responses" are returned for expunged messages>		FETCH responses" are returned for expunged messages>
	C2: B002 FETCH 3:5 ENVELOPE		C2: B002 FETCH 3:5 ENVELOPE
	S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)		S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
	S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL		S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
	NIL NIL)		NIL NIL)
	skipping to change at line 394 ¶		skipping to change at line 417 ¶
	Following are some strategies an IMAP server may choose to use when		Following are some strategies an IMAP server may choose to use when
	dealing with a STORE command on expunged messages.		dealing with a STORE command on expunged messages.
	4.2.1 If the ".SILENT" suffix is used, and the STORE completed		4.2.1 If the ".SILENT" suffix is used, and the STORE completed
	successfully for all the non-expunged messages, the server SHOULD		successfully for all the non-expunged messages, the server SHOULD
	return a tagged OK.		return a tagged OK.
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
	<Client #2 tries to SILENETLY STORE flags on expunged and non-		<Client #2 tries to silently STORE flags on expunged and non-
	expunged messages. The server sets the flags on the non-expunged		expunged messages. The server sets the flags on the non-expunged
	messages and returns OK>		messages and returns OK>
	C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)		C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
	S2: B001 OK		S2: B001 OK
	4.2.2. If the ".SILENT" suffix is not used, and only expunged messages		4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
	are referenced, the server SHOULD return only a tagged NO.		are referenced, the server SHOULD return only a tagged NO.
			Gahrns 8
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
	<Client #2 tries to STORE flags only on expunged messages>		<Client #2 tries to STORE flags only on expunged messages>
	C2: B001 STORE 5:7 +FLAGS (\SEEN)		C2: B001 STORE 5:7 +FLAGS (\SEEN)
	S2: B001 NO Messages have been expunged		S2: B001 NO Messages have been expunged
	4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged		4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
	and non-expunged messages are referenced, the server MAY set the		and non-expunged messages are referenced, the server MAY set the
	flags and return a FETCH response for the non-expunged messages		flags and return a FETCH response for the non-expunged messages
	along with a tagged NO.		along with a tagged NO.
	skipping to change at line 434 ¶		skipping to change at line 461 ¶
	<Client #2 tries to STORE flags on a mixture of expunged and non-		<Client #2 tries to STORE flags on a mixture of expunged and non-
	expunged messages>		expunged messages>
	C2: B001 STORE 1:7 +FLAGS (\SEEN)		C2: B001 STORE 1:7 +FLAGS (\SEEN)
	S2: * FETCH 1 FLAGS (\SEEN)		S2: * FETCH 1 FLAGS (\SEEN)
	S2: * FETCH 2 FLAGS (\SEEN)		S2: * FETCH 2 FLAGS (\SEEN)
	S2: * FETCH 3 FLAGS (\SEEN)		S2: * FETCH 3 FLAGS (\SEEN)
	S2: B001 NO Some of the messages no longer exist.		S2: B001 NO Some of the messages no longer exist.
	C2: B002 NOOP		C2: B002 NOOP
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * 3 EXISTS		S2: * 3 EXISTS
	S2: B002 OK NOOP Completed.		S2: B002 OK NOOP Completed.
	<By receiving FETCH responses for messages 1:3, and an EXPUNGE		<By receiving FETCH responses for messages 1:3, and an EXPUNGE
	response that indicates messages 4:7 have been expunged, the client		response that indicates messages 4:7 have been expunged, the client
	does not need to re-issue the STORE>		does not need to re-issue the STORE>
	4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged		4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
	and non-expunged messages are referenced, the server MAY return		and non-expunged messages are referenced, the server MAY return
	only an untagged NO and not set any flags, nor return any FETCH		only an untagged NO and not set any flags, nor return any FETCH
	responses		responses
	After receiving a tagged NO STORE response, the client SHOULD issue		After receiving a tagged NO STORE response, the client SHOULD issue
	a NOOP command so that it will be informed of any pending EXPUNGE		a NOOP command so that it will be informed of any pending EXPUNGE
			Gahrns 9
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	responses. The client would then re-issue the STORE command after		responses. The client would then re-issue the STORE command after
	updating its message list per any EXPUNGE response.		updating its message list per any EXPUNGE response.
	If a large number of clients are accessing a shared mailbox, the		If a large number of clients are accessing a shared mailbox, the
	window in which there are no pending expunges may be small or non-		window in which there are no pending expunges may be small or non-
	existent, effectively disallowing a client from setting the flags on		existent, effectively disallowing a client from setting the flags on
	all messages at once.		all messages at once.
	Example: (Building upon the scenario outlined in 4.1.)		Example: (Building upon the scenario outlined in 4.1.)
	<Client #2 tries to STORE flags on a mixture of expunged and non-		<Client #2 tries to STORE flags on a mixture of expunged and non-
	expunged messages>		expunged messages>
	C2: B001 STORE 1:7 +FLAGS (\SEEN)		C2: B001 STORE 1:7 +FLAGS (\SEEN)
	S2: B001 NO Some of the messages no longer exist.		S2: B001 NO Some of the messages no longer exist.
	<Client #2 issues a NOOP to be informed of the EXPUNGED messages>		<Client #2 issues a NOOP to be informed of the EXPUNGED messages>
	C2: B002 NOOP		C2: B002 NOOP
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * EXPUNGE 4		S2: * 4 EXPUNGE
	S2: * 3 EXISTS		S2: * 3 EXISTS
	S2: B002 OK NOOP Completed.		S2: B002 OK NOOP Completed.
	<Client #2 updates its message list and re-issues the STORE on only		<Client #2 updates its message list and re-issues the STORE on only
	those messages that have not been expunged>		those messages that have not been expunged>
	C2: B003 STORE 1:3 +FLAGS (\SEEN)		C2: B003 STORE 1:3 +FLAGS (\SEEN)
	S2: * FETCH 1 FLAGS (\SEEN)		S2: * FETCH 1 FLAGS (\SEEN)
	S2: * FETCH 2 FLAGS (\SEEN)		S2: * FETCH 2 FLAGS (\SEEN)
	S2: * FETCH 3 FLAGS (\SEEN)		S2: * FETCH 3 FLAGS (\SEEN)
	S2: B003 OK STORE Completed		S2: B003 OK STORE Completed
	4.2. Searching of EXPUNGED messages		4.3. Searching of expunged messages
	A server MAY simply not return a search response for messages that		A server MAY simply not return a search response for messages that
	have been expunged and it has not been able to inform the client		have been expunged and it has not been able to inform the client
	about. If a client was expecting a particular message to be		about. If a client was expecting a particular message to be
	returned in a search result, and it was not, the client SHOULD issue		returned in a search result, and it was not, the client SHOULD issue
	a NOOP command to see if the message was expunged by another client.		a NOOP command to see if the message was expunged by another client.
			4.4 Copying of expunged messages
			COPY is the only IMAP4 sequence number command that is safe to allow
			an EXPUNGE response on. This is because a client is not permitted
			to cascade several COPY commands together. A client is required to
			wait and confirm that the copy worked before issuing another one.
			Gahrns 10
			IMAP4 Multi-Accessed Mailbox Practice April 1997
			4.4.1 The server MAY disallow the COPY of messages in a multi-access
			mailbox that contains expunged messages.
			Pending EXPUNGE response(s) MUST be returned to the COPY command.
			Example:
			C: A001 COPY 2,4,6,8 FRED
			S: * 4 EXPUNGE
			S: A001 NO COPY rejected, because some of the requested
			messages were expunged
			Note: Non of the above messages are copied because if a COPY command
			is unsuccessful, the server MUST restore the destination mailbox to
			its state before the COPY attempt.
			4.4.2 The server MAY allow the COPY of messages in a multi-access
			mailbox that contains expunged messages.
			Pending EXPUNGE response(s) MUST be returned to the COPY command.
			Messages that are copied are messages corresponding to sequence
			numbers before any EXPUNGE response.
			Example:
			C: A001 COPY 2,4,6,8 FRED
			S: * 3 EXPUNGE
			S: A001 OK COPY completed
			In the above example, the messages that are copied to FRED are
			messages 2,4,6,8 at the start of the COPY command. These are
			equivalent to messages 2,3,5,7 at the end of the COPY command. The
			EXPUNGE response can't take place until after the messages from the
			COPY command are identified (because of the "no expunge while no
			commands in progress" rule.
			Example:
			C: A001 COPY 2,4,6,8 FRED
			S: * 4 EXPUNGE
			S: A001 OK COPY completed
			In the above example, message 4 was copied before it was expunged,
			and MUST appear in the destination mailbox FRED.
	5. Security Considerations		5. Security Considerations
	This document describes behavior of servers that use the IMAP4		This document describes behavior of servers that use the IMAP4
	protocol, and as such, has the same security considerations as		protocol, and as such, has the same security considerations as
	described in [RFC-2060].		described in [RFC-2060].
	In particular, some described server behavior does not allow for the		In particular, some described server behavior does not allow for the
	immediate deletion of information when a mailbox is accessed by		immediate deletion of information when a mailbox is accessed by
			Gahrns 11
			IMAP4 Multi-Accessed Mailbox Practice April 1997
	multiple clients. This may be a consideration when dealing with		multiple clients. This may be a consideration when dealing with
	sensitive information where immediate deletion would be preferred.		sensitive information where immediate deletion would be preferred.
	6. References		6. References
	[RFC-2060], Crispin, M., "Internet Message Access Protocol – Version		[RFC-2060], Crispin, M., "Internet Message Access Protocol – Version
	4rev1", RFC 2060, University of Washington, December 1996.		4rev1", RFC 2060, University of Washington, December 1996.
	7. Acknowledgments		7. Acknowledgments
	This document is the result of discussions on the IMAP4 mailing list		This document is the result of discussions on the IMAP4 mailing list
	and is meant to reflect consensus of this group. In particular,		and is meant to reflect consensus of this group. In particular,
	Raymond Cheng, Mark Crispin, Jack De Winter, Jim Evans, Steve Hole,		Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
	Mark Keasling, Barry Leiba, Pat Moran, Larry Osterman, Chris Newman,		Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
	and Vladimir Vulovic were significant participants in this		Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
	discussion or made suggestions to this document.		Winter were active participants in this discussion or made
			suggestions to this document.
	8. Author's Address		8. Author's Address
	Mike Gahrns		Mike Gahrns
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA, 98072		Redmond, WA, 98072
	Phone: (206) 936-9833		Phone: (206) 936-9833
	Email: mikega@microsoft.co		Email:
			mikega@microsoft.co
	m		m
			Gahrns 12
End of changes. 32 change blocks.
	49 lines changed or deleted		138 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/