< draft-melnikov-imap-ext-abnf-07.txt		draft-melnikov-imap-ext-abnf-08.txt >
	Internet Draft A. Melnikov		Internet Draft A. Melnikov
	Document: draft-melnikov-imap-ext-abnf Isode Ltd.		Document: draft-melnikov-imap-ext-abnf Isode Ltd.
	Expires: July 2006 Cyrus Daboo		Expires: July 2006 Cyrus Daboo
			Updates: RFC 3501, RFC 2342, RFC 2088, RFC 3502 and RFC 3516
	January 2006		January 2006
	Collected extensions to IMAP4 ABNF		Collected extensions to IMAP4 ABNF
	draft-melnikov-imap-ext-abnf-07		draft-melnikov-imap-ext-abnf-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at line 87 ¶		skipping to change at line 88 ¶
	10. Intellectual Property 17		10. Intellectual Property 17
	11. Appendix A. Editorial. 17		11. Appendix A. Editorial. 17
	11.1 Change Log 18		11.1 Change Log 18
	1. Introduction and Conventions Used		1. Introduction and Conventions Used
	1.1 Purpose of this document		1.1 Purpose of this document
	This document serves several purposes:		This document serves several purposes:
	1. rationalize and generalize ABNF for some existing IMAP		1. rationalize and generalize ABNF for some existing IMAP
	extensions;		extensions;
	2. collect the ABNF in one place in order to minimize cross		2. collect the ABNF in one place in order to minimize cross
	references between documents;		references between documents;
	3. define building blocks for future extensions so that they can be		3. define building blocks for future extensions so that they can
	used together in a compatible way.		be used together in a compatible way.
	It is expected that a future revision of this document gets		It is expected that a future revision of this document gets
	incorporated into a revision of RFC 3501.		incorporated into a revision of RFC 3501.
	This document updates ABNF in RFC 3501, RFC 2088, RFC 3502 and RFC		This document updates ABNF in RFC 2342, 3501, RFC 2088, RFC 3502
	3516. It also includes part of the errata to RFC 3501. This		and RFC 3516. It also includes part of the errata to RFC 3501. This
	document doesn't specify any semantic changes to the listed RFCs.		document doesn't specify any semantic changes to the listed RFCs.
	The ABNF in section 6 of RFC 2342 got rewritten to conform to the		The ABNF in section 6 of RFC 2342 got rewritten to conform to the
	ABNF syntax as defined in RFC 4234 and to reference new non-		ABNF syntax as defined in RFC 4234 and to reference new non-
	terminals from RFC 3501. It was also restructured to allow for		terminals from RFC 3501. It was also restructured to allow for
	better readability. There were no changes "on the wire".		better readability. There were no changes "on the wire".
	Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH		Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH
	/UID FETCH, STORE/UID STORE, SEARCH and APPEND commands in a		/UID FETCH, STORE/UID STORE, SEARCH and APPEND commands in a
	consistent manner. Extensions to all the commands but APPEND have		consistent manner. Extensions to all the commands but APPEND have
	skipping to change at line 127 ¶		skipping to change at line 128 ¶
	1.2 Conventions Used in this document		1.2 Conventions Used in this document
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"		The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
	in this document are to be interpreted as defined in "Key words for		in this document are to be interpreted as defined in "Key words for
	use in RFCs to Indicate Requirement Levels" [KEYWORDS].		use in RFCs to Indicate Requirement Levels" [KEYWORDS].
	<<Editorial comments and questions are enclosed like this>>
	2. IMAP ABNF extensions		2. IMAP ABNF extensions
	This section is not normative. It provides some background on the		This section is not normative. It provides some background on the
	intended use of different extensions and it gives some guidance		intended use of different extensions and it gives some guidance
	about how future extensions should extend the described commands.		about how future extensions should extend the described commands.
	2.1 Optional parameters with the SELECT/EXAMINE commands		2.1 Optional parameters with the SELECT/EXAMINE commands
	This documents adds the ability to include one or more parameters		This documents adds the ability to include one or more parameters
	with the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section		with the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section
End of changes. 5 change blocks.
	10 lines changed or deleted		9 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/