< draft-leiba-extra-specialuse-important-00.txt		draft-leiba-extra-specialuse-important-01.txt >
	Network Working Group B. Leiba, Ed.		Network Working Group B. Leiba, Ed.
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track November 15, 2017		Intended status: Standards Track February 25, 2018
	Expires: May 17, 2018		Expires: August 27, 2018
	IMAP $Important Keyword and \Important Special-Use Attribute		IMAP $Important Keyword and \Important Special-Use Attribute
	draft-leiba-extra-specialuse-important-00		draft-leiba-extra-specialuse-important-01
	Abstract		Abstract
	RFC 6154 created an IMAP Special-Use LIST extension and defined an		RFC 6154 created an IMAP Special-Use LIST extension and defined an
	initial set of attributes. This document defines a new attribute,		initial set of attributes. This document defines a new attribute,
	"\Important", and establishes a new IANA registry for IMAP folder		"\Important", and establishes a new IANA registry for IMAP folder
	attributes, registering the attributes defined in RFCs 3348, 3501,		attributes, registering the attributes defined in RFCs 3348, 3501,
	and 6154. This document also defines a new IMAP keyword,		and 6154. This document also defines a new IMAP keyword,
	"$Important", and registers it in the registry defined in RFC 5788.		"$Important", and registers it in the registry defined in RFC 5788.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 17, 2018.		This Internet-Draft will expire on August 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . . 2		1.1. Conventions used in this document . . . . . . . . . . . . . 2
	2. Definition of the '$Important' Message Keyword . . . . . . . . 2		2. Definition of the '$Important' Message Keyword . . . . . . . . 2
	3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3		3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3
	3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 3		4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	5.1. Registration of the $Important keyword . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 5		6.1. Registration of the $Important keyword . . . . . . . . . . . 5
	5.2.1. Instructions to the Designated Expert . . . . . . . . . . 5		6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 6
	5.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 6		6.2.1. Instructions to the Designated Expert . . . . . . . . . . 6
	6. Changes During Document Development . . . . . . . . . . . . . 6		6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 6
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Changes During Document Development . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . . . 8
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Internet Message Access Protocol (IMAP) specification [RFC3501]		The Internet Message Access Protocol (IMAP) specification [RFC3501]
	defines the use of message keywords, and an IMAP Keywords registry is		defines the use of message keywords, and an IMAP Keywords registry is
	created in [RFC5788]. [RFC6154] defines an extension to the IMAP		created in [RFC5788]. [RFC6154] defines an extension to the IMAP
	LIST command for special-use mailboxes. The extension allows servers		LIST command for special-use mailboxes. The extension allows servers
	to provide extra information (attributes) about the purpose of a		to provide extra information (attributes) about the purpose of a
	mailbox and defines an initial set of special-use attributes.		mailbox and defines an initial set of special-use attributes.
	skipping to change at page 2, line 52 ¶		skipping to change at page 3, line 4 ¶
	o Creates a registry for IMAP mailbox attributes and registers the		o Creates a registry for IMAP mailbox attributes and registers the
	new attribute and those defined in [RFC3348], [RFC3501], and		new attribute and those defined in [RFC3348], [RFC3501], and
	[RFC6154].		[RFC6154].
	1.1. Conventions used in this document		1.1. Conventions used in this document
	In examples, "C:" indicates lines sent by a client that is connected		In examples, "C:" indicates lines sent by a client that is connected
	to a server. "S:" indicates lines sent by the server to the client.		to a server. "S:" indicates lines sent by the server to the client.
	2. Definition of the '$Important' Message Keyword		2. Definition of the '$Important' Message Keyword
	The "$Important" keyword is a signal that a message is likely		The "$Important" keyword is a signal that a message is likely
	important to the user. The keyword can be set by the user, or		important to the user. The keyword is generally expected to be set
	automatically by the system based on available signals (such as who		automatically by the system based on available signals (such as who
	the message is from, who else the message is addressed to, evaluation		the message is from, who else the message is addressed to, evaluation
	of the subject or content, or other heuristics).		of the subject or content, or other heuristics). While the keyword
			also can be set by the user, that is not expected to be the primary
			usage.
	This is distinct from the "\Flagged" system flag in two ways:		This is distinct from the "\Flagged" system flag in two ways:
	1. "$Important" carries a specific meaning of importance, as opposed		1. "$Important" carries a specific meaning of general importance, as
	to urgency. It is meant to be used for a form of triage, with		opposed to follow-up or urgency. It is meant to be used for a
	"\Flagged" remaining as a designation of special attention or		form of triage, with "\Flagged" remaining as a designation of
	particular urgency.		special attention, need for follow-up, or time-sensitivity. In
			particular, the sense of "$Important" is that other messages that
			are "like this one" according to some server-applied heuristics
			will also be $Important.
	2. The setting of "$Important" is expected to be based at least		2. The setting of "$Important" is expected to be based at least
	partly on heuristics, whereas "\Flagged" is intended to be set by		partly on heuristics, generally set automatically by the server,
	the user.		whereas "\Flagged" is only intended to be set by the user with
			some sort of "flag this message" or "put a star on this message"
			interface.
	3. Definition of the 'Important' Mailbox Attribute		3. Definition of the 'Important' Mailbox Attribute
	The "\Important" mailbox attribute is a signal that the mailbox		The "\Important" mailbox attribute is a signal that the mailbox
	contains messages that are likely important to the user. In an		contains messages that are likely important to the user. In an
	implementation that also supports the "$Important" keyword, this		implementation that also supports the "$Important" keyword, this
	special use is likely to represent a virtual mailbox collecting		special use is likely to represent a virtual mailbox collecting
	messages (from other mailboxes) that are marked with the "$Important"		messages (from other mailboxes) that are marked with the "$Important"
	keyword. In other implementations, the system might automatically		keyword. In other implementations, the system might automatically
	put messages there based on the same sorts of heuristics that are		put messages there based on the same sorts of heuristics that are
	noted for the "$Important" keyword (see Section 2). The distinction		noted for the "$Important" keyword (see Section 2). The distinction
	between "\Important" and "\Flagged" for mailboxes is similar to those		between "\Important" and "\Flagged" for mailboxes is similar to those
	between "$Important" and "\Flagged" for messages.		between "$Important" and "\Flagged" for messages.
	3.1. Formal Syntax		3.1. Formal Syntax
	The following syntax specification adds to the one in [RFC6154],		The following syntax specification adds to the one in [RFC6154],
	Section 6, using Augmented Backus-Naur Form (ABNF) as described in		Section 6, using Augmented Backus-Naur Form (ABNF) as described in
	[RFC5234].		[RFC5234]. Be sure to see the ABNF notes at the beginning of
			[RFC3501], Section 9.
	use-attr =/ "\Important"		use-attr =/ "\Important"
	3.2. Example		3.2. Example
	In the following example, the mailbox called "Important Messages" is		In the following example, the mailbox called "Important Messages" is
	the one designated with the "\Important" attribute.		the one designated with the "\Important" attribute.
	C: t1 list "" "Imp*"		C: t1 list "" "Imp*"
	S: * LIST (\HasNoChildren \Important) "/" "Important Messages"		S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
	S: * LIST (\HasNoChildren) "/" "Imported Wine"		S: * LIST (\HasNoChildren) "/" "Imported Wine"
	S: t1 OK Success		S: t1 OK Success
	4. Security Considerations		4. Implementation Notes
			This section is non-normative and is intended to describe the
			intended (and current as of this publication) usage of "$Important"
			in contrast with "\Flagged" on a message.
			On the server:
			o \Flagged is set or cleared in response to an explicit command from
			the client.
			o $Important is set via a heuristic process performed by the server,
			usually involving analysis of header fields, what mailbox the
			message is filed in, perhaps message content, attachments, and
			such. It may then be set or cleared in response to an explicit
			command from the client, and the server may use that to adjust the
			heuristics in the future. It's also possible that the server will
			re-evaluate this and make a message $Important later if the user
			accesses the message frequently, for example.
			On the client:
			o Typically, an icon such as a flag or a star, or an indication such
			as red or bold text, is associated with \Flagged, and the UI
			provides a way for the user to turn that icon or indication on or
			off. Manipulation of the this results in a command to the server.
			o Typically, a lesser indication is used for $Important. The client
			might or might not provide the user with a way to manipulate it.
			If it does, manipulation results in a command to the server.
			5. Security Considerations
	The security considerations in [RFC6154], Section 7, apply equally to		The security considerations in [RFC6154], Section 7, apply equally to
	this extension. In particular, "Conveying special-use information to		this extension. In particular, "Conveying special-use information to
	a client exposes a small bit of extra information that could be of		a client exposes a small bit of extra information that could be of
	value to an attacker." Moreover, identifying "important" messages or		value to an attacker." Moreover, identifying "important" messages or
	a place where important messages are kept could give an attacker a		a place where important messages are kept could give an attacker a
	strategic starting point. If the algorithm by which messages are		strategic starting point. If the algorithm by which messages are
	determined to be important is well known, still more information is		determined to be important is well known, still more information is
	exposed -- perhaps, for example, there is an implication that the		exposed -- perhaps, for example, there is an implication that the
	senders of these messages are particularly significant to the mailbox		senders of these messages are particularly significant to the mailbox
	owner, and perhaps that is information that should not be made		owner, and perhaps that is information that should not be made
	public.		public.
	As noted in RFC 6154, it is wise to protect the IMAP channel from		As noted in RFC 6154, it is wise to protect the IMAP channel from
	passive eavesdropping, and to defend against unauthorized discernment		passive eavesdropping, and to defend against unauthorized discernment
	of the identity of a user's "\Important" mailbox or of a user's		of the identity of a user's "\Important" mailbox or of a user's
	"$Important" messages.		"$Important" messages.
	5. IANA Considerations		6. IANA Considerations
	This document contains 3 actions for IANA, specified in the sections		This document contains 3 actions for IANA, specified in the sections
	below:		below:
	1. Registration of the "$Important" keyword.		1. Registration of the "$Important" keyword.
	2. Creation of a new "IMAP Mailbox Name Attributes" registry.		2. Creation of a new "IMAP Mailbox Name Attributes" registry.
	3. Registration of initial entries in the "IMAP Mailbox Name		3. Registration of initial entries in the "IMAP Mailbox Name
	Attributes" registry.		Attributes" registry.
	5.1. Registration of the $Important keyword		6.1. Registration of the $Important keyword
	IANA is asked to register the $Important keyword in the "IMAP		IANA is asked to register the $Important keyword in the "IMAP
	Keywords" registry, as follows, using the template in [RFC5788].		Keywords" registry, as follows, using the template in [RFC5788].
	IMAP keyword name: $Important		IMAP keyword name: $Important
	Purpose (description): The "$Important" keyword is a signal that a		Purpose (description): The "$Important" keyword is a signal that a
	message is likely important to the user.		message is likely important to the user.
	Private or Shared on a server: PRIVATE		Private or Shared on a server: PRIVATE
	Is it an advisory keyword or may it cause an automatic action: Adviso		Is it an advisory keyword or may it cause an automatic action:
	ry (but see the reference for details).		Advisory (but see the reference for details).
	When/by whom the keyword is set/cleared: The keyword can be set by		When/by whom the keyword is set/cleared: The keyword can be set by
	the user, or automatically by the system based on available		the user, or automatically by the system based on available
	signals (such as who the message is from, who else the message		signals (such as who the message is from, who else the message
	is addressed to, evaluation of the subject or content, or other		is addressed to, evaluation of the subject or content, or other
	heuristics).		heuristics).
	Related keywords: None (but see the reference for the related mailbox		Related keywords: None (but see the reference for the related mailbox
	name attribute).		name attribute).
	Related IMAP capabilities: None.		Related IMAP capabilities: None.
	Security considerations: See [[THIS RFC]], Section 4		Security considerations: See [[THIS RFC]], Section 5
	Published specification: [[THIS RFC]]		Published specification: [[THIS RFC]]
	Person & email address to contact for further information: IETF Appli		Person & email address to contact for further information:
	cations Area <apps-discuss@ietf.org>		IETF Applications and Real-Time Area <art@ietf.org>
	Intended usage: COMMON		Intended usage: COMMON
	Owner/Change controller: IESG		Owner/Change controller: IESG
	Note: None.		Note: None.
	5.2. Creation of the IMAP Mailbox Name Attributes Registry		6.2. Creation of the IMAP Mailbox Name Attributes Registry
	IANA is asked to create a new registry in the group "Internet Message		IANA is asked to create a new registry in the group "Internet Message
	Access Protocol (IMAP)". The new registry will be called "IMAP		Access Protocol (IMAP)". The new registry will be called "IMAP
	Mailbox Name Attributes", and will have two references: "RFC 3501,		Mailbox Name Attributes", and will have two references: "RFC 3501,
	Section 7.2.2", and "[[THIS RFC]], Section 5".		Section 7.2.2", and "[[THIS RFC]], Section 6".
	The registry entries will contain three fields:		The registry entries will contain three fields:
	1. Attribute Name		1. Attribute Name
	2. Description		2. Description
	3. Reference		3. Reference
	IANA will keep this list in alphabetical order by Attribute Name,		IANA will keep this list in alphabetical order by Attribute Name,
	which is registered without the initial backslash ("\").		which is registered without the initial backslash ("\"). The names
			are generally registered with initial capital letters, but are
			treated as case-insensitive strings.
	The registration policy for the new registry will be listed as "IETF		The registration policy for the new registry will be listed as "IETF
	Review or Expert Review" [RFC8126], and new registrations will be		Review or Expert Review" [RFC8126], and new registrations will be
	accepted in one of two ways:		accepted in one of two ways:
	1. For registrations requested in an IETF consensus document, the		1. For registrations requested in an IETF consensus document, the
	registration policy will be IETF Review, and the request will be		registration policy will be IETF Review, and the request will be
	made in the IANA Considerations section of the document, giving		made in the IANA Considerations section of the document, giving
	the requested values for each of the three fields.		the requested values for each of the three fields.
	2. For other registrations, the policy will be Expert Review policy		2. For other registrations, the policy will be Expert Review policy
	(see Section 5.2.1), and the request will be made by sending		(see Section 6.2.1), and the request will be made by sending
	email to IANA asking for a new IMAP Mailbox Name Attribute and		email to IANA asking for a new IMAP Mailbox Name Attribute and
	giving the requested values for each of the three fields.		giving the requested values for each of the three fields.
	5.2.1. Instructions to the Designated Expert		6.2.1. Instructions to the Designated Expert
	The expert reviewer, who will be designated by the IESG, is expected		The expert reviewer, who will be designated by the IESG, is expected
	to provide only a general review of the requested registration,		to provide only a general review of the requested registration,
	checking that the reference and description are adequate for		checking that the reference and description are adequate for
	understanding the intent of the registered attribute. Efforts should		understanding the intent of the registered attribute. Efforts should
	also be made to generalize the intent of an attribute so that		also be made to generalize the intent of an attribute so that
	multiple implementations with the same requirements may reuse		multiple implementations with the same requirements may reuse
	existing attributes. Except for this check, this is intended to be		existing attributes. Except for this check, this is intended to be
	very close to a first come first served policy, and the expert should		very close to a first come first served policy, and the expert should
	not block serious registration requests with a reasonable reference.		not block serious registration requests with a reasonable reference.
	The reference may be to any form of documentation, including a web		The reference may be to any form of documentation, including a web
	page, but consideration should be given to providing one that is		page, but consideration should be given to providing one that is
	expected to be long-lived and stable.		expected to be long-lived and stable.
	5.3. Initial Entries for the IMAP Mailbox Name Attributes Registry		6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry
	The registry will initially contain these entries:		The registry will initially contain these entries:
	+===============+===================================+===========+		+===============+===================================+===========+
	| Attribute | Description | Reference |		| Attribute | Description | Reference |
	| Name | | |		| Name | | |
	+===============+===================================+===========+		+===============+===================================+===========+
	| All | All messages | [RFC6154] |		| All | All messages | [RFC6154] |
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	| Archive | Archived messages | [RFC6154] |		| Archive | Archived messages | [RFC6154] |
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 40 ¶
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	| Noselect | The mailbox is not selectable | [RFC3501] |		| Noselect | The mailbox is not selectable | [RFC3501] |
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	| Sent | Sent mail | [RFC6154] |		| Sent | Sent mail | [RFC6154] |
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	| Trash | Messages the user has discarded | [RFC6154] |		| Trash | Messages the user has discarded | [RFC6154] |
	+---------------+-----------------------------------+-----------+		+---------------+-----------------------------------+-----------+
	| Unmarked | No new messages since last select | [RFC3501] |		| Unmarked | No new messages since last select | [RFC3501] |
	+===============+===================================+===========+		+===============+===================================+===========+
	6. Changes During Document Development		7. Changes During Document Development
	[[RFC Editor: Please remove this section prior to publication.]]		[[RFC Editor: Please remove this section prior to publication.]]
	Changes in -02		Changes in draft-leiba-extra-specialuse-important-01
			o Updated "IETF Applications Area" to "IETF Applications and Real-
			Time Area".
			o Changed some wording to make the distinction between \Flagged and
			\Important clearer.
			o Added some text explaining how \Important is used in existing
			servers.
			o Added a note in the ABNF section referring to the ABNF notes in
			the IMAP spec.
			Changes in draft-leiba-extra-specialuse-important-00
			o Reset status, moved Eric to "Contributors", changed Barry to
			"Editor"
			o Updated BCP 26 reference to RFC 8126.
			Changes in draft-iceman-imap-specialuse-important-02
	o Added the definition and registration of $Important.		o Added the definition and registration of $Important.
	o Noted that \Important might be implemented as a virtual collection		o Noted that \Important might be implemented as a virtual collection
	of $Important messages.		of $Important messages.
	Changes in -01		Changes in draft-iceman-imap-specialuse-important-01
	o Expanded the new registry to all mailbox name attributes, and		o Expanded the new registry to all mailbox name attributes, and
	added the attributes from 3501 and 3348 (suggested by Alexey).		added the attributes from 3501 and 3348 (suggested by Alexey).
	This also adds those two documents to the "updates" list.		This also adds those two documents to the "updates" list.
	o Recorded Cyrus's suggestion to define $Important.		o Recorded Cyrus's suggestion to define $Important.
	7. Contributors		8. Contributors
	The following author was an original contributor to this document in		The following author was an original contributor to this document in
	addition to the editor.		addition to the editor.
	Eric "Iceman"		Eric "Iceman"
	Google		Google
	iceman@google.com		iceman@google.com
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for		[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
	Special-Use Mailboxes", RFC 6154, March 2011.		Special-Use Mailboxes", RFC 6154, March 2011.
	[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www		RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www
	.rfc-editor.org/info/rfc8126>.		.rfc-editor.org/info/rfc8126>.
	8.2. Informative References		9.2. Informative References
	[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action		[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
	Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July		Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July
	2002.		2002.
	[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",		[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
	RFC 5788, March 2010.		RFC 5788, March 2010.
	Author's Address		Author's Address
End of changes. 31 change blocks.
	50 lines changed or deleted		111 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/