idnits 2.17.1 draft-ietf-imapext-annotate-15.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 1518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1508. ** 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 (March 28, 2006) is 6576 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 161, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 161, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 613, but not defined == Missing Reference: 'READ-ONLY' is mentioned on line 602, but not defined == Missing Reference: 'UNSEEN 10268' is mentioned on line 708, but not defined == Missing Reference: 'UIDVALIDITY 890061587' is mentioned on line 709, but not defined == Missing Reference: 'UIDNEXT 34643' is mentioned on line 710, but not defined == Missing Reference: 'X' is mentioned on line 1393, but not defined == Unused Reference: 'I-D.ietf-imapext-condstore' is defined on line 1460, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 ** 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) Summary: 7 errors (**), 0 flaws (~~), 12 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: September 29, 2006 R. Gellens 5 QUALCOMM Incorporated 6 March 28, 2006 8 IMAP ANNOTATE Extension 9 draft-ietf-imapext-annotate-15 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 September 29, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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. For 45 example, this can be used to attach comments and other useful 46 information to a message. It is also possible to attach annotations 47 to specific parts of a message, so that, for example, they could be 48 marked as seen or important, or a comment added. 50 Change History (to be removed prior to publication as an RFC) 52 Changes from -14 to -15: 53 1. Updated to rfc 4314 reference. 54 2. Removed Content-Language value and reference. 55 3. Added statement about experimental status. 56 4. Changed to experimental capability name. 57 5. Removed ability to sort on size attribute. 58 6. Expanded abstract. 60 Changes from -13 to -14: 61 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 62 for entry/attribute names. 63 2. Updated examples to match new astring syntax. 64 3. Now requires explicit use of .priv or .shared in SORT. 65 4. Removed requirement that 'n' right only be present if 'r' right 66 is also present. 67 5. Changed ANNOTATESIZE response to ANNOTATIONS response. 68 6. Allow servers to indicate that they do not support private 69 annotations. 70 7. Added example for extended SELECT including ANNOTATIONS response 71 code. 72 8. Removed content-type attribute. 73 9. Removed display-name attribute. 74 10. Prevent use of * and % wildcards in attributes. 75 11. Only allow "value" attributes in SEARCH. 76 12. Only allow "value" or "size" attributes in SORT. 77 13. Removed vendor attributes. 78 14. Removed IMAP flags, though the /flags entry path is reserved. 79 15. Added internationalization considerations. 81 Changes from -12 to -13: 82 1. Sync with change from DC meeting wrt 'r' right for both read and 83 write of .priv. 84 2. Add text about 'n' right being a 'shared flag right' as defined 85 in 2086upd. 86 3. Allow NIL in //flags entries. 87 4. Expand abstract to also indicate that annotations can apply on a 88 per-body part basis as well as per message. 89 5. Fix resp-text-code to use nil instead of "NIL". 90 6. Use double-quotes consistently around ANNOTATESIZE etc. 91 7. Fix typos. 92 8. Remove redundant second para of Introduction. 93 9. Added 'Conventions' section with RFC2119 reference.. 94 10. Describe S:, C: example behaviour in conventions section.. 95 11. Clarify that new rights must also be present if only old ACL is 96 present. 98 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 99 '.'. 100 13. Clarify default charset for content-type text/plain. 101 14. Recommend use of utf-8 for all non-ascii text. 102 15. Clarify terminology of ANNOTATESIZE response code. 103 16. Require servers to return ANNOTATESIZE on SELECT. 104 17. Change an example to use UID FETCH for variety. 105 18. Clarify what to do about annotations exceeding allowed 106 ANNOTATESIZE when doing copy. 107 19. Use ABNFext document for extended SELECT etc. 108 20. Remove RFC1891 reference. 109 21. capability syntax extension. 110 22. Comment on validation content-type attribute. 111 23. Added recommended content-type in IANA registration. 112 24. Added use of literal8 for values. 113 25. Prevent use of 'shared' and 'priv' as separate hierarchy 114 components. 115 26. Restrict entry/attribute names to ascii and added display-name 116 attribute. 117 27. Remove references to CATENATE and use ABNFext for extended 118 APPEND syntax. 120 Changes from -11 to -12: 121 1. Fixed raw XML in formal syntax. 122 2. Fixed double \ in IANA section titles. 123 3. Fixed APPEND formal syntax. 124 4. Added annotations to CATENATE extension. 125 5. Reworded text for unsolicited responses. 126 6. Fixed formal syntax for fetch responses to extend base spec item. 128 Changes from -10 to -11: 129 1. Flags are now read-only and exactly match their IMAP 130 counterparts. 131 2. Added new ACL bits for annotations. 132 3. Revise security considerations. 133 4. Fixed some references. 135 Changes from -09 to -10: 136 1. Added Content-Language value. 137 2. Added IANA registrations for entries/attributes in this document. 139 Changes from -08 to -09: 140 1. Fix formatting, ID nits etc. 141 2. Fix subject -> altsubject in examples. 142 3. Added text to SELECT/EXAMINE optional parameter definition to 143 indicate that the option could trigger a global state change or a 144 mailbox specific change. 146 4. Changed entry/attribute names to be case-sensitive to avoid case 147 mapping issues with utf8 text. 148 5. Clarify COPY interaction to indicate that only the current user's 149 '.priv's are copied, not the '.priv's of other users. 151 Changes from -07 to -08: 152 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 153 does not support any type of annotations, and "0" for a mailbox 154 that only supports read-only annotations. 156 Changes from -06 to -07: 157 1. Added text to state entry and attribute names are always case- 158 insensitive. 159 2. Removed top-level entry namespace. 160 3. Added server accept minima for annotation size and count. 161 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 162 5. Added [ANNOTATESIZE <>] response code. 163 6. Added comment on suggested CONDSTORE support. 164 7. Modified append behaviour to account for MULTIAPPEND. 165 8. Tweaked ABNF. 167 Changes from -05 to -06: 168 1. Split references into Normative and Informative. 169 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 170 name. 171 3. Removed smtp-envelope annotation - a future extension can add 172 this. 173 4. Changed subject to altsubject. 174 5. Added $MDNSent flag and reference to document. 175 6. Cleaned up formal syntax to use IMAP string type for entry and 176 attributes, with requirements on how the string is formatted. 177 7. Use of ACAP vendor subtree registry for vendor tokens. 178 8. Fixed STORE syntax. 180 Changes from -04 to -05: 181 1. Fixed examples to match formal syntax for FETCH responses where 182 parenthesis do not appear around entry-att items. 184 Changes from -03 to -04: 185 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 186 2. Add text for server to reject unknown . 187 3. Do not allow empty part-specifier. 188 4. Store NIL to value to delete. 189 5. Comment on COPY interaction with ANNOTATE. 190 6. Added comment that IMAP flags are mapped one-to-one with their 191 corresponding FLAGS items. 193 7. Added comment that the recent flag annotation is read-only. 195 Changes from -02 to -03: 196 1. Removed reference to status modtime item. 197 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 198 smtp-envelope. 199 3. Added requirement to store data permanently - no 'session only' 200 annotations. 201 4. Removed Access Control section. Replaced with comments on read- 202 only/read-write mailboxes and storing private or shared 203 annotations. 204 5. Removed STORE to default .priv or .shared. 205 6. Added section on optional select parameters. 207 Changes from -01 to -02: 208 1. Now require .priv or .shared on store operations. 210 Changes from -00 to -01: 211 1. MODTIME moved to its own draft, which this draft now depends on. 212 Thus, Conditional Annotation STORE and related items deleted from 213 this draft. 214 2. Private versus Shared Annotations: both are possible (separately 215 addressable using ".priv" and ".shared" suffixes). There is a 216 per-mailbox setting for the default. It is an open issue how 217 this is viewed or changed by the client. 218 3. In ACLs, the "w" right is needed to updated shared state; the "s" 219 right is needed to update private state. 220 4. Various clarifications and text modifications. 221 5. Added 'forwarded' flag for message parts. 223 Changes from pre-imapext to -00: 224 1. Clarified text describing attributions, entries, and attributes. 225 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 226 3. Deleted 'queued' flag. 227 4. Expanded and explained smtp-envelope entry. 228 5. Restricted including ANNOTATION data in unsolicited responses 229 until the client uses it first. (Open issue as to if needed). 230 6. Examples now only use valid entries and attributes. 231 7. Updated Security Considerations. 232 8. Content-Type now defaults to text/plain. 233 9. Open Issue: Shared vs. private annotations. 234 10. Open issue: Annotation Modtime untagged response or VALIDTIME 235 FETCH data. 236 11. Open issue: Conditional annotation STORE. 237 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 238 CAPABILITY command response. 240 13. Prohibition on annotations in lieu of base spec functionality. 241 14. Specified required ACL rights. 242 15. ANNOTATION message data item in APPEND. 243 16. ANNOTATION-MODTIME message data item in STATUS. 244 17. Replaced ATOM_CHAR with utf8-char. 245 18. Updated other ABNF entries. 247 Table of Contents 249 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 8 250 2. Working Group Note on Status . . . . . . . . . . . . . . . . . 8 251 3. Conventions Used in This Document . . . . . . . . . . . . . . 9 252 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 253 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 254 4.2. Namespace of entries and attributes . . . . . . . . . . . 9 255 4.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 10 256 4.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 12 257 4.3. Private versus Shared . . . . . . . . . . . . . . . . . . 12 258 4.4. Access Control . . . . . . . . . . . . . . . . . . . . . . 13 259 4.5. Access to Standard IMAP Flags and Keywords . . . . . . . . 16 260 5. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 16 261 5.1. General Considerations . . . . . . . . . . . . . . . . . . 16 262 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands . . . 17 263 5.3. ANNOTATION Message Data Item in FETCH Command . . . . . . 17 264 5.4. ANNOTATION Message Data Item in FETCH Response . . . . . . 19 265 5.5. ANNOTATION Message Data Item in STORE . . . . . . . . . . 21 266 5.6. ANNOTATION interaction with COPY . . . . . . . . . . . . . 22 267 5.7. ANNOTATION Message Data Item in APPEND . . . . . . . . . . 23 268 5.8. ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23 269 5.9. ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 24 270 5.10. New ACL Rights . . . . . . . . . . . . . . . . . . . . . . 25 271 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25 272 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 273 7.1. Entry and Attribute Registration Template . . . . . . . . 27 274 7.2. Entry Registrations . . . . . . . . . . . . . . . . . . . 28 275 7.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 28 276 7.2.2. /flags . . . . . . . . . . . . . . . . . . . . . . . . 28 277 7.2.3. /altsubject . . . . . . . . . . . . . . . . . . . . . 29 278 7.2.4. //comment . . . . . . . . . . . . . . . 29 279 7.2.5. //flags/seen . . . . . . . . . . . . . . 30 280 7.2.6. //flags/answered . . . . . . . . . . . . 30 281 7.2.7. //flags/flagged . . . . . . . . . . . . 31 282 7.2.8. //flags/forwarded . . . . . . . . . . . 31 283 7.3. Attribute Registrations . . . . . . . . . . . . . . . . . 31 284 7.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 32 285 7.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 32 286 8. Internationalization Considerations . . . . . . . . . . . . . 32 287 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 288 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 289 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 290 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 291 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 292 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 293 Intellectual Property and Copyright Statements . . . . . . . . . . 36 295 1. Introduction and Overview 297 The ANNOTATE extension is present in any IMAP [RFC3501] 298 implementation which returns "ANNOTATE-EXPERIMENT-1" as one of the 299 supported capabilities in the CAPABILITY response. 301 This extension makes the following changes to the IMAP protocol: 303 a. adds a new ANNOTATION message data item for use in FETCH 304 b. adds a new ANNOTATION message data item for use in STORE 305 c. adds a new ANNOTATION search criterion for use in SEARCH 306 d. adds a new ANNOTATION sort key for use in SORT extension 307 e. adds a new ANNOTATION data item for use in APPEND 308 f. adds a new requirement on the COPY command 309 g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE 310 commands 311 h. adds two new response codes to indicate store failures of 312 annotations. 313 i. adds a new untagged response code for the SELECT or EXAMINE 314 commands to indicate the maximum size. 315 j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] 316 and [RFC4314] . 318 The data model used for the storage of annotations is based on that 319 of the Application Configuration Access Protocol [RFC2244]. Note 320 that there is no inheritance in annotations. 322 If a server supports annotations, then it MUST store all annotation 323 data permanently, i.e. there is no concept of "session only" 324 annotations that would correspond to the behaviour of "session" flags 325 as defined in the IMAP base specification. 327 In order to provide optimum support for a disconnected client (one 328 that needs to synchronise annotations for use when offline), servers 329 SHOULD also support the Conditional STORE [I-D.ietf-imapext- 330 condstore] extension. 332 The rest of this document describes the data model and protocol 333 changes more rigorously. 335 2. Working Group Note on Status 337 The IMAP Extensions Working Group, which produced this specification, 338 has felt it important to first gain implementation experience with 339 this specification before submitting it as a 'proposed standard' for 340 more general deployment, and therefore suggests that it be published 341 as Experimental. As such the Working Group strongly encourages 342 implementers to implement this specification as-is and provide their 343 valuable feedback on any problems or issues found when doing that or 344 when attempting to interoperate with other products. 346 Implementers should be aware that this specification may change in an 347 incompatible manner when going to 'proposed standard' status. 348 However, any incompatible changes will result in a new capability 349 name being used to prevent problems with any deployments of the 350 experimental extension. 352 3. Conventions Used in This Document 354 In examples, "C:" and "S:" indicate lines sent by the client and 355 server respectively. 357 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 358 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 359 document are to be interpreted as described in [RFC2119]. 361 4. Data Model 363 4.1. Overview 365 The data model used in ANNOTATE is that of a uniquely named entry 366 which contains a set of standard attributes. A single coherent unit 367 of "meta data" for a message is stored as a single entry, made up of 368 several attributes. 370 For example, a comment annotation added to a message has an entry 371 name of "/comment". This entry is composed of several attributes 372 such as "value", "size", etc. which contain the properties and data 373 of the entry. 375 The protocol changes to IMAP described below allow a client to access 376 or change the values of any attributes in any entries in a message 377 annotation, assuming it has sufficient access rights to do so (see 378 Section 4.4 for specifics). 380 4.2. Namespace of entries and attributes 382 Each message annotation is made up of a set of entries. Each entry 383 has a hierarchical name, with each component of the name separated by 384 a slash ("/"). An entry name MUST NOT contain two consecutive "/" 385 characters and MUST NOT end with a "/" character. 387 Each entry is made up of a set of attributes. Each attribute has a 388 hierarchical name, with each component of the name separated by a 389 period ("."). An attribute name MUST NOT contain two consecutive "." 390 characters and MUST NOT end with a "." character. 392 The value of an attribute is "NIL" (has no value), or is a string of 393 zero or more octets. 395 Entry and attribute names MUST NOT contain asterisk ("*") or percent 396 ("%") characters and MUST NOT contain non-ASCII characters or the 397 NULL octet. Invalid entry or attribute names result in a BAD 398 response in any IMAP commands where they are used. 400 Attribute names MUST NOT contain any hierarchical components with the 401 names "priv" or "shared" as those have special meaning (see 402 Section 4.3). 404 Entry and attribute names are case-sensitive. 406 Use of control or punctuation characters in entry and attribute names 407 is strongly discouraged. 409 This specification defines an initial set of entry and attribute 410 names available for use in message annotations. In addition, an 411 extension mechanism is described to allow additional names to be 412 added as needed. 414 4.2.1. Entry Names 416 Entry names MUST be specified in a standards track or IESG approved 417 experimental RFC, or fall under the vendor namespace. See 418 Section 7.1 for the registration template. 420 / 421 Defines the top-level of entries associated with an entire 422 message. This entry itself does not contain any attributes. All 423 entries that start with a numeric character ("0" - "9") refer to 424 an annotation on a specific body part. All other entries are for 425 annotations on the entire message. 427 /comment 428 Defines a comment or note associated with an entire message. 430 /flags 431 This entry hierarchy is reserved for future use. 433 /altsubject 434 Contains text supplied by the message recipient, to be used by the 435 client instead of the original message Subject. 437 /vendor/ 438 Defines the top-level of entries associated with an entire message 439 as created by a particular product of some vendor. These sub- 440 entries can be used by vendors to provide client-specific 441 annotations. The vendor-token MUST be registered with IANA, using 442 the [RFC2244] vendor subtree registry. 444 / 445 Defines the top-level of entries associated with a specific body 446 part of a message. This entry itself does not contain any 447 attributes. The section-part uses the same numeric part specifier 448 syntax as the BODY message data item in the FETCH command 449 [RFC3501]. The server MUST return a BAD response if the client 450 uses an incorrect part specifier (either incorrect syntax or a 451 specifier referring to a non-existent part). The server MUST 452 return a BAD response if the client uses an empty part specifier 453 (which is used in IMAP to represent the entire message). 455 //comment 456 Defines a comment or note associated with a specific body part of 457 a message. 459 //flags 460 Defines the top-level of entries associated with flag state for a 461 specific body part of a message. All sub-entries are maintained 462 entirely by the client. There is no implicit change to any flag 463 by the server. 465 //flags/seen 466 //flags/answered 467 //flags/flagged 468 //flags/forwarded 470 Defines flags for a specific body part of a message. The "value" 471 attribute of each of the entries described above must be either 472 "1", "0" or "NIL". "1" corresponds to the flag being set. 474 //vendor/ 475 Defines the top-level of entries associated with a specific body 476 part of a message as created by a particular product of some 477 vendor. This entry can be used by vendors to provide client 478 specific annotations. The vendor-token MUST be registered with 479 IANA. 481 4.2.2. Attribute Names 483 Attribute names MUST be specified in a standards track or IESG 484 approved experimental RFC. See Section 7.1 for the registration 485 template. 487 All attribute names implicitly have a ".priv" and a ".shared" suffix 488 which maps to private and shared versions of the entry. Searching or 489 fetching without using either suffix includes both. The client MUST 490 specify either a ".priv" or ".shared" suffix when storing an 491 annotation or sorting on annotations. 493 value 494 A string or binary data representing the value of the annotation. 495 To delete an annotation, the client can store "NIL" into the 496 value. The content represented by the string is determined by the 497 content-type used to register the entry (see Section 7.1 for entry 498 registration templates). Where applicable, the registered 499 content-type MUST include a charset parameter. Text values SHOULD 500 use the utf-8 [RFC3629] character set. 501 Note that binary data (data which may contain the NULL octet) is 502 allowed (e.g. for storing images etc), and this extension uses the 503 "literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow 504 such data to be written to or read from the server. 506 size 507 The size of the value, in octets. Set automatically by the 508 server, read-only to clients. 510 4.3. Private versus Shared 512 Some IMAP mailboxes are private, accessible only to the owning user. 513 Other mailboxes are not, either because the owner has set an ACL 514 [RFC4314] which permits access by other users, or because it is a 515 shared mailbox. 517 This raises the issue of shared versus private annotations. 519 If all annotations are private, it is impossible to set annotations 520 in a shared or otherwise non-private mailbox that are visible to 521 other users. This eliminates what could be a useful aspect of 522 annotations in a shared environment. An example of such use is a 523 shared IMAP folder containing bug reports. Engineers may want to use 524 annotations to add information to existing messages, indicate 525 assignments, status, etc. This use requires shared annotations. 527 If all annotations are shared, it is impossible to use annotations 528 for private notes on messages in shared mailboxes. Also, modifying 529 an ACL to permit access to a mailbox by other users may 530 unintentionally expose private information. 532 There are also situations in which both shared and private 533 annotations are useful. For example, an administrator may want to 534 set shared annotations on messages in a shared folder, which 535 individual users may wish to supplement with additional notes. 537 If shared and private annotations are to coexist, we need a clear way 538 to differentiate them. Also, it should be as easy as possible for a 539 client to access both and not overlook either. There is also a 540 danger in allowing a client to store an annotation without knowing if 541 it is shared or private. 543 This document proposes two standard suffixes for all attributes: 544 ".shared" and ".priv". A SEARCH or FETCH command which specifies 545 neither uses both. STORE, APPEND and SORT commands MUST explicitly 546 use ".priv" or ".shared" suffixes. 548 If the ANNOTATE extension is present, support for shared annotations 549 in servers is REQUIRED, whilst support for private annotations in 550 servers is OPTIONAL. This recognises the fact that support for 551 private annotations may introduce significantly more complexity to a 552 server in terms of tracking ownership of the annotations, how quota 553 is determined for users based on their own annotations etc. Clients 554 that support the ANNOTATE extension MUST handle both shared and 555 private annotations. 557 4.4. Access Control 559 A user needs to have appropriate rights in order to read or write 560 ".priv" or ".shared" annotation values. How those rights are 561 calculated depends on whether the ACL [RFC2086] extension or its 562 update [RFC4314] is present or not. If a client attempts to store or 563 fetch an annotation to which they do not have the appropriate rights, 564 the server MUST respond with a NO response. 566 When the ACL extension is not present, access to annotation values is 567 governed by the nature of the selected state. In particular whether 568 the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE 569 mode. 571 When the ACL extension is present, the server MUST recognise the new 572 ACL right "n", in addition to the ones defined by the ACL extension 573 itself. 575 The "r" right controls both read and write access to ".priv" 576 annotation values. When it is on, access to ".priv" annotations is 577 allowed, when it is off, access to ".priv" annotations is disallowed. 579 The "r" right controls only the read access for ".shared" annotation 580 values. When it is on, ".shared" annotations can be read, when it is 581 off, ".shared" annotations cannot be read. 583 The "n" right controls only the write access for ".shared" annotation 584 values. When it is on, ".shared" annotations can be changed or 585 created through either a STORE or APPEND command, when it is off, 586 ".shared" annotations cannot be changed or created. The "n" right 587 constitutes a "shared flag right" as defined in [RFC4314] Section 588 6.2. 590 A summary of all the access control restrictions is tabulated below 591 +---------------+---------------+-----------------------------------+ 592 | Server Type | Action on | Type of mailbox | 593 | | annotation | | 594 +===============+===============+===================================+ 595 | | | | 596 | | read .priv | Any mailbox that can be SELECTED | 597 | | values | or EXAMINED. | 598 | | | | 599 | +---------------+-----------------------------------+ 600 | | | | 601 | | write .priv | Any SELECTED [READ-WRITE] mailbox.| 602 | | values | SELECTED [READ-ONLY] mailboxes MAY| 603 | Server | | also permit writes. | 604 | without | | | 605 | ACL Extension +---------------+-----------------------------------+ 606 | | | | 607 | | read .shared | Any mailbox that can be SELECTED | 608 | | values | or EXAMINED. | 609 | | | | 610 | +---------------+-----------------------------------+ 611 | | | | 612 | | write .shared | Any mailbox that can be SELECTED | 613 | | values | or EXAMINED and is [READ-WRITE]. | 614 | | | | 615 +---------------+---------------+-----------------------------------+ 616 | | | | 617 | | read .priv | Any mailbox with the "r" | 618 | | values | ACL right. | 619 | | | | 620 | +---------------+-----------------------------------+ 621 | | | | 622 | | write .priv | Any mailbox with the "r" | 623 | Server | values | ACL right. | 624 | with | | | 625 | ACL Extension +---------------+-----------------------------------+ 626 | | | | 627 | | read .shared | Any mailbox with the "r" | 628 | | values | ACL right. | 629 | | | | 630 | +---------------+-----------------------------------+ 631 | | | | 632 | | write .shared | Any mailbox with the "n" | 633 | | values | ACL right. | 634 | | | | 635 +---------------+---------------+-----------------------------------+ 637 4.5. Access to Standard IMAP Flags and Keywords 639 Due to ambiguity of how private and shared values would map to the 640 base IMAP flag and keyword values, the ANNOTATE extension does not 641 expose IMAP flags or keywords as entries. However, the /flags 642 annotation entry is reserved for future use and MUST NOT be used by 643 clients or servers supporting this extension. 645 Clients that need to implement shared and private "flags" can create 646 their own annotation entries for those, completely bypassing the base 647 IMAP flag/keyword behaviour. 649 5. IMAP Protocol Changes 651 5.1. General Considerations 653 Servers may be able to offer only a limited level of support for 654 annotations in mailboxes, and it is useful for clients to be able to 655 know what level of support is available. Servers MUST return an 656 ANNOTATIONS response during the SELECT or EXAMINE command for a 657 mailbox to indicate the level of support. Possible response codes 658 used with the ANNOTATIONS response are: 660 "NONE" - this indicates that the mailbox being selected does not 661 support annotations at all. Clients MUST NOT attempt to use 662 annotation extensions in commands. 664 "READ-ONLY" - this indicates that the annotations supported by the 665 mailbox cannot be changed by the client. Clients MUST NOT attempt 666 to store annotations on any messages in a mailbox with this 667 response code. 669 "NOPRIVATE" - this indicates that the server does not support 670 private annotations on the mailbox. Only shared annotations are 671 supported. Clients SHOULD only attempt to read or store 672 annotations attributes with the ".shared" suffix. If a client 673 uses an attribute with the ".priv" suffix in a FETCH command, then 674 servers should return the attribute value in the FETCH response as 675 "NIL". If a client uses an attribute with the ".priv" suffix in a 676 STORE command (or an APPEND command targetted at the mailbox) then 677 the server MUST return a NO response. 679 numeric values - if servers support writable annotations, then the 680 server MUST indicate the maximum size for an annotation value by 681 providing the maximum size value in the response code. Clients 682 MUST NOT store annotation values of a size greater than the amount 683 indicated by the server. Servers MUST accept a minimum annotation 684 data size of at least 1024 bytes if annotations can be written. 686 In addition the server MAY limit the total number of annotations for 687 a single message. However, the server MUST provide a minimum 688 annotation count per message of at least 10. 690 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands 692 The ANNOTATE extension defines a single optional SELECT parameter 693 [I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on 694 unsolicited responses for annotations as described in Section 5.4. 695 This optional parameter results in a per-mailbox state change, i.e. 696 it must be used in each SELECT/EXAMINE command in order to be 697 effective, irrespective of whether it was used in a previous SELECT/ 698 EXAMINE during the same session. 700 Example: 702 C: a SELECT INBOX (ANNOTATE) 703 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 704 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 705 \Deleted \Seen \*)] 706 S: * 10268 EXISTS 707 S: * 1 RECENT 708 S: * OK [UNSEEN 10268] 709 S: * OK [UIDVALIDITY 890061587] 710 S: * OK [UIDNEXT 34643] 711 S: * OK [ANNOTATIONS 20480 NOPRIVATE] 712 S: a OK [READ-WRITE] Completed 714 In the above example, a SELECT command with the ANNOTATE parameter 715 is issued. The response from the server includes the required 716 ANNOTATIONS response that indicates that the server supports 717 annotations up to a maximum size of 20480 bytes and does not 718 support private annotations (only shared). 720 5.3. ANNOTATION Message Data Item in FETCH Command 722 This extension adds an ANNOTATION message data item to the FETCH 723 command. This allows clients to retrieve annotations for a range of 724 messages in the currently selected mailbox. 726 ANNOTATION 728 The ANNOTATION message data item, when used by the client in the 729 FETCH command, takes an entry specifier and an attribute 730 specifier. 732 Example: 734 C: a FETCH 1 (ANNOTATION (/comment value)) 735 S: * 1 FETCH (ANNOTATION (/comment 736 (value.priv "My comment" 737 value.shared "Group note"))) 738 S: a OK Fetch complete 740 In the above example, the content of the "value" attribute for the 741 "/comment" entry is requested by the client and returned by the 742 server. Since neither ".shared" nor ".priv" was specified, both 743 are returned. 745 "*" and "%" wild card characters can be used in entry specifiers to 746 match one or more characters at that position, with the exception 747 that "%" does not match the "/" hierarchy delimiter. Thus an entry 748 specifier of "/%" matches entries such as "/comment" and 749 "/altsubject", but not "/1/comment". 751 Example: 753 C: a UID FETCH 1123 (UID ANNOTATION 754 (/* (value.priv size.priv))) 755 S: * 12 FETCH (UID 1123 ANNOTATION 756 (/comment (value.priv "My comment" 757 size.priv "10") 758 /altsubject (value.priv "Rhinoceroses!" 759 size.priv "13") 760 /vendor/foobar/label.priv 761 (value.priv "label43" 762 size.priv "7") 763 /vendor/foobar/personality 764 (value.priv "Tallulah Bankhead" 765 size.priv "17"))) 766 S: a OK Fetch complete 768 In the above example, the contents of the private "value" and 769 "size" attributes for any entries in the "/" hierarchy are 770 requested by the client and returned by the server. 772 Example: 774 C: a FETCH 1 (ANNOTATION (/% value.shared)) 775 S: * 1 FETCH (ANNOTATION 776 (/comment (value.shared "Patch Mangler") 777 /altsubject (value.shared "Patches? We don't 778 need no steenkin patches!"))) 779 S: a OK Fetch complete 781 In the above example, the contents of the shared "value" 782 attributes for entries at the top level only of the "/" hierarchy 783 are requested by the client and returned by the server. 785 Entry and attribute specifiers can be lists of atomic specifiers, so 786 that multiple items of each type may be returned in a single FETCH 787 command. 789 Example: 791 C: a FETCH 1 (ANNOTATION 792 ((/comment /altsubject) value.priv)) 793 S: * 1 FETCH (ANNOTATION 794 (/comment (value.priv "What a chowder-head") 795 /altsubject (value.priv "How to crush beer cans"))) 796 S: a OK Fetch complete 798 In the above example, the contents of the private "value" 799 attributes for the two entries "/comment" and "/altsubject" are 800 requested by the client and returned by the server. 802 5.4. ANNOTATION Message Data Item in FETCH Response 804 The ANNOTATION message data item in the FETCH response displays 805 information about annotations in a message. 807 ANNOTATION parenthesised list 809 The response consists of a list of entries, each of which has a 810 list of attribute-value pairs. 812 Example: 814 C: a FETCH 1 (ANNOTATION (/comment value)) 815 S: * 1 FETCH (ANNOTATION (/comment 816 (value.priv "My comment" 817 value.shared NIL))) 818 S: a OK Fetch complete 820 In the above example, a single entry with a single attribute-value 821 pair is returned by the server. Since the client did not specify 822 a ".shared" or ".priv" suffix, both are returned. Only the 823 private attribute has a value (the shared value is "NIL"). 825 Example: 827 C: a FETCH 1 (ANNOTATION 828 ((/comment /altsubject) value)) 829 S: * 1 FETCH (ANNOTATION 830 (/comment (value.priv "My comment" 831 value.shared NIL) 832 /altsubject (value.priv "My subject" 833 value.shared NIL))) 834 S: a OK Fetch complete 836 In the above example, two entries each with a single attribute- 837 value pair are returned by the server. Since the client did not 838 specify a ".shared" or ".priv" suffix, both are returned. Only 839 the private attributes have values; the shared attributes are 840 "NIL". 842 Example: 844 C: a FETCH 1 (ANNOTATION 845 (/comment (value size))) 846 S: * 1 FETCH (ANNOTATION 847 (/comment 848 (value.priv "My comment" 849 value.shared NIL 850 size.priv "10" 851 size.shared "0"))) 852 S: a OK Fetch complete 854 In the above example, a single entry with two attribute-value 855 pairs is returned by the server. Since the client did not specify 856 a ".shared" or ".priv" suffix, both are returned. Only the 857 private attributes have values; the shared attributes are "NIL". 859 Servers SHOULD send ANNOTATION message data items in unsolicited 860 FETCH responses if an annotation entry is changed by a third-party, 861 and the ANNOTATE select parameter was used. This allows servers to 862 keep clients updated with changes to annotations by other clients. 864 Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data 865 values - only the entry name of the ANNOTATION that has changed. 866 This restriction avoids sending ANNOTATION data values (which may be 867 large) to a client unless the client explicitly asks for the value. 869 Example: 871 C: a STORE 1 +FLAGS (\Seen) 872 S: * 1 FETCH (FLAGS (\Seen)) 873 ANNOTATION (/comment)) 874 S: a OK STORE complete 876 In the above example, an unsolicited ANNOTATION response is 877 returned during a STORE command. The unsolicited response 878 contains only the entry name of the annotation that changed, and 879 not its value. 881 5.5. ANNOTATION Message Data Item in STORE 883 ANNOTATION 885 Sets the specified list of entries by adding or replacing the 886 specified attributes with the values provided. Clients can use 887 "NIL" for values of attributes it wants to remove from entries. 889 The ANNOTATION message data item used with the STORE command has an 890 implicit ".SILENT" behaviour. This means the server does not 891 generate an untagged FETCH in response to the STORE command and 892 assumes that the client updates its own cache if the command 893 succeeds. 895 If the server is unable to store an annotation because the size of 896 its value is too large, the server MUST return a tagged NO response 897 with a "[ANNOTATE TOOBIG]" response code. 899 If the server is unable to store a new annotation because the maximum 900 number of allowed annotations has already been reached, the server 901 MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response 902 code. 904 Example: 906 C: a STORE 1 ANNOTATION (/comment 907 (value.priv "My new comment")) 908 S: a OK Store complete 910 In the above example, the entry "/comment" is created (if not 911 already present) and the private attribute "value" with data set 912 to "My new comment" is created if not already present, or replaced 913 if it exists. 915 Example: 917 C: a STORE 1 ANNOTATION (/comment 918 (value.shared NIL)) 919 S: a OK Store complete 921 In the above example, the shared "value" attribute of the entry 922 "/comment" is removed by storing "NIL" into the attribute. 924 Multiple entries can be set in a single STORE command by listing 925 entry-attribute-value pairs in the list. 927 Example: 929 C: a STORE 1 ANNOTATION (/comment 930 (value.priv "Get tix Tuesday") 931 /altsubject 932 (value.priv "Wots On")) 933 S: a OK Store complete 935 In the above example, the entries "/comment" and "/altsubject" are 936 created (if not already present) and the private attribute "value" 937 is created for each entry if not already present, or replaced if 938 they exist. 940 Multiple attributes can be set in a single STORE command by listing 941 multiple attribute-value pairs in the entry list. 943 Example: 945 C: a STORE 1 ANNOTATION (/comment 946 (value.priv "My new comment" 947 value.shared "foo's bar")) 948 S: a OK Store complete 950 In the above example, the entry "/comment" is created (if not already 951 present) and the private and shared "value" attributes are created if 952 not already present, or replaced if they exist. 954 5.6. ANNOTATION interaction with COPY 956 The COPY command can be used to move messages from one mailbox to 957 another on the same server. Servers that support the ANNOTATION 958 extension MUST, for each message being copied, copy all ".priv" 959 annotation data for the current user only, and all ".shared" 960 annotation data along with the message to the new mailbox. The only 961 exceptions to this are if the destination mailbox permissions are 962 such that either the ".priv" or ".shared" annotations are not 963 allowed, or if the destination mailbox is of a type that does not 964 support annotations or does not support storing of annotations (a 965 mailbox that returns a "NONE" or "READ-ONLY" response code in its 966 ANNOTATIONS response), or if the destination mailbox cannot support 967 the size of a annotation because it exceeds the ANNOTATIONS value. 968 Servers MUST NOT copy ".priv" annotation data for users other than 969 the current user. 971 5.7. ANNOTATION Message Data Item in APPEND 973 ANNOTATION 975 Sets the specified list of entries and attributes in the resulting 976 message. 978 The APPEND command can include annotations for the message being 979 appended via the addition of a new append data item [I-D.melnikov- 980 imap-ext-abnf]. The new data item can also be used with the multi- 981 append [RFC3502] extension that allows multiple messages to be 982 appended via a single APPEND command. 984 Example: 986 C: a APPEND drafts ANNOTATION (/comment 987 (value.priv "Don't send until I say so")) {310} 988 S: + Ready for literal data 989 C: MIME-Version: 1.0 990 ... 991 C: 992 S: a OK APPEND completed 994 In the above example, a comment with a private value is added to a 995 new message appended to the mailbox. The ellipsis represents the 996 bulk of the message. 998 5.8. ANNOTATION Criterion in SEARCH 1000 ANNOTATION 1002 The ANNOTATION criterion for the SEARCH command allows a client to 1003 search for a specified string in the value of an annotation entry of 1004 a message. 1006 Messages that have annotations with entries matching and 1007 attributes matching and the specified string 1008 in their values are returned in the SEARCH results. The "*" 1009 character can be used in the entry name field to match any content in 1010 those items. The "%" character can be used in the entry name field 1011 to match a single level of hierarchy only. 1013 Only the "value", "value.priv" and "value.shared" attributes can be 1014 searched. Clients MUST NOT specify an attribute other than either 1015 "value", "value.priv" or "value.shared". Servers MUST return a BAD 1016 response if the client tries to search any other attribute. 1018 Example: 1020 C: a SEARCH ANNOTATION /comment value "IMAP4" 1021 S: * SEARCH 2 3 5 7 11 13 17 19 23 1022 S: a OK Search complete 1024 In the above example, the message numbers of any messages 1025 containing the string "IMAP4" in the shared or private "value" 1026 attribute of the "/comment" entry are returned in the search 1027 results. 1029 Example: 1031 C: a SEARCH ANNOTATION * value.priv "IMAP4" 1032 S: * SEARCH 1 2 3 5 8 13 21 34 1033 S: a OK Search complete 1035 In the above example, the message numbers of any messages 1036 containing the string "IMAP4" in the private "value" attribute of 1037 any entry are returned in the search results. 1039 5.9. ANNOTATION Key in SORT 1041 ANNOTATION 1043 The ANNOTATION criterion for the SORT command [I-D.ietf-imapext-sort] 1044 instructs the server to return the message numbers or UIDs of a 1045 mailbox, sorted using the values of the specified annotations. The 1046 ANNOTATION criterion is available if the server returns both 1047 ANNOTATE-EXPERIMENT-1 and SORT as supported capabilities in the 1048 CAPABILITY command response. 1050 Messages are sorted using the values of the 1051 attributes in the entries. 1053 Clients MUST provide either the ".priv" or ".shared" suffix to the 1054 attribute name to ensure that the server knows which specific value 1055 to sort on. 1057 Only the "value.priv" and "value.shared" attributes can be used for 1058 sorting. Clients MUST NOT specify an attribute other than either 1059 "value.priv" or "value.shared". Servers MUST return a BAD response 1060 if the client tries to search any other attribute. 1062 When either "value.priv" or "value.shared" is being sorted, the 1063 server MUST use the character set value specified in the SORT command 1064 to determine the appropriate sort order. 1066 Example: 1068 C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL 1069 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 1070 S: a OK Sort complete 1072 In the above example, the message numbers of all messages are 1073 returned, sorted according to the shared "value" attribute of the 1074 "/altsubject" entry. 1076 Note that the ANNOTATION sort key must include a fully specified 1077 entry - wild cards are not allowed. 1079 5.10. New ACL Rights 1081 As discussed in Section 4.4 this extension adds a new "n" right to 1082 the list of rights provided by the ACL extensions [RFC2086] and 1083 [RFC4314]. 1085 6. Formal Syntax 1087 The following syntax specification uses the Augmented Backus-Naur 1088 Form (ABNF) notation as specified in [RFC2234]. 1090 Non-terminals referenced but not defined below are as defined by 1091 [RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf] 1092 superseding those in [RFC3501]. 1094 Except as noted otherwise, all alphabetic characters are case- 1095 insensitive. The use of upper or lower case characters to define 1096 token strings is for editorial clarity only. Implementations MUST 1097 accept these strings in a case-insensitive fashion. 1099 ann-size = "NONE" / 1100 (("READ-ONLY" / nz-size) 1101 [SP "NOPRIVATE"]) 1102 ; response codes indicating the level of 1103 ; support for annotations in a mailbox 1105 append-ext =/ att-annotate 1106 ; modifies [RFC3501] extension behaviour 1108 att-annotate = "ANNOTATION" SP 1109 "(" entry-att *(SP entry-att) ")" 1111 att-search = "value" / "value.priv" / "value.shared" 1112 ; the only attributes that can be searched 1114 att-sort = "value.priv" / "value.shared" 1115 ; the only attributes that can be sorted 1117 att-value = attrib SP value 1119 attrib = astring 1120 ; dot-separated attribute name 1121 ; MUST NOT contain "*" or "%" 1123 attribs = attrib / "(" attrib *(SP attrib) ")" 1124 ; one or more attribute specifiers 1126 capability =/ "ANNOTATE-EXPERIMENT-1" 1127 ; defines the capability for this extension 1129 entries = entry-match / 1130 "(" entry-match *(SP entry-match) ")" 1132 entry = astring 1133 ; slash-separated path to entry 1134 ; MUST NOT contain "*" or "%" 1136 entry-att = entry SP "(" att-value *(SP att-value) ")" 1138 entry-match = list-mailbox 1139 ; slash-separated path to entry 1140 ; MAY contain "*" or "%" for use as wild cards 1142 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 1143 ; modifies original IMAP fetch-att 1145 msg-att-dynamic =/ "ANNOTATION" SP 1146 ( "(" entry-att *(SP entry-att) ")" / 1147 "(" entry *(SP entry) ")" ) 1148 ; extends FETCH response with annotation data 1150 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 1151 "ANNOTATE" SP "TOOMANY" / 1152 "ANNOTATIONS" SP ann-size 1153 ; new response codes 1155 search-key =/ "ANNOTATION" SP entry-match SP att-search 1156 SP value 1157 ; modifies original IMAP search-key 1159 select-param =/ "ANNOTATE" 1160 ; defines the select parameter used with 1161 ; ANNOTATE extension 1163 sort-key =/ "ANNOTATION" SP entry SP att-sort 1164 ; modifies original sort-key 1166 store-att-flags =/ att-annotate 1167 ; modifies original IMAP STORE command 1169 value = nstring / literal8 1171 7. IANA Considerations 1173 Entry names MUST be specified in a standards track or IESG approved 1174 experimental RFC, or fall under the vendor namespace. Vendor names 1175 MUST be registered. 1177 Attribute names MUST be specified in a standards track or IESG 1178 approved experimental RFC. 1180 Each entry registration MUST include a content-type that is used to 1181 indicate the nature of the annotation value. Where applicable a 1182 charset parameter MUST be included with the content-type. 1184 7.1. Entry and Attribute Registration Template 1186 To: iana@iana.org 1187 Subject: IMAP Annotate Registration 1189 Please register the following IMAP Annotate item: 1191 [] Entry [] Attribute 1193 Name: ______________________________ 1195 Description: _______________________ 1197 ____________________________________ 1199 ____________________________________ 1201 Content-Type:_______________________ 1203 Contact person: ____________________ 1205 email: ____________________ 1207 7.2. Entry Registrations 1209 The following templates specify the IANA registrations of annotation 1210 entries specified in this document. 1212 7.2.1. /comment 1214 To: iana@iana.org 1215 Subject: IMAP Annotate Registration 1217 Please register the following IMAP Annotate item: 1219 [X] Entry [] Attribute 1221 Name: /comment 1223 Description: Defined in IMAP ANNOTATE extension document. 1225 Content-Type: text/plain; charset=utf-8 1227 Contact person: Cyrus Daboo 1229 email: cyrus@daboo.name 1231 7.2.2. /flags 1233 To: iana@iana.org 1234 Subject: IMAP Annotate Registration 1236 Please register the following IMAP Annotate item: 1238 [X] Entry [] Attribute 1240 Name: /flags 1242 Description: Reserved entry hierarchy. 1244 Content-Type: - 1246 Contact person: Cyrus Daboo 1248 email: cyrus@daboo.name 1250 7.2.3. /altsubject 1252 To: iana@iana.org 1253 Subject: IMAP Annotate Registration 1255 Please register the following IMAP Annotate item: 1257 [X] Entry [] Attribute 1259 Name: /altsubject 1261 Description: Defined in IMAP ANNOTATE extension document. 1263 Content-Type: text/plain; charset=utf-8 1265 Contact person: Cyrus Daboo 1267 email: cyrus@daboo.name 1269 7.2.4. //comment 1271 To: iana@iana.org 1272 Subject: IMAP Annotate Registration 1274 Please register the following IMAP Annotate item: 1276 [X] Entry [] Attribute 1278 Name: //comment 1280 Description: Defined in IMAP ANNOTATE extension document. 1282 Content-Type: text/plain; charset=utf-8 1284 Contact person: Cyrus Daboo 1286 email: cyrus@daboo.name 1288 7.2.5. //flags/seen 1290 To: iana@iana.org 1291 Subject: IMAP Annotate Registration 1293 Please register the following IMAP Annotate item: 1295 [X] Entry [] Attribute 1297 Name: //flags/seen 1299 Description: Defined in IMAP ANNOTATE extension document. 1301 Content-Type: text/plain; charset=utf-8 1303 Contact person: Cyrus Daboo 1305 email: cyrus@daboo.name 1307 7.2.6. //flags/answered 1309 To: iana@iana.org 1310 Subject: IMAP Annotate Registration 1312 Please register the following IMAP Annotate item: 1314 [X] Entry [] Attribute 1316 Name: //flags/answered 1318 Description: Defined in IMAP ANNOTATE extension document. 1320 Content-Type: text/plain; charset=utf-8 1322 Contact person: Cyrus Daboo 1324 email: cyrus@daboo.name 1326 7.2.7. //flags/flagged 1328 To: iana@iana.org 1329 Subject: IMAP Annotate Registration 1331 Please register the following IMAP Annotate item: 1333 [X] Entry [] Attribute 1335 Name: //flags/flagged 1337 Description: Defined in IMAP ANNOTATE extension document. 1339 Content-Type: text/plain; charset=utf-8 1341 Contact person: Cyrus Daboo 1343 email: cyrus@daboo.name 1345 7.2.8. //flags/forwarded 1347 To: iana@iana.org 1348 Subject: IMAP Annotate Registration 1350 Please register the following IMAP Annotate item: 1352 [X] Entry [] Attribute 1354 Name: //flags/forwarded 1356 Description: Defined in IMAP ANNOTATE extension document. 1358 Content-Type: text/plain; charset=utf-8 1360 Contact person: Cyrus Daboo 1362 email: cyrus@daboo.name 1364 7.3. Attribute Registrations 1366 The following templates specify the IANA registrations of annotation 1367 attributes specified in this document. 1369 7.3.1. value 1371 To: iana@iana.org 1372 Subject: IMAP Annotate Registration 1374 Please register the following IMAP Annotate item: 1376 [] Entry [X] Attribute 1378 Name: value 1380 Description: Defined in IMAP ANNOTATE extension document. 1382 Contact person: Cyrus Daboo 1384 email: cyrus@daboo.name 1386 7.3.2. size 1388 To: iana@iana.org 1389 Subject: IMAP Annotate Registration 1391 Please register the following IMAP Annotate item: 1393 [] Entry [X] Attribute 1395 Name: size 1397 Description: Defined in IMAP ANNOTATE extension document. 1399 Contact person: Cyrus Daboo 1401 email: cyrus@daboo.name 1403 8. Internationalization Considerations 1405 Annotations may contain values that include text strings, and both 1406 searching and sorting are possible with annotations. Servers MUST 1407 follow standard IMAP text normalization, character set conversion and 1408 collation rules when such operations are acarried out, as they would 1409 for other textual fields being searched or sorted on. 1411 9. Security Considerations 1413 Annotations whose values are intended to remain private MUST be 1414 stored in ".priv" values, and not ".shared" values which may be 1415 accessible to other users. 1417 Excluding the above issues the ANNOTATE extension does not raise any 1418 security considerations that are not present in the base IMAP 1419 protocol, and these issues are discussed in [RFC3501]. 1421 10. References 1423 10.1. Normative References 1425 [I-D.ietf-imapext-sort] 1426 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1427 PROTOCOL - SORT AND THREAD EXTENSION", 1428 draft-ietf-imapext-sort-17 (work in progress), May 2004. 1430 [I-D.melnikov-imap-ext-abnf] 1431 Daboo, C. and A. Melnikov, "Collected extensions to IMAP4 1432 ABNF", draft-melnikov-imap-ext-abnf-08 (work in progress), 1433 January 2006. 1435 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1438 Requirement Levels", BCP 14, RFC 2119, March 1997. 1440 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1441 Specifications: ABNF", RFC 2234, November 1997. 1443 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1444 Configuration Access Protocol", RFC 2244, November 1997. 1446 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1447 4rev1", RFC 3501, March 2003. 1449 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1450 MULTIAPPEND Extension", RFC 3502, March 2003. 1452 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1453 10646", STD 63, RFC 3629, November 2003. 1455 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 1456 RFC 4314, December 2005. 1458 10.2. Informative References 1460 [I-D.ietf-imapext-condstore] 1461 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1462 STORE operation", draft-ietf-imapext-condstore-09 (work in 1463 progress), February 2006. 1465 Appendix A. Acknowledgments 1467 Many thanks to Chris Newman for his detailed comments on the first 1468 draft of this document, and to the participants at the ACAP working 1469 dinner in Pittsburgh. The participants of the IMAPext working group 1470 made significant contributions to this work. 1472 Authors' Addresses 1474 Cyrus Daboo 1476 Email: cyrus@daboo.name 1478 Randall Gellens 1479 QUALCOMM Incorporated 1480 5775 Morehouse Dr. 1481 San Diego, CA 92121-2779 1482 US 1484 Email: randy@qualcomm.com 1486 Intellectual Property Statement 1488 The IETF takes no position regarding the validity or scope of any 1489 Intellectual Property Rights or other rights that might be claimed to 1490 pertain to the implementation or use of the technology described in 1491 this document or the extent to which any license under such rights 1492 might or might not be available; nor does it represent that it has 1493 made any independent effort to identify any such rights. Information 1494 on the procedures with respect to rights in RFC documents can be 1495 found in BCP 78 and BCP 79. 1497 Copies of IPR disclosures made to the IETF Secretariat and any 1498 assurances of licenses to be made available, or the result of an 1499 attempt made to obtain a general license or permission for the use of 1500 such proprietary rights by implementers or users of this 1501 specification can be obtained from the IETF on-line IPR repository at 1502 http://www.ietf.org/ipr. 1504 The IETF invites any interested party to bring to its attention any 1505 copyrights, patents or patent applications, or other proprietary 1506 rights that may cover technology that may be required to implement 1507 this standard. Please address the information to the IETF at 1508 ietf-ipr@ietf.org. 1510 Disclaimer of Validity 1512 This document and the information contained herein are provided on an 1513 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1514 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1515 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1516 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1517 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1520 Copyright Statement 1522 Copyright (C) The Internet Society (2006). This document is subject 1523 to the rights, licenses and restrictions contained in BCP 78, and 1524 except as set forth therein, the authors retain all their rights. 1526 Acknowledgment 1528 Funding for the RFC Editor function is currently provided by the 1529 Internet Society.