idnits 2.17.1 draft-melnikov-imap-keywords-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 11, 2009) is 5243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft D. Cridland 4 Intended status: Standards Track Isode Limited 5 Expires: June 14, 2010 December 11, 2009 7 IMAP4 Keyword Registry 8 draft-melnikov-imap-keywords-10 10 Abstract 12 The aim of this document is to establishe a new IANA registry for 13 IMAP keywords and to define a procedure for keyword registration, in 14 order to improve interoperability between different IMAP clients. 16 Note 18 A revised version of this draft document will be submitted to the RFC 19 editor as a Proposed Standard for the Internet Community. Discussion 20 and suggestions for improvement are requested, and should be sent to 21 morg@ietf.org. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 14, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Conventions used in this document . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . 3 68 3.1. Review guidelines for the designated Expert Reviewer . . . 5 69 3.2. Comments on IMAP Keywords' Registrations . . . . . . . . . 6 70 3.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4. Initial registrations . . . . . . . . . . . . . . . . . . 7 72 3.4.1. $MDNSent IMAP keyword registration . . . . . . . . . . . . 7 73 3.4.2. $Forwarded IMAP keyword registration . . . . . . . . . . . 8 74 3.4.3. $SubmitPending IMAP keyword registration . . . . . . . . . 9 75 3.4.4. $Submitted IMAP keyword registration . . . . . . . . . . . 11 77 4. Security Considerations . . . . . . . . . . . . . . . . . 12 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 87 1. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [Kwds]. 93 2. Introduction 95 IMAP Keywords [RFC3501] are boolean named flags that can be used by 96 clients to annotate messages in an IMAP mailbox. Although IMAP 97 keywords is an optional feature of IMAP, the majority of IMAP servers 98 can store arbitrary keywords. Many mainstream IMAP clients use a 99 limited set of specific keywords, and some can manage (create, edit, 100 display) arbitrary IMAP keywords. 102 Over years some IMAP keywords have become de-facto standard, with 103 some specific semantics associated with them. In some cases 104 different client implementors decided to define and use keywords with 105 different names, but the same semantics. Some server implementors 106 decided to map such keywords automatically in order to improve cross 107 client interoperability. 109 In other cases, the same keywords have been used with different 110 semantics, thus causing interoperability problems. 112 This document attempts to prevent further incompatible uses of IMAP 113 keywords by establishing an IMAP Keyword registry, and allocating a 114 special prefix for standardized keywords. 116 3. IANA Considerations 118 IANA is requested to establish a new registry for IMAP keywords. 120 Registration of an IMAP keyword is requested by filling in the 121 following template and following the instructions on the IANA pages 122 for the registry for submitting it to IANA: 124 Subject: Registration of IMAP keyword X 126 IMAP keyword name: 128 Purpose (description): 130 Private or Shared on a server: (One of PRIVATE, SHARED or BOTH. 131 PRIVATE means that each different user has a distinct 132 copy of the keyword. SHARED means that all different 133 users see the same value of the keyword. BOTH means that 134 an IMAP server can have the keyword as either private or 135 shared.) 137 Is it an advisory keyword or may it cause an automatic action: 139 When/by whom the keyword is set/cleared: 141 Related keywords: (for example "mutually exclusive with keywords Y 142 and Z") 144 Related IMAP capabilities: 146 Security considerations: 148 Published specification (recommended): 150 Person & email address to contact for further information: 152 Intended usage: (One of COMMON, LIMITED USE or DEPRECATED (i.e. not 153 recommended for use)) 155 Owner/Change controller: (MUST be "IESG" for any "common use" 156 keyword registration specified in an IETF Review 157 document. See definition of "common use" below in this 158 section. When the Owner/Change controller is not a 159 Standardization Organization, the registration request 160 MUST make it clear if the registration is controlled by a 161 company, or the individual performing the registration.) 163 Note: (Any other information that the author deems interesting 164 may be added here, for example if the keyword(s) is 165 supported by existing clients.) 167 Registration of an IMAP keyword requires Expert Review [RFC5226]. 168 Registration of any IMAP keyword is initiated by posting a 169 registration request to the Message Organization WG mailing list 170 (or its replacement as chosen by the responsible 171 Application Area Director) and CCing IANA (). After 172 allowing for at least 2 weeks for community input on the designated 173 mailing list, the expert will determine the appropriateness of the 174 registration request and either approve or disapprove the request 175 with notice to the requestor, the mailing list, and IANA. Any 176 refusal must come with a clear explanation. 178 The IESG appoints one or more Expert Reviewer for the IMAP Keyword 179 registry established by this document. 181 Expert Reviewer should strive for timely reviews. Expert Reviewer 182 should take no longer than 6 weeks to make and announce the decision, 183 or notify the mailing list that more time is required. 185 Decisions (or lack of) made by an Expert Reviewer can be first 186 appealed to Application Area Directors and, if the appellant is not 187 satisfied with the response, to the full IESG. 189 There are two types of IMAP keywords in the "IMAP Keywords" registry: 190 intended for common use and vendor/organization specific (also known 191 as "limited use"). An IMAP keyword is said to be for "common use" if 192 it is reasonably expected to be implemented in at least 2 independent 193 client implementations. The two types of IMAP Keywords have 194 different levels of requirements for registration (see below). 196 3.1. Review guidelines for the designated Expert Reviewer 198 Expert Reviewers should focus on the following requirements. 200 Registration of a vendor/organization specific ("limited use") IMAP 201 keyword is easier. The Expert Reviewer only needs to check that the 202 requested name doesn't conflict with an already registered name, and 203 that the name is not too generic, misleading, etc. The Expert 204 Reviewer MAY request the IMAP Keyword name change before approving 205 the registration. The Expert Reviewer SHOULD refuse a registration 206 if there is an already registered IMAP Keyword which serve the same 207 purpose, but has a different name. 209 When registering an IMAP Keyword for "common use", the Expert 210 Reviewer performs the checks described for vendor/organization 211 specific IMAP Keywords, plus additional checks as detailed below. 213 Keywords intended for common use SHOULD start with the "$" prefix. 214 (Note that this is a SHOULD because some of the commonly used IMAP 215 keywords in widespread use don't follow this convention.) 217 IMAP keywords intended for common use SHOULD be standardized in IETF 218 Review [RFC5226] documents. (Note that IETF Review documents still 219 require Expert Review.) 221 Values in the "IMAP Keywords" IANA registry intended for common use 222 must be clearly documented and likely to ensure interoperability. 223 They must be useful, not harmful to the Internet. In cases when an 224 IMAP Keyword being registered is already deployed, Expert Reviewers 225 should favour registering it over requiring perfect documentation 226 and/or requesting to change the name of the IMAP Keyword. 228 The Expert Reviewer MAY automatically "upgrade" registration requests 229 for a "limited use" IMAP Keyword to "common use" level. The Expert 230 Reviewer MAY also request that a registration targeted for "common 231 use" be registered as "limited use" instead. 233 3.2. Comments on IMAP Keywords' Registrations 235 Comments on registered IMAP Keywords should be sent to both the 236 "owner" of the mechanism and to the mailing list designated to IMAP 237 keyword review (see Section 3). This improves chances of getting a 238 timely response. 240 Submitters of comments may, after a reasonable attempt to contact the 241 owner and after soliciting comments on the IMAP mailing list, request 242 the designated Expert Reviewer to attach their comment to the IMAP 243 keyword registration itself. The procedure is similar to requesting 244 an expert review for the affected keyword. 246 3.3. Change Control 248 Once an IMAP keyword registration has been published by IANA, the 249 owner may request a change to its definition. The change request 250 (including a change to the "intended usage" field) follows the same 251 procedure as the initial registration request, with the exception of 252 changes to the "Person & email address to contact for further 253 information" and "Owner/Change controller" fields. The latter can be 254 changed by the owner by informing IANA; this can be done without 255 discussion or review. 257 The IESG may reassign responsibility for an IMAP keyword. The most 258 common case of this will be to enable clarifications to be made to 259 keywords where the owner of the registration has died, moved out of 260 contact or is otherwise unable to make changes that are important to 261 the community. 263 IMAP keyword registrations MUST NOT be deleted; keywords which are no 264 longer believed appropriate for use can be declared DEPRECATED by a 265 change to their "intended usage" field. 267 The IESG is considered to be the owner of all "common use" IMAP 268 keywords that are published in an IETF Review document. 270 3.4. Initial registrations 272 IANA is requested to register IMAP Keywords specified in subsections 273 of this section in the registry established in this document. 275 3.4.1. $MDNSent IMAP keyword registration 277 Subject: Registration of IMAP keyword $MDNSent 279 IMAP keyword name: $MDNSent 281 Purpose (description): Specifies that a Message Disposition 282 Notification (MDN) must not be sent for any message 283 annotated with the $MDNSent IMAP keyword. 285 Private or Shared on a server: SHARED 287 Is it an advisory keyword or may it cause an automatic action: This 288 keyword can cause automatic action by the client. See 289 [RFC3503] for more details. 291 When/by whom the keyword is set/cleared: This keyword is set by an 292 IMAP client when it decides to act on a MDN request, or 293 when uploading a sent or draft message. It can also be 294 set by a delivery agent. Once set the flag SHOULD NOT be 295 cleared. 297 Related keywords: None 299 Related IMAP capabilities: None 301 Security considerations: See section 6 of [RFC3503] 303 Published specification (recommended): [RFC3503] 305 Person & email address to contact for further information: Alexey 306 Melnikov 308 Intended usage: COMMON 310 Owner/Change controller: IESG 312 Note: 314 3.4.2. $Forwarded IMAP keyword registration 316 Subject: Registration of the IMAP keyword $Forwarded 318 IMAP keyword name: $Forwarded 320 Purpose (description): $Forwarded is used by several IMAP clients to 321 specify that the message was resent to another email 322 address, embedded within or attached to a new message. 323 This keyword is set by the mail client when it 324 successfully forwards the message to another email 325 address. Typical usage of this keyword is to show a 326 different (or additional) icon for a message that has 327 been forwarded. 329 Private or Shared on a server: BOTH 330 Is it an advisory keyword or may it cause an automatic action: 331 advisory 333 When/by whom the keyword is set/cleared: This keyword can be set 334 either by a delivery agent or by a mail client. Once set 335 the flag SHOULD NOT be cleared. Notes: There is no way 336 to tell if a message with $Forwarded keyword set was 337 forwarded more than once. 339 Related keywords: None 341 Related IMAP capabilities: None 343 Security considerations: A server implementing this keyword as a 344 shared keyword, may disclose that a confidential message 345 was forwarded. 347 Published specification (recommended): [RFC5550] 349 Person & email address to contact for further information: Alexey 350 Melnikov 352 Intended usage: COMMON 354 Owner/Change controller: IESG 356 Note: 358 3.4.3. $SubmitPending IMAP keyword registration 360 Subject: Registration of IMAP keyword $SubmitPending 362 IMAP keyword name: $SubmitPending 363 Purpose (description): The $SubmitPending IMAP keyword designates 364 the message as awaiting to be submitted. This keyword 365 allows storing messages waiting to be submitted in the 366 same mailbox where messages that were already submitted 367 and/or are being edited are stored. 369 A message that has both $Submitted and $SubmitPending 370 IMAP keywords set is a message being actively submitted. 372 Private or Shared on a server: SHARED 374 Is it an advisory keyword or may it cause an automatic action: This 375 keyword can cause automatic action by the client. See 376 Section 5.10 of [RFC5550] for more details. 378 When/by whom the keyword is set/cleared: This keyword is set by a 379 mail client when it decides that the message needs to be 380 sent out. 382 Related keywords: $Submitted 384 Related IMAP capabilities: None 386 Security considerations: A server implementing this keyword as a 387 shared keyword, may disclose that a confidential message 388 is sheduled to be sent out or is being actively sent out. 390 Published specification (recommended): [RFC5550] 392 Person & email address to contact for further information: Alexey 393 Melnikov 395 Intended usage: COMMON 397 Owner/Change controller: IESG 398 Note: 400 3.4.4. $Submitted IMAP keyword registration 402 Subject: Registration of IMAP keyword $Submitted 404 IMAP keyword name: $Submitted 406 Purpose (description): The $Submitted IMAP keyword designates the 407 message as being sent out. 409 A message that has both $Submitted and $SubmitPending 410 IMAP keywords set is a message being actively submitted. 412 Private or Shared on a server: SHARED 414 Is it an advisory keyword or may it cause an automatic action: This 415 keyword can cause automatic action by the client. See 416 Section 5.10 of [RFC5550] for more details. 418 When/by whom the keyword is set/cleared: This keyword is set by a 419 mail client when it decides to start sending it. 421 Related keywords: $SubmitPending 423 Related IMAP capabilities: None 425 Security considerations: A server implementing this keyword as a 426 shared keyword, may disclose that a confidential message 427 was sent or is being actively sent out. 429 Published specification (recommended): [RFC5550] 431 Person & email address to contact for further information: Alexey 432 Melnikov 434 Intended usage: COMMON 436 Owner/Change controller: IESG 438 Note: 440 4. Security Considerations 442 IMAP Keywords are one of the base IMAP features [RFC3501]. This 443 document doesn't change their behaviour, so it is not adding new 444 security issues. 446 A particular IMAP keyword might have specific security 447 considerations, which are documented in IMAP keyword registration 448 template standardized by this document. 450 5. Acknowledgements 452 The creation of this document was prompted by one of many discussions 453 on the IMAP mailing list. 455 John Neystadt co-authored the first revision of this document. 457 Special thanks to Chris Newman, David Harris, Lyndon Nerenberg, Mark 458 Crispin, Samuel Weiler and Alfred Hoenes for reviewing different 459 versions of this document. However all errors or omissions must be 460 attributed to the authors of this document. 462 The author would also like to thank the developers of Mozilla mail 463 clients for providing food for thoughts. 465 6. References 467 6.1. Normative References 469 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", RFC 2119, March 1997. 472 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 473 4rev1", RFC 3501, March 2003. 475 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 476 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 477 May 2008. 479 6.2. Informative References 481 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 482 profile for Internet Message Access Protocol (IMAP)", 483 RFC 3503, March 2003. 485 [RFC5550] Cridland, D., Melnikov, A., and S. Maes, "The Internet 486 Email to Support Diverse Service Environments (Lemonade) 487 Profile", RFC 5550, August 2009. 489 Authors' Addresses 491 Alexey Melnikov 492 Isode Limited 493 5 Castle Business Village 494 36 Station Road 495 Hampton, Middlesex TW12 2BX 496 UK 498 Email: Alexey.Melnikov@isode.com 499 URI: http://www.melnikov.ca/ 501 Dave Cridland 502 Isode Limited 503 5 Castle Business Village 504 36 Station Road 505 Hampton, Middlesex TW12 2BX 506 UK 508 Email: dave.cridland@isode.com