idnits 2.17.1 draft-ietf-imapext-annotate-12.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1661. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 3, 2005) is 7016 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 88, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 88, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 571, but not defined == Missing Reference: 'READ-ONLY' is mentioned on line 560, but not defined == Missing Reference: 'MULTIAPPEND' is mentioned on line 1103, but not defined == Missing Reference: 'X' is mentioned on line 1542, but not defined == Unused Reference: 'RFC1891' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1581, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-imapext-2086upd-02 == Outdated reference: A later version (-05) exists of draft-ietf-lemonade-catenate-03 ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 == Outdated reference: A later version (-09) exists of draft-ietf-imapext-condstore-05 Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group C. Daboo 2 Internet-Draft ISAMET, Inc. 3 Expires: August 4, 2005 R. Gellens 4 QUALCOMM Incorporated 5 February 3, 2005 7 IMAP ANNOTATE Extension 8 draft-ietf-imapext-annotate-12 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 4, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The ANNOTATE extension to the Internet Message Access Protocol 44 permits clients and servers to maintain "metadata" for messages 45 stored in an IMAP mailbox. 47 Change History (to be removed prior to publication as an RFC) 48 Changes from -11 to -12: 49 1. Fixed raw XML in formal syntax. 50 2. Fixed double \ in IANA section titles. 51 3. Fixed APPEND formal syntax. 52 4. Added annotations to CATENATE extension. 53 5. Reworded text for unsolicited responses. 54 6. Fixed formal syntax for fetch responses to extend base spec item. 56 Changes from -10 to -11: 57 1. Flags are now read-only and exactly match their IMAP 58 counterparts. 59 2. Added new ACL bits for annotations. 60 3. Revise security considerations. 61 4. Fixed some references. 63 Changes from -09 to -10: 64 1. Added Content-Language value. 65 2. Added IANA registrations for entries/attributes in this document. 67 Changes from -08 to -09: 68 1. Fix formatting, ID nits etc. 69 2. Fix subject -> altsubject in examples. 70 3. Added text to SELECT/EXAMINE optional parameter definition to 71 indicate that the option could trigger a global state change or a 72 mailbox specific change. 73 4. Changed entry/attribute names to be case-sensitive to avoid case 74 mapping issues with utf8 text. 75 5. Clarify COPY interaction to indicate that only the current user's 76 '.priv's are copied, not the '.priv's of other users. 78 Changes from -07 to -08: 79 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 80 does not support any type of annotations, and "0" for a mailbox 81 that only supports read-only annotations. 83 Changes from -06 to -07: 84 1. Added text to state entry and attribute names are always 85 case-insensitive. 86 2. Removed top-level entry namespace. 87 3. Added server accept minima for annotation size and count. 88 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 89 5. Added [ANNOTATESIZE <>] response code. 90 6. Added comment on suggested CONDSTORE support. 91 7. Modified append behaviour to account for MULTIAPPEND. 92 8. Tweaked ABNF. 94 Changes from -05 to -06: 96 1. Split references into Normative and Informative. 97 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 98 name. 99 3. Removed smtp-envelope annotation - a future extension can add 100 this. 101 4. Changed subject to altsubject. 102 5. Added $MDNSent flag and reference to document. 103 6. Cleaned up formal syntax to use IMAP string type for entry and 104 attributes, with requirements on how the string is formatted. 105 7. Use of ACAP vendor subtree registry for vendor tokens. 106 8. Fixed STORE syntax. 108 Changes from -04 to -05: 109 1. Fixed examples to match formal syntax for FETCH responses where 110 parenthesis do not appear around entry-att items. 112 Changes from -03 to -04: 113 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 114 2. Add text for server to reject unknown . 115 3. Do not allow empty part-specifier. 116 4. Store NIL to value to delete. 117 5. Comment on COPY interaction with ANNOTATE. 118 6. Added comment that IMAP flags are mapped one-to-one with their 119 corresponding FLAGS items. 120 7. Added comment that the recent flag annotation is read-only. 122 Changes from -02 to -03: 123 1. Removed reference to status modtime item. 124 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 125 smtp-envelope. 126 3. Added requirement to store data permanently - no 'session only' 127 annotations. 128 4. Removed Access Control section. Replaced with comments on 129 read-only/read-write mailboxes and storing private or shared 130 annotations. 131 5. Removed STORE to default .priv or .shared. 132 6. Added section on optional select parameters. 134 Changes from -01 to -02: 135 1. Now require .priv or .shared on store operations. 137 Changes from -00 to -01: 138 1. MODTIME moved to its own draft, which this draft now depends on. 139 Thus, Conditional Annotation STORE and related items deleted from 140 this draft. 141 2. Private versus Shared Annotations: both are possible (separately 142 addressable using ".priv" and ".shared" suffixes). There is a 143 per-mailbox setting for the default. It is an open issue how 144 this is viewed or changed by the client. 145 3. In ACLs, the "w" right is needed to updated shared state; the "s" 146 right is needed to update private state. 147 4. Various clarifications and text modifications. 148 5. Added 'forwarded' flag for message parts. 150 Changes from pre-imapext to -00: 151 1. Clarified text describing attributions, entries, and attributes. 152 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 153 3. Deleted 'queued' flag. 154 4. Expanded and explained smtp-envelope entry. 155 5. Restricted including ANNOTATION data in unsolicited responses 156 until the client uses it first. (Open issue as to if needed). 157 6. Examples now only use valid entries and attributes. 158 7. Updated Security Considerations. 159 8. Content-Type now defaults to text/plain. 160 9. Open Issue: Shared vs. private annotations. 161 10. Open issue: Annotation Modtime untagged response or VALIDTIME 162 FETCH data. 163 11. Open issue: Conditional annotation STORE. 164 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 165 CAPABILITY command response. 166 13. Prohibition on annotations in lieu of base spec functionality. 167 14. Specified required ACL rights. 168 15. ANNOTATION message data item in APPEND. 169 16. ANNOTATION-MODTIME message data item in STATUS. 170 17. Replaced ATOM_CHAR with utf8-char. 171 18. Updated other ABNF entries. 173 Table of Contents 175 1. Introduction and Overview . . . . . . . . . . . . . . . . . 7 176 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 177 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 178 2.2 Namespace of entries and attributes . . . . . . . . . . . 8 179 2.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 9 180 2.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 11 181 2.3 Private versus Shared . . . . . . . . . . . . . . . . . . 12 182 2.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 13 183 2.5 Access to Standard IMAP Flags and Keywords . . . . . . . . 15 184 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 15 185 3.1 General Considerations . . . . . . . . . . . . . . . . . . 15 186 3.2 Optional parameters with the SELECT/EXAMINE commands . . . 15 187 3.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 17 188 3.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 19 189 3.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 20 190 3.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 22 191 3.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22 192 3.8 ANNOTATION Parameter in CATENATE . . . . . . . . . . . . . 23 193 3.9 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23 194 3.10 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . 24 195 3.11 New ACL Rights . . . . . . . . . . . . . . . . . . . . . 25 196 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 25 197 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 198 5.1 Entry and Attribute Registration Template . . . . . . . . 27 199 5.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 27 200 5.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 28 201 5.2.2 /flags/\answered . . . . . . . . . . . . . . . . . . . 28 202 5.2.3 /flags/\flagged . . . . . . . . . . . . . . . . . . . 29 203 5.2.4 /flags/\deleted . . . . . . . . . . . . . . . . . . . 29 204 5.2.5 /flags/\seen . . . . . . . . . . . . . . . . . . . . . 30 205 5.2.6 /flags/\draft . . . . . . . . . . . . . . . . . . . . 30 206 5.2.7 /flags/\recent . . . . . . . . . . . . . . . . . . . . 31 207 5.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 31 208 5.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 32 209 5.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 32 210 5.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 33 211 5.2.12 //comment . . . . . . . . . . . . . . 33 212 5.2.13 //flags/seen . . . . . . . . . . . . . 34 213 5.2.14 //flags/answered . . . . . . . . . . . 34 214 5.2.15 //flags/flagged . . . . . . . . . . . 35 215 5.2.16 //flags/forwarded . . . . . . . . . . 35 216 5.3 Attribute Registrations . . . . . . . . . . . . . . . . . 35 217 5.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 36 218 5.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 36 219 5.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 37 220 5.3.4 content-language . . . . . . . . . . . . . . . . . . . 37 222 6. Security Considerations . . . . . . . . . . . . . . . . . . 37 223 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 224 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 38 225 7.2 Informative References . . . . . . . . . . . . . . . . . . . 38 226 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 227 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 228 Intellectual Property and Copyright Statements . . . . . . . 40 230 1. Introduction and Overview 232 The ANNOTATE extension is present in any IMAP [RFC3501] 233 implementation which returns "ANNOTATE" as one of the supported 234 capabilities in the CAPABILITY response. 236 The ANNOTATE extension adds a new message data item to the FETCH and 237 STORE commands, as well as adding SEARCH and SORT keys and an APPEND 238 modifier. It also extends tyhe CATENATE extension with a new 239 parameter. 241 This extension makes the following changes to the IMAP protocol: 243 a. adds a new ANNOTATION message data item for use in FETCH 244 b. adds a new ANNOTATION message data item for use in STORE 245 c. adds a new ANNOTATION search criterion for use in SEARCH 246 d. adds a new ANNOTATION sort key for use in SORT extension 247 e. adds a new ANNOTATION data item for use in APPEND 248 f. adds a new ANNOTATION parameter for use in CATENATE 249 g. adds a new requirement on the COPY command 250 h. adds a extension mechanism for adding parameters to the SELECT/ 251 EXAMINE commands and defines the ANNOTATE parameter 252 i. adds two new response codes to indicate store failures of 253 annotations. 254 j. adds a new untagged response codes for the SELECT or EXAMINE 255 commands to indicate the maximum size. 256 k. adds two new ACL 'bits' for use with the ACL [ACLUPD] extension. 258 The data model used for the storage of annotations is based on that 259 of the Application Configuration Access Protocol [RFC2244]. Note 260 that there is no inheritance in annotations. 262 If a server supports annotations, then it MUST store all annotation 263 data permanently, i.e. there is no concept of 'session only' 264 annotations that would correspond to the behaviour of 'session' flags 265 as defined in the IMAP base specification. 267 This extension also introduces a generalised mechanism for adding 268 parameters to the SELECT or EXAMINE commands. It is anticipated that 269 other extensions may want to utilise this, so it is not strictly 270 dependent on the ANNOTATE extension being present. 272 In order to provide optimum support for a disconnected client (one 273 that needs to synchronise annotations for use when offline), servers 274 SHOULD also support the Conditional STORE [CONDSTORE] extension. 276 The rest of this document describes the data model and protocol 277 changes more rigorously. 279 2. Data Model 281 2.1 Overview 283 The data model used in ANNOTATE is that of a uniquely named entry 284 which contains a set of standard attributes. A single coherent unit 285 of "metadata" for a message is stored as a single entry, made up of 286 several attributes. 288 For example, a comment added to a message has an entry name of "/ 289 comment". This entry is composed of several attributes such as 290 "value", "size", etc. which contain the properties and data of the 291 entry. 293 The protocol changes to IMAP described below allow a client to access 294 or change the values of any attributes in any entries in a message 295 annotation, assuming it has sufficient access rights to do so (see 296 Section 2.4 for specifics). 298 2.2 Namespace of entries and attributes 300 Each message annotation is made up of a set of entries. Each entry 301 has a hierarchical name in UTF-8, with each component of the name 302 separated by a slash ("/"). 304 Each entry is made up of a set of attributes. Each attribute has a 305 hierarchical name in UTF-8, with each component of the name separated 306 by a period ("."). 308 The value of an attribute is NIL (has no value), or is a string of 309 zero or more octets. 311 Entry and attribute names MUST NOT contain asterisk ("*") or percent 312 ("%") characters and MUST be valid UTF-8 strings which do not contain 313 the NULL octet. Invalid entry or attribute names result in a BAD 314 response in any IMAP commands where they are used. 316 Entry and attribute names are case-sensitive. 318 Use of non-visible UTF-8 characters in entry and attribute names is 319 strongly discouraged. 321 This specification defines an initial set of entry and attribute 322 names available for use in message annotations. In addition, an 323 extension mechanism is described to allow additional names to be 324 added for extensibility. 326 2.2.1 Entry Names 328 Entry names MUST be specified in a standards track or IESG approved 329 experimental RFC, or fall under the vendor namespace. See Section 330 5.1 for the registration template. 332 / 333 Defines the top-level of entries associated with an entire 334 message. This entry itself does not contain any attributes. All 335 entries that start with a numeric character ("0" - "9") refer to 336 an annotation on a specific body part. All other entries are for 337 annotations on the entire message. 339 /comment 340 Defines a comment or note associated with an entire message. 342 /flags 343 Defines the top-level of entries for flags associated with an 344 entire message. The "value" attribute of each of the entries 345 described below must be either "1", "0" or NIL. "1" corresponds 346 to the flag being set. 348 Standard [RFC3501] flags always have a '\' prefix character. 349 Other standard flags have a '$' prefix. The annotation names used 350 for all flags uses the complete name for that flag, including the 351 prefix character. 353 Flag annotations are read-only. Clients MUST NOT attempt to 354 change them via the annotation entries, using instead the normal 355 IMAP STORE FLAGS command. 357 The set of standard IMAP flags annotations are: 359 /flags/\answered 360 /flags/\flagged 361 /flags/\deleted 362 /flags/\seen 363 /flags/\draft 364 /flags/\recent 366 Note that entry names are sent as IMAP string elements which 367 requires that '\' characters be escaped if sent as a quoted string 368 as opposed to a literal. 370 Note that flag and keyword names in IMAP are case-insensitive, 371 however the entry names for the corresponding annotations are 372 case-sensitive. Thus the IMAP flag and keyword names MUST be 373 mapped to lowercase characters before being used as entry names 374 for annotations. 376 Additional standard flags are: 378 /flags/$mdnsent 379 /flags/$redirected 380 /flags/$forwarded 382 The '$mdnsent' flag is used to indicate message disposition 383 notification processing state [RFC3503]. 385 The '$redirected' flag indicates that a message has been handed 386 off to someone else, by resending the message with minimal 387 alterations, and in such a way that a reply by the new 388 recipient is addressed to the original author, not the user who 389 performed the redirection. 391 The '$forwarded' flag indicates the message was resent to 392 another user, embedded within or attached to a new message. 394 /altsubject 395 Contains text supplied by the message recipient, to be used by the 396 client instead of the original message Subject. 398 /vendor/ 399 Defines the top-level of entries associated with an entire message 400 as created by a particular product of some vendor. These 401 sub-entries can be used by vendors to provide client-specific 402 attributes. The vendor-token MUST be registered with IANA, using 403 the [RFC2244] vendor subtree registry. 405 / 406 Defines the top-level of entries associated with a specific body 407 part of a message. This entry itself does not contain any 408 attributes. The section-part uses the same numeric part specifier 409 syntax as the BODY message data item in the FETCH command 410 [RFC3501]. The server MUST return a BAD response if the client 411 uses an incorrect part specifier (either incorrect syntax or a 412 specifier referring to a non-existent part). The server MUST 413 return a BAD response if the client uses an empty part specifier 414 (which is used in IMAP to represent the entire message). 416 //comment 417 Defines a comment or note associated with a specific body part of 418 a message. 420 //flags 421 Defines the top-level of entries associated with flag state for a 422 specific body part of a message. All sub-entries are maintained 423 entirely by the client. There is no implicit change to any flag 424 by the server. 426 //flags/seen 427 //flags/answered 428 //flags/flagged 429 //flags/forwarded 431 Defines flags for a specific body part of a message. The "value" 432 attribute of these entries must be either "1" or "0". 434 //vendor/ 435 Defines the top-level of entries associated with a specific body 436 part of a message as created by a particular product of some 437 vendor. This entry can be used by vendors to provide client 438 specific attributes. The vendor-token MUST be registered with 439 IANA. 441 2.2.2 Attribute Names 443 Attribute names MUST be specified in a standards track or IESG 444 approved experimental RFC, or fall under the vendor namespace. See 445 Section 5.1 for the registration template. 447 All attribute names implicitly have a ".priv" and a ".shared" suffix 448 which maps to private and shared versions of the entry. Searching or 449 fetching without using either suffix includes both. The client MUST 450 specify either a ".priv" or ".shared" suffix when storing an 451 annotation. 453 value 454 A UTF8 string representing the data value of the attribute. To 455 delete an annotation, the client can store NIL into the value. 457 size 458 The size of the value, in octets. Set automatically by the 459 server, read-only to clients. 461 content-type 462 A MIME [RFC2046] content type and subtype that describes the 463 nature of the content of the "value" attribute. If not present, a 464 value of "text/plain; charset=utf8" is assumed. 466 content-language 467 Indicates the language used for the value. This follows the 468 format described in [RFC3282]. Clients SHOULD set this value when 469 storing an annotation that uses text that can be presented to the 470 user. It is not required for enumerated or numeric values such as 471 flags etc. 473 vendor. 474 Defines an attribute associated with a particular product of some 475 vendor. This attribute can be used by vendors to provide client 476 specific attributes. The vendor-token MUST be registered with 477 IANA, using the [RFC2244] vendor subtree registry. 479 2.3 Private versus Shared 481 Some IMAP mailboxes are private, accessible only to the owning user. 482 Other mailboxes are not, either because the owner has set an ACL 483 [ACLUPD] which permits access by other users, or because it is a 484 shared mailbox. 486 This raises the issue of shared versus private annotations. 488 If all annotations are private, it is impossible to set annotations 489 in a shared or otherwise non-private mailbox that are visible to 490 other users. This eliminates what could be a useful aspect of 491 annotations in a shared environment. An example of such use is a 492 shared IMAP folder containing bug reports. Engineers may want to use 493 annotations to add information to existing messages, indicate 494 assignments, status, etc. This use requires shared annotations. 496 If all annotations are shared, it is impossible to use annotations 497 for private notes on messages in shared mailboxes. Also, modifying 498 an ACL to permit access to a mailbox by other users may 499 unintentionally expose private information. 501 There are also situations in which both shared and private 502 annotations are useful. For example, an administrator may want to 503 set shared annotations on messages in a shared folder, which 504 individual users may wish to supplement with additional notes. 506 If shared and private annotations are to coexist, we need a clear way 507 to differentiate them. Also, it should be as easy as possible for a 508 client to access both and not overlook either. There is also a 509 danger in allowing a client to store an annotation without knowing if 510 it is shared or private. 512 This document proposes two standard suffixes for all attributes: 513 ".shared" and ".priv". A search, fetch, or sort which specifies 514 neither uses both. Store operations MUST explicitly use .priv or 515 .shared suffixes. 517 2.4 Access Control 519 A user needs to have appropriate rights in order to read or write 520 .priv or .shared annotation values. How those rights are calculated 521 depends on whether the ACL [ACLUPD] extension is present or not. If 522 a client attempts to store or fetch an annotation to which they do 523 not have the appropriate rights, the server MUST respond with a NO 524 response. 526 When the ACL extension is not present, access to annotation values is 527 governed by the nature of the selected state. In particular whether 528 the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE 529 mode. 531 When the ACL extension is present, the server MUST recognise two new 532 ACL rights, 'm' and 'n', in addition to the ones defined by the ACL 533 extension itself. 535 The 'm' right controls both read and write access to .priv annotation 536 values. When it is on, access to .priv annotations is allowed, when 537 it is off, access to .priv annotations is disallowed. 539 The 'r' right controls only the read access for .shared annotation 540 values. When it is on, .shared annotations can be read, when it is 541 off, .shared annotations cannot be read. 543 The 'n' right controls only the write access for .shared annotation 544 values. When it is on, .shared annotations can be changed, when it 545 is off, .shared annotations cannot be changed. The 'n' right MUST 546 NOT be present if the 'r' is not present. 548 A summary of all the access control restrictions is tabulated below 549 +---------------+---------------+-----------------------------------+ 550 | Server Type | Action on | Type of mailbox | 551 | | annotation | | 552 +===============+===============+===================================+ 553 | | | | 554 | | read .priv | Any mailbox that can be SELECTED | 555 | | values | or EXAMINED. | 556 | | | | 557 | +---------------+-----------------------------------+ 558 | | | | 559 | | write .priv | Any SELECTED [READ-WRITE] mailbox.| 560 | | values | SELECTED [READ-ONLY] mailboxes MAY| 561 | Server | | also permit writes. | 562 | without | | | 563 | ACL Extension +---------------+-----------------------------------+ 564 | | | | 565 | | read .shared | Any mailbox that can be SELECTED | 566 | | values | or EXAMINED. | 567 | | | | 568 | +---------------+-----------------------------------+ 569 | | | | 570 | | write .shared | Any mailbox that can be SELECTED | 571 | | values | or EXAMINED and is [READ-WRITE]. | 572 | | | | 573 +---------------+---------------+-----------------------------------+ 574 | | | | 575 | | read .priv | Any mailbox with the 'm' | 576 | | values | ACL right. | 577 | | | | 578 | +---------------+-----------------------------------+ 579 | | | | 580 | | write .priv | Any mailbox with the 'm' | 581 | Server | values | ACL right. | 582 | with | | | 583 | ACL Extension +---------------+-----------------------------------+ 584 | | | | 585 | | read .shared | Any mailbox with the 'r' | 586 | | values | ACL right. | 587 | | | | 588 | +---------------+-----------------------------------+ 589 | | | | 590 | | write .shared | Any mailbox with the 'n' | 591 | | values | ACL right. | 592 | | | | 593 +---------------+---------------+-----------------------------------+ 595 2.5 Access to Standard IMAP Flags and Keywords 597 Flags cannot be changed through annotations due to ambiguity of how 598 private and shared values would map to the base IMAP flag and keyword 599 values. As a result the /flags annotation values are treated as 600 read-only and MUST NOT be changed by a client. In turn this means 601 that the .priv and .shared values of a flag annotation are always the 602 same and represent the value of the base IMAP flag or keyword. 604 Clients that need to implement shared and private 'flags' can create 605 their own annotation entries for those, completely bypassing the base 606 IMAP flag/keyword behaviour. 608 3. IMAP Protocol Changes 610 3.1 General Considerations 612 The server is allowed to impose limitations on the size of any one 613 annotation or the total number of annotations for a single message. 614 However, the server MUST accept a minimum annotation data size of at 615 least 1024 bytes, and a minimum annotation count per message of at 616 least 10. 618 The server SHOULD indicate the maximum size for an annotation value 619 by sending an untagged "ANNOTATESIZE" response during a SELECT or 620 EXAMINE command. Clients MUST NOT store annotation values of a size 621 greater than the amount indicated by the server in the "ANNOTATESIZE" 622 response. 624 In some cases, servers may be able to offer annotations on some 625 mailboxes and not others, or may be able to provide only read-only 626 annotations on some mailboxes. For mailboxes that cannot have 627 annotations associated with them, the server MUST return an 628 "ANNOTATESIZE" response with a value of "NIL" during the SELECT or 629 EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch 630 or store annotations on any messages in a mailbox for which the 631 "ANNOTATESIZE" response was "NIL". For mailboxes that can only have 632 read-only annotations associated with them, the server MUST return an 633 "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT 634 or EXAMINE command for that mailbox. Clients MUST NOT attempt to 635 store annotations on any messages in a mailbox for which the 636 "ANNOTATESIZE" response was zero. 638 3.2 Optional parameters with the SELECT/EXAMINE commands 640 This extension adds the ability to include one or more parameters 641 with the IMAP SELECT or EXAMINE commands, to turn on or off certain 642 standard behaviour, or to add new optional behaviours required for a 643 particular extension. 645 There are two possible modes of operation: 647 o A global state change where a single use of the optional parameter 648 will effect the session state from that time on, irrespective of 649 subsequent SELECT/EXAMINE commands. 651 o A per-mailbox state change that will effect the session only for 652 the duration of the new selected state. A subsequent SELECT/ 653 EXAMINE without the optional parameter will cancel its effect for 654 the newly selected mailbox. 656 It is anticipated that other extensions may want to use this 657 facility, so a generalised approach is given here. This facility is 658 not dependent on the presence of the ANNOTATE extension - other 659 extensions can use it with a server that does not implement ANNOTATE. 661 Optional parameters to the SELECT or EXAMINE commands are added as a 662 parenthesised list of atoms or strings, and appear after the mailbox 663 name in the standard SELECT or EXAMINE command. The order of 664 individual parameters is arbitrary. Individual parameters may 665 consist of one or more atoms or strings in a specific order. If a 666 parameter consists of more than one atom or string, it MUST appear in 667 its own parenthesised list. Any parameter not defined by extensions 668 that the server supports MUST be rejected with a NO response. 670 Example: 672 C: a SELECT INBOX (ANNOTATE) 673 S: ... 674 S: a OK SELECT complete 676 In the above example, a single parameter is used with the SELECT 677 command. 679 Example: 681 C: a EXAMINE INBOX (ANNOTATE (RESPONSES "UID Responses") CONDSTORE) 682 S: ... 683 S: a OK EXAMINE complete 685 In the above example, three parameters are used with the EXAMINE 686 command. The second parameter consists of two items: an atom 687 followed by a quoted string. 689 Example: 691 C: a SELECT INBOX (BLURDYBLOOP) 692 S: a NO Unknown parameter in SELECT command 694 In the above example, a parameter not supported by the server is 695 incorrectly used. 697 The ANNOTATE extension defines a single optional SELECT parameter 698 "ANNOTATE", which is used to turn on unsolicited responses for 699 annotations as described in Section 3.4. This optional parameter 700 results in a per-mailbox state change, i.e. it must be used in each 701 SELECT/EXAMINE command in order to be effective, irrespective of 702 whether it was used in a previous SELECT/EXAMINE during the same 703 session. 705 3.3 ANNOTATION Message Data Item in FETCH Command 707 This extension adds an ANNOTATION message data item to the FETCH 708 command. This allows clients to retrieve annotations for a range of 709 messages in the currently selected mailbox. 711 ANNOTATION 713 The ANNOTATION message data item, when used by the client in the 714 FETCH command, takes an entry specifier and an attribute 715 specifier. 717 Example: 719 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 720 S: * 1 FETCH (ANNOTATION ("/comment" 721 ("value.priv" "My comment" 722 "value.shared" "Group note"))) 723 S: a OK Fetch complete 725 In the above example, the content of the "value" attribute for the 726 "/comment" entry is requested by the client and returned by the 727 server. Since neither ".shared" nor ".priv" was specified, both 728 are returned. 730 "*" and "%" wildcard characters can be used in either specifier to 731 match one or more characters at that position, with the exception 732 that "%" does not match the hierarchy delimiter for the specifier it 733 appears in (that is, "/" for an entry specifier or "." for an 734 attribute specifier). Thus an entry specifier of "/%" matches 735 entries such as "/comment" and "/altsubject", but not "/flags/ 736 $redirected". 738 Example: 740 C: a FETCH 1 (ANNOTATION ("/*" ("value.priv" "size.priv"))) 741 S: * 1 FETCH (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 3.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 823 attribute-value pair are returned by the server. Since the client 824 did not specify a ".shared" or ".priv" suffix, both are returned. 825 Only 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 3.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 "vendor.foobar.priv" "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 attributes "value" and "vendor.foobar" are 938 created if not already present, or replaced if they exist. 940 3.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 zero or "NIL" value for its ANNOTATESIZE 952 response code). Servers MUST NOT copy '.priv' annotation data for 953 users other than the current user. 955 3.7 ANNOTATION Message Data Item in APPEND 957 ANNOTATION 959 Sets the specified list of entries and attributes in the resulting 960 message. 962 The APPEND command can include annotations for the message being 963 appended via the addition of a new append data item. The new data 964 item can also be used with the multi-append [RFC3502] extension that 965 allows multiple messages to be appended via a single APPEND command. 967 Example: 969 C: a APPEND drafts ANNOTATION ("/comment" 970 ("value.priv" "Don't send until we hear from Sally")) {310} 971 S: + Ready for literal data 972 C: MIME-Version: 1.0 973 ... 975 C: 976 S: a OK APPEND completed 978 In the above example, a comment with a private value is added to a 979 new message appended to the mailbox. The ellipsis represents the 980 bulk of the message. 982 3.8 ANNOTATION Parameter in CATENATE 984 ANNOTATION 986 Sets the specified list of entries and attributes in the resulting 987 message. 989 The CATENATE [CATENATE] extension defines a new command similar to 990 the APPEND command. When the CATENATE extension is present on a 991 server that also supports the ANNOTATE extension, the CATENATE 992 command MUST allow annotations to be added to the message being 993 'catenated' via the addition of a new parameter item in the command. 995 Example: 997 C: a CATENATE drafts ANNOTATION ("/comment" 998 ("value.priv" "Don't send until we hear from Sally")) 999 TEXT {310} 1000 S: + Ready for literal data 1001 C: MIME-Version: 1.0 1002 ... 1003 C: 1004 S: a OK CATENATE completed 1006 In the above example, a comment with a private value is added to a 1007 new message 'catenated' to the mailbox. The ellipsis represents 1008 the bulk of the message. 1010 3.9 ANNOTATION Criterion in SEARCH 1012 ANNOTATION 1014 The ANNOTATION criterion for the SEARCH command allows a client to 1015 search for a specified string in the value of an annotation entry of 1016 a message. 1018 Messages that have annotations with entries matching and 1019 attributes matching and the specified string 1020 in their values are returned in the SEARCH results. The "*" 1021 character can be used in the entry or attribute name fields to match 1022 any content in those items. The "%" character can be used in the 1023 entry or attribute name fields to match a single level of hierarchy 1024 only. 1026 Example: 1028 C: a SEARCH ANNOTATION "/comment" "value" "IMAP4" 1029 S: * SEARCH 2 3 5 7 11 13 17 19 23 1030 S: a OK Search complete 1032 In the above example, the message numbers of any messages 1033 containing the string "IMAP4" in the shared or private "value" 1034 attribute of the "/comment" entry are returned in the search 1035 results. 1037 Example: 1039 C: a SEARCH ANNOTATION "*" "*" "IMAP4" 1040 S: * SEARCH 1 2 3 5 8 13 21 34 1041 S: a OK Search complete 1043 In the above example, the message numbers of any messages 1044 containing the string "IMAP4" in any attribute (public or private) 1045 of any entry are returned in the search results. 1047 3.10 ANNOTATION Key in SORT 1049 ANNOTATION 1051 The ANNOTATION criterion for the SORT command [SORT] instructs the 1052 server to return the message numbers or UIDs of a mailbox, sorted 1053 using the values of the specified annotations. The ANNOTATION 1054 criterion is available if the server returns both "ANNOTATE" and 1055 "SORT" as supported capabilities in the CAPABILITY command response. 1057 Messages are sorted using the values of the 1058 attributes in the entries. (The charset argument 1059 determines sort order, as specified in the SORT extension 1060 description.) 1062 Example: 1064 C: a SORT (ANNOTATION "/altsubject" "value.shared") UTF-8 ALL 1065 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 1066 S: a OK Sort complete 1068 In the above example, the message numbers of all messages are 1069 returned, sorted according to the shared "value" attribute of the 1070 "/altsubject" entry. 1072 Note that the ANNOTATION sort key must include a fully specified 1073 entry and attribute -- wildcards are not allowed. 1075 3.11 New ACL Rights 1077 As discussed in Section 2.4 this extension adds new 'm' and 'n' 1078 rights to the list of rights provided by the ACL [ACLUPD] extension. 1080 4. Formal Syntax 1082 The following syntax specification uses the Augmented Backus-Naur 1083 Form (ABNF) notation as specified in [RFC2234]. 1085 Non-terminals referenced but not defined below are as defined by 1086 [RFC3501]. 1088 Except as noted otherwise, all alphabetic characters are 1089 case-insensitive. The use of upper or lower case characters to 1090 define token strings is for editorial clarity only. Implementations 1091 MUST accept these strings in a case-insensitive fashion. 1093 annotate-param = "ANNOTATE" 1094 ; defines the select parameter used with 1095 ; ANNOTATE extension 1097 append = "APPEND" SP mailbox [SP flag-list] [SP date-time] 1098 [SP att-annotate] SP literal 1099 ; modifies original IMAP APPEND command 1101 append-message = [SP flag-list] [SP date-time] 1102 [SP att-annotate] SP literal 1103 ; modifies [MULTIAPPEND] extension behaviour 1105 att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 1107 att-match = string 1108 ; dot-separated attribute name 1109 ; MAY contain "*" or "%" for use as wildcards 1111 att-value = attrib SP value 1113 attrib = string 1114 ; dot-separated attribute name 1115 ; MUST NOT contain "*" or "%" 1117 attribs = att-match / 1118 "(" att-match *(SP att-match) ")" 1120 entries = entry-match / 1121 "(" entry-match *(SP entry-match) ")" 1123 entry = string 1124 ; slash-separated path to entry 1125 ; MUST NOT contain "*" or "%" 1127 entry-att = entry SP "(" att-value *(SP att-value) ")" 1129 entry-match = string 1130 ; slash-separated path to entry 1131 ; MAY contain "*" or "%" for use as wildcards 1133 examine =/ *(SP "(" select-param *(SP select-param) ")" 1134 ; modifies the original IMAP examine command to 1135 ; accept optional parameters 1137 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 1138 ; modifies original IMAP fetch-att 1140 msg-att-dynamic =/ "ANNOTATION" SP 1141 ( "(" entry-att *(SP entry-att) ")" / 1142 "(" entry *(SP entry) ")" ) 1143 ; extends FETCH response with annotation data 1145 parameter =/ att-annotate 1146 ; modifies original IMAP CATENATE formal syntax 1147 ; to include annotations 1149 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 1150 "ANNOTATE" SP "TOOMANY" / 1151 "ANNOTATESIZE" SP (number / "NIL") 1152 ; new response codes 1154 search-key =/ "ANNOTATION" SP entry-match SP att-match 1155 SP value 1156 ; modifies original IMAP search-key 1158 select =/ *(SP "(" select-param *(SP select-param) ")" 1159 ; modifies the original IMAP select command to 1160 ; accept optional parameters 1162 select-param = astring / "(" astring SP astring *(SP astring) ")" 1163 ; parameters to SELECT may contain one or 1164 ; more atoms or strings - multiple items 1165 ; are always parenthesised 1167 sort-key =/ "ANNOTATION" SP entry SP attrib 1168 ; modifies original sort-key 1170 store-att-flags =/ att-annotate 1171 ; modifies original IMAP STORE command 1173 value = nstring 1175 5. IANA Considerations 1177 Both entry names and attribute names MUST be specified in a standards 1178 track or IESG approved experimental RFC, or fall under the vendor 1179 namespace. Vendor names MUST be registered. 1181 5.1 Entry and Attribute Registration Template 1183 To: iana@iana.org 1184 Subject: IMAP Annotate Registration 1186 Please register the following IMAP Annotate item: 1188 [] Entry [] Attribute 1190 Name: ______________________________ 1192 Description: _______________________ 1194 ____________________________________ 1196 ____________________________________ 1198 Contact person: ____________________ 1200 email: ____________________ 1202 5.2 Entry Registrations 1204 The following templates specify the IANA registrations of annotation 1205 entries specified in this document. 1207 5.2.1 /comment 1209 To: iana@iana.org 1210 Subject: IMAP Annotate Registration 1212 Please register the following IMAP Annotate item: 1214 [X] Entry [] Attribute 1216 Name: /comment 1218 Description: Defined in IMAP ANNOTATE extension document. 1220 Contact person: Cyrus Daboo 1222 email: daboo@isamet.com 1224 5.2.2 /flags/\answered 1226 To: iana@iana.org 1227 Subject: IMAP Annotate Registration 1229 Please register the following IMAP Annotate item: 1231 [X] Entry [] Attribute 1233 Name: /flags/\answered 1235 Description: Defined in IMAP ANNOTATE extension document. 1237 Contact person: Cyrus Daboo 1239 email: daboo@isamet.com 1241 5.2.3 /flags/\flagged 1243 To: iana@iana.org 1244 Subject: IMAP Annotate Registration 1246 Please register the following IMAP Annotate item: 1248 [X] Entry [] Attribute 1250 Name: /flags/\flagged 1252 Description: Defined in IMAP ANNOTATE extension document. 1254 Contact person: Cyrus Daboo 1256 email: daboo@isamet.com 1258 5.2.4 /flags/\deleted 1260 To: iana@iana.org 1261 Subject: IMAP Annotate Registration 1263 Please register the following IMAP Annotate item: 1265 [X] Entry [] Attribute 1267 Name: /flags/\deleted 1269 Description: Defined in IMAP ANNOTATE extension document. 1271 Contact person: Cyrus Daboo 1273 email: daboo@isamet.com 1275 5.2.5 /flags/\seen 1277 To: iana@iana.org 1278 Subject: IMAP Annotate Registration 1280 Please register the following IMAP Annotate item: 1282 [X] Entry [] Attribute 1284 Name: /flags/\seen 1286 Description: Defined in IMAP ANNOTATE extension document. 1288 Contact person: Cyrus Daboo 1290 email: daboo@isamet.com 1292 5.2.6 /flags/\draft 1294 To: iana@iana.org 1295 Subject: IMAP Annotate Registration 1297 Please register the following IMAP Annotate item: 1299 [X] Entry [] Attribute 1301 Name: /flags/\draft 1303 Description: Defined in IMAP ANNOTATE extension document. 1305 Contact person: Cyrus Daboo 1307 email: daboo@isamet.com 1309 5.2.7 /flags/\recent 1311 To: iana@iana.org 1312 Subject: IMAP Annotate Registration 1314 Please register the following IMAP Annotate item: 1316 [X] Entry [] Attribute 1318 Name: /flags/\recent 1320 Description: Defined in IMAP ANNOTATE extension document. 1322 Contact person: Cyrus Daboo 1324 email: daboo@isamet.com 1326 5.2.8 /flags/$mdnsent 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/$mdnsent 1337 Description: Defined in IMAP ANNOTATE extension document. 1339 Contact person: Cyrus Daboo 1341 email: daboo@isamet.com 1343 5.2.9 /flags/$redirected 1345 To: iana@iana.org 1346 Subject: IMAP Annotate Registration 1348 Please register the following IMAP Annotate item: 1350 [X] Entry [] Attribute 1352 Name: /flags/$redirected 1354 Description: Defined in IMAP ANNOTATE extension document. 1356 Contact person: Cyrus Daboo 1358 email: daboo@isamet.com 1360 5.2.10 /flags/$forwarded 1362 To: iana@iana.org 1363 Subject: IMAP Annotate Registration 1365 Please register the following IMAP Annotate item: 1367 [X] Entry [] Attribute 1369 Name: /flags/$forwarded 1371 Description: Defined in IMAP ANNOTATE extension document. 1373 Contact person: Cyrus Daboo 1375 email: daboo@isamet.com 1377 5.2.11 /altsubject 1379 To: iana@iana.org 1380 Subject: IMAP Annotate Registration 1382 Please register the following IMAP Annotate item: 1384 [X] Entry [] Attribute 1386 Name: /altsubject 1388 Description: Defined in IMAP ANNOTATE extension document. 1390 Contact person: Cyrus Daboo 1392 email: daboo@isamet.com 1394 5.2.12 //comment 1396 To: iana@iana.org 1397 Subject: IMAP Annotate Registration 1399 Please register the following IMAP Annotate item: 1401 [X] Entry [] Attribute 1403 Name: //comment 1405 Description: Defined in IMAP ANNOTATE extension document. 1407 Contact person: Cyrus Daboo 1409 email: daboo@isamet.com 1411 5.2.13 //flags/seen 1413 To: iana@iana.org 1414 Subject: IMAP Annotate Registration 1416 Please register the following IMAP Annotate item: 1418 [X] Entry [] Attribute 1420 Name: //flags/seen 1422 Description: Defined in IMAP ANNOTATE extension document. 1424 Contact person: Cyrus Daboo 1426 email: daboo@isamet.com 1428 5.2.14 //flags/answered 1430 To: iana@iana.org 1431 Subject: IMAP Annotate Registration 1433 Please register the following IMAP Annotate item: 1435 [X] Entry [] Attribute 1437 Name: //flags/answered 1439 Description: Defined in IMAP ANNOTATE extension document. 1441 Contact person: Cyrus Daboo 1443 email: daboo@isamet.com 1445 5.2.15 //flags/flagged 1447 To: iana@iana.org 1448 Subject: IMAP Annotate Registration 1450 Please register the following IMAP Annotate item: 1452 [X] Entry [] Attribute 1454 Name: //flags/flagged 1456 Description: Defined in IMAP ANNOTATE extension document. 1458 Contact person: Cyrus Daboo 1460 email: daboo@isamet.com 1462 5.2.16 //flags/forwarded 1464 To: iana@iana.org 1465 Subject: IMAP Annotate Registration 1467 Please register the following IMAP Annotate item: 1469 [X] Entry [] Attribute 1471 Name: //flags/forwarded 1473 Description: Defined in IMAP ANNOTATE extension document. 1475 Contact person: Cyrus Daboo 1477 email: daboo@isamet.com 1479 5.3 Attribute Registrations 1481 The following templates specify the IANA registrations of annotation 1482 attributes specified in this document. 1484 5.3.1 value 1486 To: iana@iana.org 1487 Subject: IMAP Annotate Registration 1489 Please register the following IMAP Annotate item: 1491 [] Entry [X] Attribute 1493 Name: value 1495 Description: Defined in IMAP ANNOTATE extension document. 1497 Contact person: Cyrus Daboo 1499 email: daboo@isamet.com 1501 5.3.2 size 1503 To: iana@iana.org 1504 Subject: IMAP Annotate Registration 1506 Please register the following IMAP Annotate item: 1508 [] Entry [X] Attribute 1510 Name: size 1512 Description: Defined in IMAP ANNOTATE extension document. 1514 Contact person: Cyrus Daboo 1516 email: daboo@isamet.com 1518 5.3.3 content-type 1520 To: iana@iana.org 1521 Subject: IMAP Annotate Registration 1523 Please register the following IMAP Annotate item: 1525 [] Entry [X] Attribute 1527 Name: content-type 1529 Description: Defined in IMAP ANNOTATE extension document. 1531 Contact person: Cyrus Daboo 1533 email: daboo@isamet.com 1535 5.3.4 content-language 1537 To: iana@iana.org 1538 Subject: IMAP Annotate Registration 1540 Please register the following IMAP Annotate item: 1542 [] Entry [X] Attribute 1544 Name: content-language 1546 Description: Defined in IMAP ANNOTATE extension document. 1548 Contact person: Cyrus Daboo 1550 email: daboo@isamet.com 1552 6. Security Considerations 1554 Annotations whose values are intended to remain private MUST be 1555 stored in .priv values, and not .shared values which may be 1556 accessible to other users. 1558 Excluding the above issues the ANNOTATE extension does not raise any 1559 security considerations that are not present in the base IMAP 1560 protocol, and these issues are discussed in [RFC3501]. 1562 7. References 1564 7.1 Normative References 1566 [ACLUPD] Melnikov, A., "IMAP4 ACL extension", 1567 draft-ietf-imapext-2086upd-02.txt, December 2004. 1569 [CATENATE] 1570 Resnick, P., "Internet Message Access Protocol (IMAP) 1571 CATENATE Extension", draft-ietf-lemonade-catenate-03.txt, 1572 December 2004. 1574 [RFC1891] Moore, K., "SMTP Service Extension for Delivery Status 1575 Notifications", RFC 1891, January 1996. 1577 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1578 Extensions (MIME) Part Two: Media Types", RFC 2046, 1579 November 1996. 1581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1582 Requirement Levels", BCP 14, RFC 2119, March 1997. 1584 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1585 Specifications: ABNF", RFC 2234, November 1997. 1587 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1588 Configuration Access Protocol", RFC 2244, November 1997. 1590 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 1591 2002. 1593 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1594 4rev1", RFC 3501, March 2003. 1596 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1597 MULTIAPPEND Extension", RFC 3502, March 2003. 1599 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1600 profile for Internet Message Access Protocol (IMAP)", RFC 1601 3503, March 2003. 1603 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 1604 Protocol - Sort and Thread Extension", 1605 draft-ietf-imapext-sort-17.txt, May 2004. 1607 7.2 Informative References 1609 [CONDSTORE] 1610 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1611 STORE operation", draft-ietf-imapext-condstore-05.txt, 1612 November 2003. 1614 Authors' Addresses 1616 Cyrus Daboo 1617 ISAMET, Inc. 1618 5001 Baum Blvd. 1619 Suite 650 1620 Pittsburgh, PA 15213 1621 US 1623 EMail: daboo@isamet.com 1625 Randall Gellens 1626 QUALCOMM Incorporated 1627 5775 Morehouse Dr. 1628 San Diego, CA 92121-2779 1629 US 1631 EMail: randy@qualcomm.com 1633 Appendix A. Acknowledgments 1635 Many thanks to Chris Newman for his detailed comments on the first 1636 draft of this document, and to the participants at the ACAP working 1637 dinner in Pittsburgh. 1639 Intellectual Property Statement 1641 The IETF takes no position regarding the validity or scope of any 1642 Intellectual Property Rights or other rights that might be claimed to 1643 pertain to the implementation or use of the technology described in 1644 this document or the extent to which any license under such rights 1645 might or might not be available; nor does it represent that it has 1646 made any independent effort to identify any such rights. Information 1647 on the procedures with respect to rights in RFC documents can be 1648 found in BCP 78 and BCP 79. 1650 Copies of IPR disclosures made to the IETF Secretariat and any 1651 assurances of licenses to be made available, or the result of an 1652 attempt made to obtain a general license or permission for the use of 1653 such proprietary rights by implementers or users of this 1654 specification can be obtained from the IETF on-line IPR repository at 1655 http://www.ietf.org/ipr. 1657 The IETF invites any interested party to bring to its attention any 1658 copyrights, patents or patent applications, or other proprietary 1659 rights that may cover technology that may be required to implement 1660 this standard. Please address the information to the IETF at 1661 ietf-ipr@ietf.org. 1663 Disclaimer of Validity 1665 This document and the information contained herein are provided on an 1666 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1667 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1668 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1669 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1670 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1671 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1673 Copyright Statement 1675 Copyright (C) The Internet Society (2005). This document is subject 1676 to the rights, licenses and restrictions contained in BCP 78, and 1677 except as set forth therein, the authors retain all their rights. 1679 Acknowledgment 1681 Funding for the RFC Editor function is currently provided by the 1682 Internet Society.