idnits 2.17.1 draft-ietf-imapext-annotate-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1521. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ANNOTATETOOBIG], [ANNOTATETOOMANY]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (November 21, 2005) is 6724 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ANNOTATE TOOBIG' is mentioned on line 150, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 150, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 599, but not defined == Missing Reference: 'READ-ONLY' is mentioned on line 588, but not defined == Missing Reference: 'UNSEEN 10268' is mentioned on line 694, but not defined == Missing Reference: 'UIDVALIDITY 890061587' is mentioned on line 695, but not defined == Missing Reference: 'UIDNEXT 34643' is mentioned on line 696, but not defined == Missing Reference: 'X' is mentioned on line 1401, but not defined == Unused Reference: 'I-D.ietf-imapext-condstore' is defined on line 1473, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 == Outdated reference: A later version (-08) exists of draft-melnikov-imap-ext-abnf-05 ** Obsolete normative reference: RFC 2086 (Obsoleted by RFC 4314) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-09) exists of draft-ietf-imapext-condstore-06 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group C. Daboo 3 Internet-Draft 4 Expires: May 25, 2006 R. Gellens 5 QUALCOMM Incorporated 6 November 21, 2005 8 IMAP ANNOTATE Extension 9 draft-ietf-imapext-annotate-14 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The ANNOTATE extension to the Internet Message Access Protocol 43 permits clients and servers to maintain "meta data" for messages, or 44 individual message parts, stored in a mailbox on the server. 46 Change History (to be removed prior to publication as an RFC) 48 Changes from -13 to -14: 50 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 51 for entry/attribute names. 52 2. Updated examples to match new astring syntax. 53 3. Now requires explicit use of .priv or .shared in SORT. 54 4. Removed requirement that 'n' right only be present if 'r' right 55 is also present. 56 5. Changed ANNOTATESIZE response to ANNOTATIONS response. 57 6. Allow servers to indicate that they do not support private 58 annotations. 59 7. Added example for extended SELECT including ANNOTATIONS response 60 code. 61 8. Removed content-type attribute. 62 9. Removed display-name attribute. 63 10. Prevent use of * and % wildcards in attributes. 64 11. Only allow "value" attributes in SEARCH. 65 12. Only allow "value" or "size" attributes in SORT. 66 13. Removed vendor attributes. 67 14. Removed IMAP flags, though the /flags entry path is reserved. 68 15. Added internationalization considerations. 70 Changes from -12 to -13: 71 1. Sync with change from DC meeting wrt 'r' right for both read and 72 write of .priv. 73 2. Add text about 'n' right being a 'shared flag right' as defined 74 in 2086upd. 75 3. Allow NIL in //flags entries. 76 4. Expand abstract to also indicate that annotations can apply on a 77 per-body part basis as well as per message. 78 5. Fix resp-text-code to use nil instead of "NIL". 79 6. Use double-quotes consistently around ANNOTATESIZE etc. 80 7. Fix typos. 81 8. Remove redundant second para of Introduction. 82 9. Added 'Conventions' section with RFC2119 reference.. 83 10. Describe S:, C: example behaviour in conventions section.. 84 11. Clarify that new rights must also be present if only old ACL is 85 present. 86 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 87 '.'. 88 13. Clarify default charset for content-type text/plain. 89 14. Recommend use of utf-8 for all non-ascii text. 90 15. Clarify terminology of ANNOTATESIZE response code. 91 16. Require servers to return ANNOTATESIZE on SELECT. 92 17. Change an example to use UID FETCH for variety. 93 18. Clarify what to do about annotations exceeding allowed 94 ANNOTATESIZE when doing copy. 95 19. Use ABNFext document for extended SELECT etc. 97 20. Remove RFC1891 reference. 98 21. capability syntax extension. 99 22. Comment on validation content-type attribute. 100 23. Added recommended content-type in IANA registration. 101 24. Added use of literal8 for values. 102 25. Prevent use of 'shared' and 'priv' as separate hierarchy 103 components. 104 26. Restrict entry/attribute names to ascii and added display-name 105 attribute. 106 27. Remove references to CATENATE and use ABNFext for extended 107 APPEND syntax. 109 Changes from -11 to -12: 110 1. Fixed raw XML in formal syntax. 111 2. Fixed double \ in IANA section titles. 112 3. Fixed APPEND formal syntax. 113 4. Added annotations to CATENATE extension. 114 5. Reworded text for unsolicited responses. 115 6. Fixed formal syntax for fetch responses to extend base spec item. 117 Changes from -10 to -11: 118 1. Flags are now read-only and exactly match their IMAP 119 counterparts. 120 2. Added new ACL bits for annotations. 121 3. Revise security considerations. 122 4. Fixed some references. 124 Changes from -09 to -10: 125 1. Added Content-Language value. 126 2. Added IANA registrations for entries/attributes in this document. 128 Changes from -08 to -09: 129 1. Fix formatting, ID nits etc. 130 2. Fix subject -> altsubject in examples. 131 3. Added text to SELECT/EXAMINE optional parameter definition to 132 indicate that the option could trigger a global state change or a 133 mailbox specific change. 134 4. Changed entry/attribute names to be case-sensitive to avoid case 135 mapping issues with utf8 text. 136 5. Clarify COPY interaction to indicate that only the current user's 137 '.priv's are copied, not the '.priv's of other users. 139 Changes from -07 to -08: 140 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 141 does not support any type of annotations, and "0" for a mailbox 142 that only supports read-only annotations. 144 Changes from -06 to -07: 146 1. Added text to state entry and attribute names are always case- 147 insensitive. 148 2. Removed top-level entry namespace. 149 3. Added server accept minima for annotation size and count. 150 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 151 5. Added [ANNOTATESIZE <>] response code. 152 6. Added comment on suggested CONDSTORE support. 153 7. Modified append behaviour to account for MULTIAPPEND. 154 8. Tweaked ABNF. 156 Changes from -05 to -06: 157 1. Split references into Normative and Informative. 158 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 159 name. 160 3. Removed smtp-envelope annotation - a future extension can add 161 this. 162 4. Changed subject to altsubject. 163 5. Added $MDNSent flag and reference to document. 164 6. Cleaned up formal syntax to use IMAP string type for entry and 165 attributes, with requirements on how the string is formatted. 166 7. Use of ACAP vendor subtree registry for vendor tokens. 167 8. Fixed STORE syntax. 169 Changes from -04 to -05: 170 1. Fixed examples to match formal syntax for FETCH responses where 171 parenthesis do not appear around entry-att items. 173 Changes from -03 to -04: 174 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 175 2. Add text for server to reject unknown . 176 3. Do not allow empty part-specifier. 177 4. Store NIL to value to delete. 178 5. Comment on COPY interaction with ANNOTATE. 179 6. Added comment that IMAP flags are mapped one-to-one with their 180 corresponding FLAGS items. 181 7. Added comment that the recent flag annotation is read-only. 183 Changes from -02 to -03: 184 1. Removed reference to status modtime item. 185 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 186 smtp-envelope. 187 3. Added requirement to store data permanently - no 'session only' 188 annotations. 189 4. Removed Access Control section. Replaced with comments on read- 190 only/read-write mailboxes and storing private or shared 191 annotations. 193 5. Removed STORE to default .priv or .shared. 194 6. Added section on optional select parameters. 196 Changes from -01 to -02: 197 1. Now require .priv or .shared on store operations. 199 Changes from -00 to -01: 200 1. MODTIME moved to its own draft, which this draft now depends on. 201 Thus, Conditional Annotation STORE and related items deleted from 202 this draft. 203 2. Private versus Shared Annotations: both are possible (separately 204 addressable using ".priv" and ".shared" suffixes). There is a 205 per-mailbox setting for the default. It is an open issue how 206 this is viewed or changed by the client. 207 3. In ACLs, the "w" right is needed to updated shared state; the "s" 208 right is needed to update private state. 209 4. Various clarifications and text modifications. 210 5. Added 'forwarded' flag for message parts. 212 Changes from pre-imapext to -00: 213 1. Clarified text describing attributions, entries, and attributes. 214 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 215 3. Deleted 'queued' flag. 216 4. Expanded and explained smtp-envelope entry. 217 5. Restricted including ANNOTATION data in unsolicited responses 218 until the client uses it first. (Open issue as to if needed). 219 6. Examples now only use valid entries and attributes. 220 7. Updated Security Considerations. 221 8. Content-Type now defaults to text/plain. 222 9. Open Issue: Shared vs. private annotations. 223 10. Open issue: Annotation Modtime untagged response or VALIDTIME 224 FETCH data. 225 11. Open issue: Conditional annotation STORE. 226 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 227 CAPABILITY command response. 228 13. Prohibition on annotations in lieu of base spec functionality. 229 14. Specified required ACL rights. 230 15. ANNOTATION message data item in APPEND. 231 16. ANNOTATION-MODTIME message data item in STATUS. 232 17. Replaced ATOM_CHAR with utf8-char. 233 18. Updated other ABNF entries. 235 Table of Contents 237 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 7 238 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 239 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 240 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 241 3.2. Namespace of entries and attributes . . . . . . . . . . . 8 242 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 9 243 3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 10 244 3.3. Private versus Shared . . . . . . . . . . . . . . . . . . 11 245 3.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 12 246 3.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 15 247 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 15 248 4.1. General Considerations . . . . . . . . . . . . . . . . . . 15 249 4.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 16 250 4.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 16 251 4.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 18 252 4.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 20 253 4.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 21 254 4.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22 255 4.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 22 256 4.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 23 257 4.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 24 258 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24 259 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 260 6.1. Entry and Attribute Registration Template . . . . . . . . 26 261 6.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 27 262 6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 27 263 6.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 27 264 6.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 28 265 6.2.4. //comment . . . . . . . . . . . . . . . 28 266 6.2.5. //flags/seen . . . . . . . . . . . . . . 29 267 6.2.6. //flags/answered . . . . . . . . . . . . 29 268 6.2.7. //flags/flagged . . . . . . . . . . . . 30 269 6.2.8. //flags/forwarded . . . . . . . . . . . 30 270 6.3. Attribute Registrations . . . . . . . . . . . . . . . . . 30 271 6.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 31 272 6.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 31 273 6.3.3. content-language . . . . . . . . . . . . . . . . . . . 32 274 7. Internationalization Considerations . . . . . . . . . . . . . 32 275 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 276 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 277 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 278 9.2. Informative References . . . . . . . . . . . . . . . . . . 33 279 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 280 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 281 Intellectual Property and Copyright Statements . . . . . . . . . . 35 283 1. Introduction and Overview 285 The ANNOTATE extension is present in any IMAP [RFC3501] 286 implementation which returns "ANNOTATE" as one of the supported 287 capabilities in the CAPABILITY response. 289 This extension makes the following changes to the IMAP protocol: 291 a. adds a new ANNOTATION message data item for use in FETCH 292 b. adds a new ANNOTATION message data item for use in STORE 293 c. adds a new ANNOTATION search criterion for use in SEARCH 294 d. adds a new ANNOTATION sort key for use in SORT extension 295 e. adds a new ANNOTATION data item for use in APPEND 296 f. adds a new requirement on the COPY command 297 g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE 298 commands 299 h. adds two new response codes to indicate store failures of 300 annotations. 301 i. adds a new untagged response code for the SELECT or EXAMINE 302 commands to indicate the maximum size. 303 j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] 304 and [I-D.ietf-imapext-2086upd] . 306 The data model used for the storage of annotations is based on that 307 of the Application Configuration Access Protocol [RFC2244]. Note 308 that there is no inheritance in annotations. 310 If a server supports annotations, then it MUST store all annotation 311 data permanently, i.e. there is no concept of "session only" 312 annotations that would correspond to the behaviour of "session" flags 313 as defined in the IMAP base specification. 315 In order to provide optimum support for a disconnected client (one 316 that needs to synchronise annotations for use when offline), servers 317 SHOULD also support the Conditional STORE [I-D.ietf-imapext- 318 condstore] extension. 320 The rest of this document describes the data model and protocol 321 changes more rigorously. 323 2. Conventions Used in This Document 325 In examples, "C:" and "S:" indicate lines sent by the client and 326 server respectively. 328 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 329 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 330 document are to be interpreted as described in [RFC2119]. 332 3. Data Model 334 3.1. Overview 336 The data model used in ANNOTATE is that of a uniquely named entry 337 which contains a set of standard attributes. A single coherent unit 338 of "meta data" for a message is stored as a single entry, made up of 339 several attributes. 341 For example, a comment annotation added to a message has an entry 342 name of "/comment". This entry is composed of several attributes 343 such as "value", "size", etc. which contain the properties and data 344 of the entry. 346 The protocol changes to IMAP described below allow a client to access 347 or change the values of any attributes in any entries in a message 348 annotation, assuming it has sufficient access rights to do so (see 349 Section 3.4 for specifics). 351 3.2. Namespace of entries and attributes 353 Each message annotation is made up of a set of entries. Each entry 354 has a hierarchical name, with each component of the name separated by 355 a slash ("/"). An entry name MUST NOT contain two consecutive "/" 356 characters and MUST NOT end with a "/" character. 358 Each entry is made up of a set of attributes. Each attribute has a 359 hierarchical name, with each component of the name separated by a 360 period ("."). An attribute name MUST NOT contain two consecutive "." 361 characters and MUST NOT end with a "." character. 363 The value of an attribute is "NIL" (has no value), or is a string of 364 zero or more octets. 366 Entry and attribute names MUST NOT contain asterisk ("*") or percent 367 ("%") characters and MUST NOT contain non-ASCII characters or the 368 NULL octet. Invalid entry or attribute names result in a BAD 369 response in any IMAP commands where they are used. 371 Attribute names MUST NOT contain any hierarchical components with the 372 names "priv" or "shared" as those have special meaning (see 373 Section 3.3. 375 Entry and attribute names are case-sensitive. 377 Use of control or punctuation characters in entry and attribute names 378 is strongly discouraged. 380 This specification defines an initial set of entry and attribute 381 names available for use in message annotations. In addition, an 382 extension mechanism is described to allow additional names to be 383 added as needed. 385 3.2.1. Entry Names 387 Entry names MUST be specified in a standards track or IESG approved 388 experimental RFC, or fall under the vendor namespace. See 389 Section 6.1 for the registration template. 391 / 392 Defines the top-level of entries associated with an entire 393 message. This entry itself does not contain any attributes. All 394 entries that start with a numeric character ("0" - "9") refer to 395 an annotation on a specific body part. All other entries are for 396 annotations on the entire message. 398 /comment 399 Defines a comment or note associated with an entire message. 401 /flags 402 This entry hierarchy is reserved for future use. 404 /altsubject 405 Contains text supplied by the message recipient, to be used by the 406 client instead of the original message Subject. 408 /vendor/ 409 Defines the top-level of entries associated with an entire message 410 as created by a particular product of some vendor. These sub- 411 entries can be used by vendors to provide client-specific 412 annotations. The vendor-token MUST be registered with IANA, using 413 the [RFC2244] vendor subtree registry. 415 / 416 Defines the top-level of entries associated with a specific body 417 part of a message. This entry itself does not contain any 418 attributes. The section-part uses the same numeric part specifier 419 syntax as the BODY message data item in the FETCH command 420 [RFC3501]. The server MUST return a BAD response if the client 421 uses an incorrect part specifier (either incorrect syntax or a 422 specifier referring to a non-existent part). The server MUST 423 return a BAD response if the client uses an empty part specifier 424 (which is used in IMAP to represent the entire message). 426 //comment 427 Defines a comment or note associated with a specific body part of 428 a message. 430 //flags 431 Defines the top-level of entries associated with flag state for a 432 specific body part of a message. All sub-entries are maintained 433 entirely by the client. There is no implicit change to any flag 434 by the server. 436 //flags/seen 437 //flags/answered 438 //flags/flagged 439 //flags/forwarded 441 Defines flags for a specific body part of a message. The "value" 442 attribute of each of the entries described above must be either 443 "1", "0" or "NIL". "1" corresponds to the flag being set. 445 //vendor/ 446 Defines the top-level of entries associated with a specific body 447 part of a message as created by a particular product of some 448 vendor. This entry can be used by vendors to provide client 449 specific annotations. The vendor-token MUST be registered with 450 IANA. 452 3.2.2. Attribute Names 454 Attribute names MUST be specified in a standards track or IESG 455 approved experimental RFC. See Section 6.1 for the registration 456 template. 458 All attribute names implicitly have a ".priv" and a ".shared" suffix 459 which maps to private and shared versions of the entry. Searching or 460 fetching without using either suffix includes both. The client MUST 461 specify either a ".priv" or ".shared" suffix when storing an 462 annotation. 464 value 465 A string or binary data representing the value of the annotation. 466 To delete an annotation, the client can store "NIL" into the 467 value. The content represented by the string is determined by the 468 Content-type used to register the entry (see Section 6.1 for entry 469 registration templates). Where applicable, the registered 470 content-type MUST include a charset parameter. Text values SHOULD 471 use the utf-8 [RFC3629] character set. 473 Note that binary data (data which may contain the NULL octet) is 474 allowed (e.g. for storing images etc), and this extension uses the 475 "literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow 476 such data to be written to or read from the server. 478 size 479 The size of the value, in octets. Set automatically by the 480 server, read-only to clients. 482 content-language 483 Indicates the language used for the value. This follows the 484 format described in [RFC3282]. Clients SHOULD set this value when 485 storing an annotation that uses text that can be presented to the 486 user. It is not required for enumerated or numeric values such as 487 flags etc. If a value is being set, clients MUST ensure that it 488 accurately reflects the content stored in the value attribute. 489 Servers MUST ensure that the "content-language" attribute value is 490 kept in synchronization with the "value" attribute. To ensure 491 that, the server MUST remove any "content-language" attribute 492 value when the client STOREs a "value" attribute without also 493 including a "content-language" attribute in the same STORE 494 command. 496 3.3. Private versus Shared 498 Some IMAP mailboxes are private, accessible only to the owning user. 499 Other mailboxes are not, either because the owner has set an ACL 500 [I-D.ietf-imapext-2086upd] which permits access by other users, or 501 because it is a shared mailbox. 503 This raises the issue of shared versus private annotations. 505 If all annotations are private, it is impossible to set annotations 506 in a shared or otherwise non-private mailbox that are visible to 507 other users. This eliminates what could be a useful aspect of 508 annotations in a shared environment. An example of such use is a 509 shared IMAP folder containing bug reports. Engineers may want to use 510 annotations to add information to existing messages, indicate 511 assignments, status, etc. This use requires shared annotations. 513 If all annotations are shared, it is impossible to use annotations 514 for private notes on messages in shared mailboxes. Also, modifying 515 an ACL to permit access to a mailbox by other users may 516 unintentionally expose private information. 518 There are also situations in which both shared and private 519 annotations are useful. For example, an administrator may want to 520 set shared annotations on messages in a shared folder, which 521 individual users may wish to supplement with additional notes. 523 If shared and private annotations are to coexist, we need a clear way 524 to differentiate them. Also, it should be as easy as possible for a 525 client to access both and not overlook either. There is also a 526 danger in allowing a client to store an annotation without knowing if 527 it is shared or private. 529 This document proposes two standard suffixes for all attributes: 530 ".shared" and ".priv". A SEARCH or FETCH command which specifies 531 neither uses both. STORE, APPEND and SORT commands MUST explicitly 532 use ".priv" or ".shared" suffixes. 534 If the ANNOTATE extension is present, support for shared annotations 535 in servers is REQUIRED, whilst support for private annotations in 536 servers is OPTIONAL. This recognises the fact that support for 537 private annotations may introduce significantly more complexity to a 538 server in terms of tracking ownership of the annotations, how quota 539 is determined for users based on their own annotations etc. Clients 540 that support the ANNOTATE extension MUST handle both shared and 541 private annotations. 543 3.4. Access Control 545 A user needs to have appropriate rights in order to read or write 546 ".priv" or ".shared" annotation values. How those rights are 547 calculated depends on whether the ACL [RFC2086] extension or its 548 update [I-D.ietf-imapext-2086upd] is present or not. If a client 549 attempts to store or fetch an annotation to which they do not have 550 the appropriate rights, the server MUST respond with a NO response. 552 When the ACL extension is not present, access to annotation values is 553 governed by the nature of the selected state. In particular whether 554 the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE 555 mode. 557 When the ACL extension is present, the server MUST recognise the new 558 ACL right "n", in addition to the ones defined by the ACL extension 559 itself. 561 The "r" right controls both read and write access to ".priv" 562 annotation values. When it is on, access to ".priv" annotations is 563 allowed, when it is off, access to ".priv" annotations is disallowed. 565 The "r" right controls only the read access for ".shared" annotation 566 values. When it is on, ".shared" annotations can be read, when it is 567 off, ".shared" annotations cannot be read. 569 The "n" right controls only the write access for ".shared" annotation 570 values. When it is on, ".shared" annotations can be changed or 571 created through either a STORE or APPEND command, when it is off, 572 ".shared" annotations cannot be changed or created. The "n" right 573 constitutes a "shared flag right" as defined in [I-D.ietf-imapext- 574 2086upd] Section 6.2. 576 A summary of all the access control restrictions is tabulated below 577 +---------------+---------------+-----------------------------------+ 578 | Server Type | Action on | Type of mailbox | 579 | | annotation | | 580 +===============+===============+===================================+ 581 | | | | 582 | | read .priv | Any mailbox that can be SELECTED | 583 | | values | or EXAMINED. | 584 | | | | 585 | +---------------+-----------------------------------+ 586 | | | | 587 | | write .priv | Any SELECTED [READ-WRITE] mailbox.| 588 | | values | SELECTED [READ-ONLY] mailboxes MAY| 589 | Server | | also permit writes. | 590 | without | | | 591 | ACL Extension +---------------+-----------------------------------+ 592 | | | | 593 | | read .shared | Any mailbox that can be SELECTED | 594 | | values | or EXAMINED. | 595 | | | | 596 | +---------------+-----------------------------------+ 597 | | | | 598 | | write .shared | Any mailbox that can be SELECTED | 599 | | values | or EXAMINED and is [READ-WRITE]. | 600 | | | | 601 +---------------+---------------+-----------------------------------+ 602 | | | | 603 | | read .priv | Any mailbox with the "r" | 604 | | values | ACL right. | 605 | | | | 606 | +---------------+-----------------------------------+ 607 | | | | 608 | | write .priv | Any mailbox with the "r" | 609 | Server | values | ACL right. | 610 | with | | | 611 | ACL Extension +---------------+-----------------------------------+ 612 | | | | 613 | | read .shared | Any mailbox with the "r" | 614 | | values | ACL right. | 615 | | | | 616 | +---------------+-----------------------------------+ 617 | | | | 618 | | write .shared | Any mailbox with the "n" | 619 | | values | ACL right. | 620 | | | | 621 +---------------+---------------+-----------------------------------+ 623 3.5. Access to Standard IMAP Flags and Keywords 625 Due to ambiguity of how private and shared values would map to the 626 base IMAP flag and keyword values, the ANNOTATE extension does not 627 expose IMAP flags or keywords as entries. However, the /flags 628 annotation entry is reserved for future use and MUST NOT be used by 629 clients or servers supporting this extension. 631 Clients that need to implement shared and private "flags" can create 632 their own annotation entries for those, completely bypassing the base 633 IMAP flag/keyword behaviour. 635 4. IMAP Protocol Changes 637 4.1. General Considerations 639 Servers may be able to offer only a limited level of support for 640 annotations in mailboxes, and it is useful for clients to be able to 641 know what level of support is available. Servers MUST return an 642 ANNOTATIONS response during the SELECT or EXAMINE command for a 643 mailbox to indicate the level of support. Possible response codes 644 used with the ANNOTATIONS response are: 646 "NONE" - this indicates that the mailbox being selected does not 647 support annotations at all. Clients MUST NOT attempt to use 648 annotation extensions in commands. 650 "READ-ONLY" - this indicates that the annotations supported by the 651 mailbox cannot be changed by the client. Clients MUST NOT attempt 652 to store annotations on any messages in a mailbox with this 653 response code. 655 "NOPRIVATE" - this indicates that the server does not support 656 private annotations on the mailbox. Only shared annotations are 657 supported. Clients SHOULD only attempt to read or store 658 annotations attributes with the ".shared" suffix. If a client 659 uses an attribute with the ".priv" suffix in a FETCH command, then 660 servers should return the attribute value in the FETCH response as 661 "NIL". If a client uses an attribute with the ".priv" suffix in a 662 STORE command (or an APPEND command targetted at the mailbox) then 663 the server MUST return a NO response. 665 numeric values - if servers support writable annotations, then the 666 server MUST indicate the maximum size for an annotation value by 667 providing the maximum size value in the response code. Clients 668 MUST NOT store annotation values of a size greater than the amount 669 indicated by the server. Servers MUST accept a minimum annotation 670 data size of at least 1024 bytes if annotations can be written. 672 In addition the server MAY limit the total number of annotations for 673 a single message. However, the server MUST provide a minimum 674 annotation count per message of at least 10. 676 4.2. ANNOTATE parameter with the SELECT/EXAMINE commands 678 The ANNOTATE extension defines a single optional SELECT parameter 679 [I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on 680 unsolicited responses for annotations as described in Section 4.4. 681 This optional parameter results in a per-mailbox state change, i.e. 682 it must be used in each SELECT/EXAMINE command in order to be 683 effective, irrespective of whether it was used in a previous SELECT/ 684 EXAMINE during the same session. 686 Example: 688 C: a SELECT INBOX ANNOTATE 689 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 690 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 691 \Deleted \Seen \*)] 692 S: * 10268 EXISTS 693 S: * 1 RECENT 694 S: * OK [UNSEEN 10268] 695 S: * OK [UIDVALIDITY 890061587] 696 S: * OK [UIDNEXT 34643] 697 S: * OK [ANNOTATIONS 20480 NOPRIVATE] 698 S: a OK [READ-WRITE] Completed 700 In the above example, a SELECT command with the ANNOTATE parameter 701 is issued. The response from the server includes the required 702 ANNOTATIONS response that indicates that the server supports 703 annotations up to a maximum size of 20480 bytes and does not 704 support private annotations (only shared). 706 4.3. ANNOTATION Message Data Item in FETCH Command 708 This extension adds an ANNOTATION message data item to the FETCH 709 command. This allows clients to retrieve annotations for a range of 710 messages in the currently selected mailbox. 712 ANNOTATION 714 The ANNOTATION message data item, when used by the client in the 715 FETCH command, takes an entry specifier and an attribute 716 specifier. 718 Example: 720 C: a FETCH 1 (ANNOTATION (/comment value)) 721 S: * 1 FETCH (ANNOTATION (/comment 722 (value.priv "My comment" 723 value.shared "Group note"))) 724 S: a OK Fetch complete 726 In the above example, the content of the "value" attribute for the 727 "/comment" entry is requested by the client and returned by the 728 server. Since neither ".shared" nor ".priv" was specified, both 729 are returned. 731 "*" and "%" wild card characters can be used in entry specifiers to 732 match one or more characters at that position, with the exception 733 that "%" does not match the "/" hierarchy delimiter. Thus an entry 734 specifier of "/%" matches entries such as "/comment" and 735 "/altsubject", but not "/1/comment". 737 Example: 739 C: a UID FETCH 1123 (UID ANNOTATION 740 (/* (value.priv size.priv))) 741 S: * 12 FETCH (UID 1123 ANNOTATION 742 (/comment (value.priv "My comment" 743 size.priv "10") 744 /altsubject (value.priv "Rhinoceroses!" 745 size.priv "13") 746 /vendor/foobar/label.priv 747 (value.priv "label43" 748 size.priv "7") 749 /vendor/foobar/personality 750 (value.priv "Tallulah Bankhead" 751 size.priv "17"))) 752 S: a OK Fetch complete 754 In the above example, the contents of the private "value" and 755 "size" attributes for any entries in the "/" hierarchy are 756 requested by the client and returned by the server. 758 Example: 760 C: a FETCH 1 (ANNOTATION (/% value.shared)) 761 S: * 1 FETCH (ANNOTATION 762 (/comment (value.shared "Patch Mangler") 763 /altsubject (value.shared "Patches? We don't 764 need no steenkin patches!"))) 765 S: a OK Fetch complete 767 In the above example, the contents of the shared "value" 768 attributes for entries at the top level only of the "/" hierarchy 769 are requested by the client and returned by the server. 771 Entry and attribute specifiers can be lists of atomic specifiers, so 772 that multiple items of each type may be returned in a single FETCH 773 command. 775 Example: 777 C: a FETCH 1 (ANNOTATION 778 ((/comment /altsubject) value.priv)) 779 S: * 1 FETCH (ANNOTATION 780 (/comment (value.priv "What a chowder-head") 781 /altsubject (value.priv "How to crush beer cans"))) 782 S: a OK Fetch complete 784 In the above example, the contents of the private "value" 785 attributes for the two entries "/comment" and "/altsubject" are 786 requested by the client and returned by the server. 788 4.4. ANNOTATION Message Data Item in FETCH Response 790 The ANNOTATION message data item in the FETCH response displays 791 information about annotations in a message. 793 ANNOTATION parenthesised list 795 The response consists of a list of entries, each of which has a 796 list of attribute-value pairs. 798 Example: 800 C: a FETCH 1 (ANNOTATION (/comment value)) 801 S: * 1 FETCH (ANNOTATION (/comment 802 (value.priv "My comment" 803 value.shared NIL))) 804 S: a OK Fetch complete 806 In the above example, a single entry with a single attribute-value 807 pair is returned by the server. Since the client did not specify 808 a ".shared" or ".priv" suffix, both are returned. Only the 809 private attribute has a value (the shared value is "NIL"). 811 Example: 813 C: a FETCH 1 (ANNOTATION 814 ((/comment /altsubject) value)) 815 S: * 1 FETCH (ANNOTATION 816 (/comment (value.priv "My comment" 817 value.shared NIL) 818 /altsubject (value.priv "My subject" 819 value.shared NIL))) 820 S: a OK Fetch complete 822 In the above example, two entries each with a single attribute- 823 value pair are returned by the server. Since the client did not 824 specify a ".shared" or ".priv" suffix, both are returned. Only 825 the private attributes have values; the shared attributes are 826 "NIL". 828 Example: 830 C: a FETCH 1 (ANNOTATION 831 (/comment (value size))) 832 S: * 1 FETCH (ANNOTATION 833 (/comment 834 (value.priv "My comment" 835 value.shared NIL 836 size.priv "10" 837 size.shared "0"))) 838 S: a OK Fetch complete 840 In the above example, a single entry with two attribute-value 841 pairs is returned by the server. Since the client did not specify 842 a ".shared" or ".priv" suffix, both are returned. Only the 843 private attributes have values; the shared attributes are "NIL". 845 Servers SHOULD send ANNOTATION message data items in unsolicited 846 FETCH responses if an annotation entry is changed by a third-party, 847 and the ANNOTATE select parameter was used. This allows servers to 848 keep clients updated with changes to annotations by other clients. 850 Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data 851 values - only the entry name of the ANNOTATION that has changed. 852 This restriction avoids sending ANNOTATION data values (which may be 853 large) to a client unless the client explicitly asks for the value. 855 Example: 857 C: a STORE 1 +FLAGS (\Seen) 858 S: * 1 FETCH (FLAGS (\Seen)) 859 ANNOTATION (/comment)) 860 S: a OK STORE complete 862 In the above example, an unsolicited ANNOTATION response is 863 returned during a STORE command. The unsolicited response 864 contains only the entry name of the annotation that changed, and 865 not its value. 867 4.5. ANNOTATION Message Data Item in STORE 869 ANNOTATION 871 Sets the specified list of entries by adding or replacing the 872 specified attributes with the values provided. Clients can use 873 "NIL" for values of attributes it wants to remove from entries. 875 The ANNOTATION message data item used with the STORE command has an 876 implicit ".SILENT" behaviour. This means the server does not 877 generate an untagged FETCH in response to the STORE command and 878 assumes that the client updates its own cache if the command 879 succeeds. 881 If the server is unable to store an annotation because the size of 882 its value is too large, the server MUST return a tagged NO response 883 with a "[ANNOTATE TOOBIG]" response code. 885 If the server is unable to store a new annotation because the maximum 886 number of allowed annotations has already been reached, the server 887 MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response 888 code. 890 Example: 892 C: a STORE 1 ANNOTATION (/comment 893 (value.priv "My new comment")) 894 S: a OK Store complete 896 In the above example, the entry "/comment" is created (if not 897 already present) and the private attribute "value" with data set 898 to "My new comment" is created if not already present, or replaced 899 if it exists. 901 Example: 903 C: a STORE 1 ANNOTATION (/comment 904 (value.shared NIL)) 905 S: a OK Store complete 907 In the above example, the shared "value" attribute of the entry 908 "/comment" is removed by storing "NIL" into the attribute. 910 Multiple entries can be set in a single STORE command by listing 911 entry-attribute-value pairs in the list. 913 Example: 915 C: a STORE 1 ANNOTATION (/comment 916 (value.priv "Get tix Tuesday") 917 /altsubject 918 (value.priv "Wots On")) 919 S: a OK Store complete 921 In the above example, the entries "/comment" and "/altsubject" are 922 created (if not already present) and the private attribute "value" 923 is created for each entry if not already present, or replaced if 924 they exist. 926 Multiple attributes can be set in a single STORE command by listing 927 multiple attribute-value pairs in the entry list. 929 Example: 931 C: a STORE 1 ANNOTATION (/comment 932 (value.priv "My new comment" 933 value.shared "foo's bar")) 934 S: a OK Store complete 936 In the above example, the entry "/comment" is created (if not already 937 present) and the private and shared "value" attributes are created if 938 not already present, or replaced if they exist. 940 4.6. ANNOTATION interaction with COPY 942 The COPY command can be used to move messages from one mailbox to 943 another on the same server. Servers that support the ANNOTATION 944 extension MUST, for each message being copied, copy all ".priv" 945 annotation data for the current user only, and all ".shared" 946 annotation data along with the message to the new mailbox. The only 947 exceptions to this are if the destination mailbox permissions are 948 such that either the ".priv" or ".shared" annotations are not 949 allowed, or if the destination mailbox is of a type that does not 950 support annotations or does not support storing of annotations (a 951 mailbox that returns a "NONE" or "READ-ONLY" response code in its 952 ANNOTATIONS response), or if the destination mailbox cannot support 953 the size of a annotation because it exceeds the ANNOTATIONS value. 954 Servers MUST NOT copy ".priv" annotation data for users other than 955 the current user. 957 4.7. ANNOTATION Message Data Item in APPEND 959 ANNOTATION 961 Sets the specified list of entries and attributes in the resulting 962 message. 964 The APPEND command can include annotations for the message being 965 appended via the addition of a new append data item [I-D.melnikov- 966 imap-ext-abnf]. The new data item can also be used with the multi- 967 append [RFC3502] extension that allows multiple messages to be 968 appended via a single APPEND command. 970 Example: 972 C: a APPEND drafts ANNOTATION (/comment 973 (value.priv "Don't send until I say so")) {310} 974 S: + Ready for literal data 975 C: MIME-Version: 1.0 976 ... 977 C: 978 S: a OK APPEND completed 980 In the above example, a comment with a private value is added to a 981 new message appended to the mailbox. The ellipsis represents the 982 bulk of the message. 984 4.8. ANNOTATION Criterion in SEARCH 986 ANNOTATION 988 The ANNOTATION criterion for the SEARCH command allows a client to 989 search for a specified string in the value of an annotation entry of 990 a message. 992 Messages that have annotations with entries matching and 993 attributes matching and the specified string 994 in their values are returned in the SEARCH results. The "*" 995 character can be used in the entry name field to match any content in 996 those items. The "%" character can be used in the entry name field 997 to match a single level of hierarchy only. 999 Only the "value", "value.priv" and "value.shared" attributes can be 1000 searched. Clients MUST NOT specify an attribute other than either 1001 "value", "value.priv" or "value.shared". Servers MUST return a BAD 1002 response if the client tries to search any other attribute. 1004 Example: 1006 C: a SEARCH ANNOTATION /comment value "IMAP4" 1007 S: * SEARCH 2 3 5 7 11 13 17 19 23 1008 S: a OK Search complete 1010 In the above example, the message numbers of any messages 1011 containing the string "IMAP4" in the shared or private "value" 1012 attribute of the "/comment" entry are returned in the search 1013 results. 1015 Example: 1017 C: a SEARCH ANNOTATION * value.priv "IMAP4" 1018 S: * SEARCH 1 2 3 5 8 13 21 34 1019 S: a OK Search complete 1021 In the above example, the message numbers of any messages 1022 containing the string "IMAP4" in the private "value" attribute of 1023 any entry are returned in the search results. 1025 4.9. ANNOTATION Key in SORT 1027 ANNOTATION 1029 The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort] 1030 instructs the server to return the message numbers or UIDs of a 1031 mailbox, sorted using the values of the specified annotations. The 1032 ANNOTATION criterion is available if the server returns both ANNOTATE 1033 and SORT as supported capabilities in the CAPABILITY command 1034 response. 1036 Messages are sorted using the values of the 1037 attributes in the entries. 1039 Clients MUST provide either the ".priv" or ".shared" suffix to the 1040 attribute name to ensure that the server knows which specific value 1041 to sort on. 1043 Only the "value.priv", "value.shared", "size.priv" and "size.shared" 1044 attributes can be used for sorting. Clients MUST NOT specify an 1045 attribute other than either "value.priv", "value.shared", "size.priv" 1046 or "size.shared". Servers MUST return a BAD response if the client 1047 tries to search any other attribute. 1049 When either "value.priv" or "value.shared" is being sorted, the 1050 server MUST use the character set value specified in the SORT command 1051 to determine the appropriate sort order. 1053 When either "size.priv" or "size.shared" is being sorted, the server 1054 sorts using the numeric values of those attributes, as it would when 1055 the "SIZE" sort key is used. 1057 Example: 1059 C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL 1060 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 1061 S: a OK Sort complete 1063 In the above example, the message numbers of all messages are 1064 returned, sorted according to the shared "value" attribute of the 1065 "/altsubject" entry. 1067 Note that the ANNOTATION sort key must include a fully specified 1068 entry - wild cards are not allowed. 1070 4.10. New ACL Rights 1072 As discussed in Section 3.4 this extension adds a new "n" right to 1073 the list of rights provided by the ACL extensions [RFC2086] and 1074 [I-D.ietf-imapext-2086upd]. 1076 5. Formal Syntax 1078 The following syntax specification uses the Augmented Backus-Naur 1079 Form (ABNF) notation as specified in [RFC2234]. 1081 Non-terminals referenced but not defined below are as defined by 1082 [RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf] 1083 superseding those in [RFC3501]. 1085 Except as noted otherwise, all alphabetic characters are case- 1086 insensitive. The use of upper or lower case characters to define 1087 token strings is for editorial clarity only. Implementations MUST 1088 accept these strings in a case-insensitive fashion. 1090 ann-size = "NONE" / 1091 (("READ-ONLY" / nz-size) 1092 [SP "NOPRIVATE"]) 1093 ; response codes indicating the level of 1094 ; support for annotations in a mailbox 1096 append-ext =/ att-annotate 1097 ; modifies [RFC3501] extension behaviour 1099 att-annotate = "ANNOTATION" SP 1100 "(" entry-att *(SP entry-att) ")" 1102 att-search = "value" / "value.priv" / "value.shared" 1103 ; the only attributes that can be searched 1105 att-sort = "value.priv" / "value.shared" / 1106 "size.priv" / "size.shared" 1107 ; the only attributes that can be sorted 1109 att-value = attrib SP value 1111 attrib = astring 1112 ; dot-separated attribute name 1113 ; MUST NOT contain "*" or "%" 1115 attribs = attrib / "(" attrib *(SP attrib) ")" 1116 ; one or more attribute specifiers 1118 capability =/ "ANNOTATE" 1119 ; defines the capability for this extension 1121 entries = entry-match / 1122 "(" entry-match *(SP entry-match) ")" 1124 entry = astring 1125 ; slash-separated path to entry 1126 ; MUST NOT contain "*" or "%" 1128 entry-att = entry SP "(" att-value *(SP att-value) ")" 1130 entry-match = list-mailbox 1131 ; slash-separated path to entry 1132 ; MAY contain "*" or "%" for use as wild cards 1134 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 1135 ; modifies original IMAP fetch-att 1137 msg-att-dynamic =/ "ANNOTATION" SP 1138 ( "(" entry-att *(SP entry-att) ")" / 1139 "(" entry *(SP entry) ")" ) 1140 ; extends FETCH response with annotation data 1142 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 1143 "ANNOTATE" SP "TOOMANY" / 1144 "ANNOTATIONS" SP ann-size 1145 ; new response codes 1147 search-key =/ "ANNOTATION" SP entry-match SP att-search 1148 SP value 1149 ; modifies original IMAP search-key 1151 select-param =/ "ANNOTATE" 1152 ; defines the select parameter used with 1153 ; ANNOTATE extension 1155 sort-key =/ "ANNOTATION" SP entry SP att-sort 1156 ; modifies original sort-key 1158 store-att-flags =/ att-annotate 1159 ; modifies original IMAP STORE command 1161 value = nstring / literal8 1163 6. IANA Considerations 1165 Entry names MUST be specified in a standards track or IESG approved 1166 experimental RFC, or fall under the vendor namespace. Vendor names 1167 MUST be registered. 1169 Attribute names MUST be specified in a standards track or IESG 1170 approved experimental RFC. 1172 Each entry registration MUST include a content-type that is used to 1173 indicate the nature of the annotation value. Where applicable a 1174 charset parameter MUST be included with the content-type. 1176 6.1. Entry and Attribute Registration Template 1178 To: iana@iana.org 1179 Subject: IMAP Annotate Registration 1181 Please register the following IMAP Annotate item: 1183 [] Entry [] Attribute 1185 Name: ______________________________ 1187 Description: _______________________ 1189 ____________________________________ 1191 ____________________________________ 1193 Content-Type:_______________________ 1195 Contact person: ____________________ 1196 email: ____________________ 1198 6.2. Entry Registrations 1200 The following templates specify the IANA registrations of annotation 1201 entries specified in this document. 1203 6.2.1. /comment 1205 To: iana@iana.org 1206 Subject: IMAP Annotate Registration 1208 Please register the following IMAP Annotate item: 1210 [X] Entry [] Attribute 1212 Name: /comment 1214 Description: Defined in IMAP ANNOTATE extension document. 1216 Content-Type: text/plain; charset=utf-8 1218 Contact person: Cyrus Daboo 1220 email: cyrus@daboo.name 1222 6.2.2. /flags 1224 To: iana@iana.org 1225 Subject: IMAP Annotate Registration 1227 Please register the following IMAP Annotate item: 1229 [X] Entry [] Attribute 1231 Name: /flags 1233 Description: Reserved entry hierarchy. 1235 Content-Type: - 1237 Contact person: Cyrus Daboo 1239 email: cyrus@daboo.name 1241 6.2.3. /altsubject 1243 To: iana@iana.org 1244 Subject: IMAP Annotate Registration 1246 Please register the following IMAP Annotate item: 1248 [X] Entry [] Attribute 1250 Name: /altsubject 1252 Description: Defined in IMAP ANNOTATE extension document. 1254 Content-Type: text/plain; charset=utf-8 1256 Contact person: Cyrus Daboo 1258 email: cyrus@daboo.name 1260 6.2.4. //comment 1262 To: iana@iana.org 1263 Subject: IMAP Annotate Registration 1265 Please register the following IMAP Annotate item: 1267 [X] Entry [] Attribute 1269 Name: //comment 1271 Description: Defined in IMAP ANNOTATE extension document. 1273 Content-Type: text/plain; charset=utf-8 1275 Contact person: Cyrus Daboo 1277 email: cyrus@daboo.name 1279 6.2.5. //flags/seen 1281 To: iana@iana.org 1282 Subject: IMAP Annotate Registration 1284 Please register the following IMAP Annotate item: 1286 [X] Entry [] Attribute 1288 Name: //flags/seen 1290 Description: Defined in IMAP ANNOTATE extension document. 1292 Content-Type: text/plain; charset=utf-8 1294 Contact person: Cyrus Daboo 1296 email: cyrus@daboo.name 1298 6.2.6. //flags/answered 1300 To: iana@iana.org 1301 Subject: IMAP Annotate Registration 1303 Please register the following IMAP Annotate item: 1305 [X] Entry [] Attribute 1307 Name: //flags/answered 1309 Description: Defined in IMAP ANNOTATE extension document. 1311 Content-Type: text/plain; charset=utf-8 1313 Contact person: Cyrus Daboo 1315 email: cyrus@daboo.name 1317 6.2.7. //flags/flagged 1319 To: iana@iana.org 1320 Subject: IMAP Annotate Registration 1322 Please register the following IMAP Annotate item: 1324 [X] Entry [] Attribute 1326 Name: //flags/flagged 1328 Description: Defined in IMAP ANNOTATE extension document. 1330 Content-Type: text/plain; charset=utf-8 1332 Contact person: Cyrus Daboo 1334 email: cyrus@daboo.name 1336 6.2.8. //flags/forwarded 1338 To: iana@iana.org 1339 Subject: IMAP Annotate Registration 1341 Please register the following IMAP Annotate item: 1343 [X] Entry [] Attribute 1345 Name: //flags/forwarded 1347 Description: Defined in IMAP ANNOTATE extension document. 1349 Content-Type: text/plain; charset=utf-8 1351 Contact person: Cyrus Daboo 1353 email: cyrus@daboo.name 1355 6.3. Attribute Registrations 1357 The following templates specify the IANA registrations of annotation 1358 attributes specified in this document. 1360 6.3.1. value 1362 To: iana@iana.org 1363 Subject: IMAP Annotate Registration 1365 Please register the following IMAP Annotate item: 1367 [] Entry [X] Attribute 1369 Name: value 1371 Description: Defined in IMAP ANNOTATE extension document. 1373 Contact person: Cyrus Daboo 1375 email: cyrus@daboo.name 1377 6.3.2. size 1379 To: iana@iana.org 1380 Subject: IMAP Annotate Registration 1382 Please register the following IMAP Annotate item: 1384 [] Entry [X] Attribute 1386 Name: size 1388 Description: Defined in IMAP ANNOTATE extension document. 1390 Contact person: Cyrus Daboo 1392 email: cyrus@daboo.name 1394 6.3.3. content-language 1396 To: iana@iana.org 1397 Subject: IMAP Annotate Registration 1399 Please register the following IMAP Annotate item: 1401 [] Entry [X] Attribute 1403 Name: content-language 1405 Description: Defined in IMAP ANNOTATE extension document. 1407 Contact person: Cyrus Daboo 1409 email: cyrus@daboo.name 1411 7. Internationalization Considerations 1413 Annotations may contain values that include text strings, and both 1414 searching and sorting are possible with annotations. Servers MUST 1415 follow standard IMAP text normalization, character set conversion and 1416 collation rules when such operations are acarried out, as they would 1417 for other textual fields being searched or sorted on. 1419 8. Security Considerations 1421 Annotations whose values are intended to remain private MUST be 1422 stored in ".priv" values, and not ".shared" values which may be 1423 accessible to other users. 1425 Excluding the above issues the ANNOTATE extension does not raise any 1426 security considerations that are not present in the base IMAP 1427 protocol, and these issues are discussed in [RFC3501]. 1429 9. References 1431 9.1. Normative References 1433 [I-D.ietf-imapext-2086upd] 1434 Melnikov, A., "IMAP4 ACL extension", 1435 draft-ietf-imapext-2086upd-08 (work in progress), 1436 June 2005. 1438 [I-D.ietf-imapext-sort] 1439 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1440 PROTOCOL - SORT AND THREAD EXTENSION", 1441 draft-ietf-imapext-sort-17 (work in progress), May 2004. 1443 [I-D.melnikov-imap-ext-abnf] 1444 Daboo, C. and A. Melnikov, "Collected extensions to IMAP4 1445 ABNF", draft-melnikov-imap-ext-abnf-05 (work in progress), 1446 October 2005. 1448 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1451 Requirement Levels", BCP 14, RFC 2119, March 1997. 1453 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1454 Specifications: ABNF", RFC 2234, November 1997. 1456 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1457 Configuration Access Protocol", RFC 2244, November 1997. 1459 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1460 May 2002. 1462 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1463 4rev1", RFC 3501, March 2003. 1465 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1466 MULTIAPPEND Extension", RFC 3502, March 2003. 1468 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1469 10646", STD 63, RFC 3629, November 2003. 1471 9.2. Informative References 1473 [I-D.ietf-imapext-condstore] 1474 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1475 STORE operation", draft-ietf-imapext-condstore-06 (work in 1476 progress), October 2005. 1478 Appendix A. Acknowledgments 1480 Many thanks to Chris Newman for his detailed comments on the first 1481 draft of this document, and to the participants at the ACAP working 1482 dinner in Pittsburgh. The participants of the IMAPext working group 1483 made significant contributions to this work. 1485 Authors' Addresses 1487 Cyrus Daboo 1489 Email: cyrus@daboo.name 1491 Randall Gellens 1492 QUALCOMM Incorporated 1493 5775 Morehouse Dr. 1494 San Diego, CA 92121-2779 1495 US 1497 Email: randy@qualcomm.com 1499 Intellectual Property Statement 1501 The IETF takes no position regarding the validity or scope of any 1502 Intellectual Property Rights or other rights that might be claimed to 1503 pertain to the implementation or use of the technology described in 1504 this document or the extent to which any license under such rights 1505 might or might not be available; nor does it represent that it has 1506 made any independent effort to identify any such rights. Information 1507 on the procedures with respect to rights in RFC documents can be 1508 found in BCP 78 and BCP 79. 1510 Copies of IPR disclosures made to the IETF Secretariat and any 1511 assurances of licenses to be made available, or the result of an 1512 attempt made to obtain a general license or permission for the use of 1513 such proprietary rights by implementers or users of this 1514 specification can be obtained from the IETF on-line IPR repository at 1515 http://www.ietf.org/ipr. 1517 The IETF invites any interested party to bring to its attention any 1518 copyrights, patents or patent applications, or other proprietary 1519 rights that may cover technology that may be required to implement 1520 this standard. Please address the information to the IETF at 1521 ietf-ipr@ietf.org. 1523 Disclaimer of Validity 1525 This document and the information contained herein are provided on an 1526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1528 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1529 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1530 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1533 Copyright Statement 1535 Copyright (C) The Internet Society (2005). This document is subject 1536 to the rights, licenses and restrictions contained in BCP 78, and 1537 except as set forth therein, the authors retain all their rights. 1539 Acknowledgment 1541 Funding for the RFC Editor function is currently provided by the 1542 Internet Society.