< draft-ietf-extra-specialuse-important-00.txt		draft-ietf-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 March 22, 2018		Intended status: Standards Track April 19, 2018
	Expires: September 21, 2018		Expires: October 19, 2018
	IMAP $Important Keyword and \Important Special-Use Attribute		IMAP $Important Keyword and \Important Special-Use Attribute
	draft-ietf-extra-specialuse-important-00		draft-ietf-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 September 21, 2018.		This Internet-Draft will expire on October 19, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3.2.1. Example of a LIST Response . . . . . . . . . . . . . . . . 3
			3.2.2. Examples of Creating a New Mailbox using \Important . . . 4
	4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4		4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Registration of the $Important keyword . . . . . . . . . . . 5		6.1. Registration of the $Important keyword . . . . . . . . . . . 5
	6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 6		6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 6
	6.2.1. Instructions to the Designated Expert . . . . . . . . . . 6		6.2.1. Instructions to the Designated Expert . . . . . . . . . . 7
	6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 7		6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry 7
	7. Changes During Document Development . . . . . . . . . . . . . 8		7. Changes During Document Development . . . . . . . . . . . . . 8
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
	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 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	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]. Be sure to see the ABNF notes at the beginning of		[RFC5234]. Be sure to see the ABNF notes at the beginning of
	[RFC3501], Section 9.		[RFC3501], Section 9.
	use-attr =/ "\Important"		use-attr =/ "\Important"
	3.2. Example		3.2. Examples
			3.2.1. Example of a LIST Response
	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
			3.2.2. Examples of Creating a New Mailbox using \Important
			In the following example, the mailbox called "Important Messages" is
			created with the "\Important" attribute on a server that advertises
			the "CREATE-SPECIAL-USE" capability string.
			C: t1 CREATE "Important Messages" (USE (\Important))
			S: t1 OK Mailbox created
			The following example is similar to the previous one, but the server
			is not able to assign the \Important attribute to the new mailbox.
			C: t1 CREATE "Important Messages" (USE (\Important))
			S: t1 NO [USEATTR] Mailbox not created; an \Important mailbox already exists
			The following example is similar to the previous one, but the server
			does not support this extension.
			C: t1 CREATE "Important Messages" (USE (\Important))
			S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important
			In both of the failure-mode examples, the "USEATTR" response code
			lets the client know that the problem is in the "USE" parameters.
			Note that the same response code is given in both cases, and the
			human-readable text is the only way to tell the difference. That
			text is not parsable by the client (it can only be logged and/or
			reported to the user).
	4. Implementation Notes		4. Implementation Notes
	This section is non-normative and is intended to describe the		This section is non-normative and is intended to describe the
	intended (and current as of this publication) usage of "$Important"		intended (and current as of this publication) usage of "$Important"
	in contrast with "\Flagged" on a message.		in contrast with "\Flagged" on a message.
	On the server:		On the server:
	o \Flagged is set or cleared in response to an explicit command from		o \Flagged is set or cleared in response to an explicit command from
	the client.		the client.
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 26 ¶
	Related IMAP capabilities: None.		Related IMAP capabilities: None.
	Security considerations: See [[THIS RFC]], Section 5		Security considerations: See [[THIS RFC]], Section 5
	Published specification: [[THIS RFC]]		Published specification: [[THIS RFC]]
	Person & email address to contact for further information:		Person & email address to contact for further information:
	IETF Applications and Real-Time Area <art@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.
	6.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 6". This registry will be		Section 7.2.2", and "[[THIS RFC]], Section 6". This registry will be
	shared with JMAP.		shared with JMAP.
	The registry entries will contain three fields:		The registry entries will contain the following fields:
	1. Attribute Name		1. Attribute Name
	2. Description		2. Description
	3. Reference		3. Reference
	4. Usage Notes		4. Usage Notes
	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 ("\"). The names		which is registered without the initial backslash ("\"). The names
	are generally registered with initial capital letters, but are		are generally registered with initial capital letters, but are
	treated as case-insensitive strings.		treated as case-insensitive US-ASCII strings.
	The "Usage Notes" field is free-form text that will normally be empty		The "Usage Notes" field is free-form US-ASCII text that will normally
	(and is empty if it's not specified in the registration request). It		be empty (and is empty if it's not specified in the registration
	is intended to hold things such as "not used by JMAP" and "JMAP		request). It is intended to hold things such as "not used by JMAP"
	only". The field is for human use, and there is no need for a		and "JMAP only". The field is for human use, and there is no need
	registry of strings that may appear here.		for a registry of strings that may appear here.
	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 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 6.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 fields.
	6.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
End of changes. 21 change blocks.
	24 lines changed or deleted		55 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/