idnits 2.17.1 draft-ietf-imapext-annotate-13.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 1690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1680. ** 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 41 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 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 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 31, 2005) is 6965 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 127, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 127, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 634, but not defined == Missing Reference: 'READ-ONLY' is mentioned on line 623, but not defined == Missing Reference: 'X' is mentioned on line 1561, but not defined == Outdated reference: A later version (-08) exists of draft-melnikov-imap-ext-abnf-01 == Outdated reference: A later version (-08) exists of draft-ietf-imapext-2086upd-02 ** Obsolete normative reference: RFC 2086 (Obsoleted by RFC 4314) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-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 (~~), 12 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: September 29, 2005 R. Gellens 4 QUALCOMM Incorporated 5 March 31, 2005 7 IMAP ANNOTATE Extension 8 draft-ietf-imapext-annotate-13 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 September 29, 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, or 45 individual message parts, stored in an IMAP mailbox. 47 Change History (to be removed prior to publication as an RFC) 48 Changes from -12 to -13: 49 1. Sync with change from DC meeting wrt 'r' right for both read and 50 write of .priv. 51 2. Add text about 'n' right being a 'shared flag right' as defined 52 in 2086upd. 53 3. Allow NIL in //flags entries. 54 4. Expand abstract to also indicate that annotations can apply on a 55 per-body part basis as well as per message. 56 5. Fix resp-text-code to use nil instead of "NIL". 57 6. Use double-quotes consistently around ANNOTATESIZE etc. 58 7. Fix typos. 59 8. Remove redundant second para of Introduction. 60 9. Added 'Conventions' section with RFC2119 reference.. 61 10. Describe S:, C: example behaviour in conventions section.. 62 11. Clarify that new rights must also be present if only old ACL is 63 present. 64 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 65 '.'. 66 13. Clarify default charset for content-type text/plain. 67 14. Recommend use of utf-8 for all non-ascii text. 68 15. Clarify terminology of ANNOTATESIZE response code. 69 16. Require servers to return ANNOTATESIZE on SELECT. 70 17. Change an example to use UID FETCH for variety. 71 18. Clarify what to do about annotations exceeding allowed 72 ANNOTATESIZE when doing copy. 73 19. Use ABNFext document for extended SELECT etc. 74 20. Remove RFC1891 reference. 75 21. capability syntax extension. 76 22. Comment on validation content-type attribute. 77 23. Added recommended content-type in IANA registration. 78 24. Added use of literal8 for values. 79 25. Prevent use of 'shared' and 'priv' as separate hierarchy 80 components. 81 26. Restrict entry/attribute names to ascii and added display-name 82 attribute. 83 27. Remove references to CATENATE and use ABNFext for extended 84 APPEND syntax. 86 Changes from -11 to -12: 87 1. Fixed raw XML in formal syntax. 88 2. Fixed double \ in IANA section titles. 89 3. Fixed APPEND formal syntax. 90 4. Added annotations to CATENATE extension. 91 5. Reworded text for unsolicited responses. 92 6. Fixed formal syntax for fetch responses to extend base spec item. 94 Changes from -10 to -11: 96 1. Flags are now read-only and exactly match their IMAP 97 counterparts. 98 2. Added new ACL bits for annotations. 99 3. Revise security considerations. 100 4. Fixed some references. 102 Changes from -09 to -10: 103 1. Added Content-Language value. 104 2. Added IANA registrations for entries/attributes in this document. 106 Changes from -08 to -09: 107 1. Fix formatting, ID nits etc. 108 2. Fix subject -> altsubject in examples. 109 3. Added text to SELECT/EXAMINE optional parameter definition to 110 indicate that the option could trigger a global state change or a 111 mailbox specific change. 112 4. Changed entry/attribute names to be case-sensitive to avoid case 113 mapping issues with utf8 text. 114 5. Clarify COPY interaction to indicate that only the current user's 115 '.priv's are copied, not the '.priv's of other users. 117 Changes from -07 to -08: 118 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 119 does not support any type of annotations, and "0" for a mailbox 120 that only supports read-only annotations. 122 Changes from -06 to -07: 123 1. Added text to state entry and attribute names are always 124 case-insensitive. 125 2. Removed top-level entry namespace. 126 3. Added server accept minima for annotation size and count. 127 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 128 5. Added [ANNOTATESIZE <>] response code. 129 6. Added comment on suggested CONDSTORE support. 130 7. Modified append behaviour to account for MULTIAPPEND. 131 8. Tweaked ABNF. 133 Changes from -05 to -06: 134 1. Split references into Normative and Informative. 135 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 136 name. 137 3. Removed smtp-envelope annotation - a future extension can add 138 this. 139 4. Changed subject to altsubject. 140 5. Added $MDNSent flag and reference to document. 141 6. Cleaned up formal syntax to use IMAP string type for entry and 142 attributes, with requirements on how the string is formatted. 144 7. Use of ACAP vendor subtree registry for vendor tokens. 145 8. Fixed STORE syntax. 147 Changes from -04 to -05: 148 1. Fixed examples to match formal syntax for FETCH responses where 149 parenthesis do not appear around entry-att items. 151 Changes from -03 to -04: 152 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 153 2. Add text for server to reject unknown . 154 3. Do not allow empty part-specifier. 155 4. Store NIL to value to delete. 156 5. Comment on COPY interaction with ANNOTATE. 157 6. Added comment that IMAP flags are mapped one-to-one with their 158 corresponding FLAGS items. 159 7. Added comment that the recent flag annotation is read-only. 161 Changes from -02 to -03: 162 1. Removed reference to status modtime item. 163 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 164 smtp-envelope. 165 3. Added requirement to store data permanently - no 'session only' 166 annotations. 167 4. Removed Access Control section. Replaced with comments on 168 read-only/read-write mailboxes and storing private or shared 169 annotations. 170 5. Removed STORE to default .priv or .shared. 171 6. Added section on optional select parameters. 173 Changes from -01 to -02: 174 1. Now require .priv or .shared on store operations. 176 Changes from -00 to -01: 177 1. MODTIME moved to its own draft, which this draft now depends on. 178 Thus, Conditional Annotation STORE and related items deleted from 179 this draft. 180 2. Private versus Shared Annotations: both are possible (separately 181 addressable using ".priv" and ".shared" suffixes). There is a 182 per-mailbox setting for the default. It is an open issue how 183 this is viewed or changed by the client. 184 3. In ACLs, the "w" right is needed to updated shared state; the "s" 185 right is needed to update private state. 186 4. Various clarifications and text modifications. 187 5. Added 'forwarded' flag for message parts. 189 Changes from pre-imapext to -00: 190 1. Clarified text describing attributions, entries, and attributes. 192 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 193 3. Deleted 'queued' flag. 194 4. Expanded and explained smtp-envelope entry. 195 5. Restricted including ANNOTATION data in unsolicited responses 196 until the client uses it first. (Open issue as to if needed). 197 6. Examples now only use valid entries and attributes. 198 7. Updated Security Considerations. 199 8. Content-Type now defaults to text/plain. 200 9. Open Issue: Shared vs. private annotations. 201 10. Open issue: Annotation Modtime untagged response or VALIDTIME 202 FETCH data. 203 11. Open issue: Conditional annotation STORE. 204 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 205 CAPABILITY command response. 206 13. Prohibition on annotations in lieu of base spec functionality. 207 14. Specified required ACL rights. 208 15. ANNOTATION message data item in APPEND. 209 16. ANNOTATION-MODTIME message data item in STATUS. 210 17. Replaced ATOM_CHAR with utf8-char. 211 18. Updated other ABNF entries. 213 Table of Contents 215 1. Introduction and Overview . . . . . . . . . . . . . . . . . 8 216 2. Conventions Used in This Document . . . . . . . . . . . . . 8 217 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 218 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 219 3.2 Namespace of entries and attributes . . . . . . . . . . . 9 220 3.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 10 221 3.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 12 222 3.3 Private versus Shared . . . . . . . . . . . . . . . . . . 13 223 3.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 14 224 3.5 Access to Standard IMAP Flags and Keywords . . . . . . . . 16 225 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 16 226 4.1 General Considerations . . . . . . . . . . . . . . . . . . 16 227 4.2 ANNOTATE parameter with the SELECT/EXAMINE commands . . . 16 228 4.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 17 229 4.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 19 230 4.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 20 231 4.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 22 232 4.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22 233 4.8 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 23 234 4.9 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 24 235 4.10 New ACL Rights . . . . . . . . . . . . . . . . . . . . . 24 236 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24 237 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 238 6.1 Entry and Attribute Registration Template . . . . . . . . 27 239 6.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 27 240 6.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 28 241 6.2.2 /flags/\answered . . . . . . . . . . . . . . . . . . . 28 242 6.2.3 /flags/\flagged . . . . . . . . . . . . . . . . . . . 29 243 6.2.4 /flags/\deleted . . . . . . . . . . . . . . . . . . . 29 244 6.2.5 /flags/\seen . . . . . . . . . . . . . . . . . . . . . 30 245 6.2.6 /flags/\draft . . . . . . . . . . . . . . . . . . . . 30 246 6.2.7 /flags/\recent . . . . . . . . . . . . . . . . . . . . 31 247 6.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 31 248 6.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 32 249 6.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 32 250 6.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 33 251 6.2.12 //comment . . . . . . . . . . . . . . 33 252 6.2.13 //flags/seen . . . . . . . . . . . . . 34 253 6.2.14 //flags/answered . . . . . . . . . . . 34 254 6.2.15 //flags/flagged . . . . . . . . . . . 35 255 6.2.16 //flags/forwarded . . . . . . . . . . 35 256 6.3 Attribute Registrations . . . . . . . . . . . . . . . . . 35 257 6.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 36 258 6.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 36 259 6.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 37 260 6.3.4 content-language . . . . . . . . . . . . . . . . . . . 37 261 6.3.5 display-name . . . . . . . . . . . . . . . . . . . . . 38 262 7. Security Considerations . . . . . . . . . . . . . . . . . . 38 263 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 264 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 38 265 8.2 Informative References . . . . . . . . . . . . . . . . . . . 39 266 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 267 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40 268 Intellectual Property and Copyright Statements . . . . . . . 41 270 1. Introduction and Overview 272 The ANNOTATE extension is present in any IMAP [RFC3501] 273 implementation which returns "ANNOTATE" as one of the supported 274 capabilities in the CAPABILITY response. 276 This extension makes the following changes to the IMAP protocol: 278 a. adds a new ANNOTATION message data item for use in FETCH 279 b. adds a new ANNOTATION message data item for use in STORE 280 c. adds a new ANNOTATION search criterion for use in SEARCH 281 d. adds a new ANNOTATION sort key for use in SORT extension 282 e. adds a new ANNOTATION data item for use in APPEND 283 f. adds a new requirement on the COPY command 284 g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE 285 commands 286 h. adds two new response codes to indicate store failures of 287 annotations. 288 i. adds a new untagged response code for the SELECT or EXAMINE 289 commands to indicate the maximum size. 290 j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] 291 and [ACLUPD] . 293 The data model used for the storage of annotations is based on that 294 of the Application Configuration Access Protocol [RFC2244]. Note 295 that there is no inheritance in annotations. 297 If a server supports annotations, then it MUST store all annotation 298 data permanently, i.e. there is no concept of "session only" 299 annotations that would correspond to the behaviour of "session" flags 300 as defined in the IMAP base specification. 302 In order to provide optimum support for a disconnected client (one 303 that needs to synchronise annotations for use when offline), servers 304 SHOULD also support the Conditional STORE [CONDSTORE] extension. 306 The rest of this document describes the data model and protocol 307 changes more rigorously. 309 2. Conventions Used in This Document 311 In examples, "C:" and "S:" indicate lines sent by the client and 312 server respectively. 314 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 315 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 316 document are to be interpreted as described in [RFC2119]. 318 3. Data Model 320 3.1 Overview 322 The data model used in ANNOTATE is that of a uniquely named entry 323 which contains a set of standard attributes. A single coherent unit 324 of "metadata" for a message is stored as a single entry, made up of 325 several attributes. 327 For example, a comment annotation added to a message has an entry 328 name of "/comment". This entry is composed of several attributes 329 such as "value", "size", etc. which contain the properties and data 330 of the entry. 332 The protocol changes to IMAP described below allow a client to access 333 or change the values of any attributes in any entries in a message 334 annotation, assuming it has sufficient access rights to do so (see 335 Section 3.4 for specifics). 337 3.2 Namespace of entries and attributes 339 Each message annotation is made up of a set of entries. Each entry 340 has a hierarchical name, with each component of the name separated by 341 a slash ("/"). An entry name MUST NOT contain two consecutive "/" 342 characters and MUST NOT end with a "/" character. 344 Each entry is made up of a set of attributes. Each attribute has a 345 hierarchical name, with each component of the name separated by a 346 period ("."). An attribute name MUST NOT contain two consecutive "." 347 characters and MUST NOT end with a "." character. 349 The value of an attribute is "NIL" (has no value), or is a string of 350 zero or more octets. 352 Entry and attribute names MUST NOT contain asterisk ("*") or percent 353 ("%") characters and MUST NOT contain non-ASCII characters or the 354 NULL octet. Invalid entry or attribute names result in a BAD 355 response in any IMAP commands where they are used. 357 Attribute names MUST NOT contain any hierarchical components with the 358 names "priv" or "shared" as those have special meaning (see Section 359 3.3. 361 Entry and attribute names are case-sensitive. 363 Use of control or punctuation characters in entry and attribute names 364 is strongly discouraged. 366 This specification defines an initial set of entry and attribute 367 names available for use in message annotations. In addition, an 368 extension mechanism is described to allow additional names to be 369 added as needed. 371 3.2.1 Entry Names 373 Entry names MUST be specified in a standards track or IESG approved 374 experimental RFC, or fall under the vendor namespace. See Section 375 6.1 for the registration template. 377 / 378 Defines the top-level of entries associated with an entire 379 message. This entry itself does not contain any attributes. All 380 entries that start with a numeric character ("0" - "9") refer to 381 an annotation on a specific body part. All other entries are for 382 annotations on the entire message. 384 /comment 385 Defines a comment or note associated with an entire message. 387 /flags 388 Defines the top-level of entries for flags associated with an 389 entire message. The "value" attribute of each of the entries 390 described below must be either "1", "0" or "NIL". "1" corresponds 391 to the flag being set. 393 Standard [RFC3501] flags always have a "\" prefix character. 394 Other standard flags have a "$" prefix. The annotation names used 395 for all flags uses the complete name for that flag, including the 396 prefix character. 398 Flag annotations are read-only. Clients MUST NOT attempt to 399 change them via the annotation entries, instead the normal IMAP 400 STORE FLAGS command is used. 402 The set of standard IMAP flags annotations are: 404 /flags/\answered 405 /flags/\flagged 406 /flags/\deleted 407 /flags/\seen 408 /flags/\draft 409 /flags/\recent 411 Note that entry names are sent as IMAP string elements which 412 requires that "\" characters be escaped if sent as a quoted string 413 as opposed to a literal. 415 Note that flag and keyword names in IMAP are case-insensitive, 416 however the entry names for the corresponding annotations are 417 case-sensitive. Thus the IMAP flag and keyword names MUST be 418 mapped to lowercase characters before being used as entry names 419 for annotations. 421 Additional standard flags are: 423 /flags/$mdnsent 424 /flags/$redirected 425 /flags/$forwarded 427 The "$mdnsent" flag is used to indicate message disposition 428 notification processing state [RFC3503]. 430 The "$redirected" flag indicates that a message has been handed 431 off to someone else, by resending the message with minimal 432 alterations, and in such a way that a reply by the new 433 recipient is addressed to the original author, not the user who 434 performed the redirection. 436 The "$forwarded" flag indicates the message was resent to 437 another user, embedded within or attached to a new message. 439 /altsubject 440 Contains text supplied by the message recipient, to be used by the 441 client instead of the original message Subject. 443 /vendor/ 444 Defines the top-level of entries associated with an entire message 445 as created by a particular product of some vendor. These 446 sub-entries can be used by vendors to provide client-specific 447 attributes. The vendor-token MUST be registered with IANA, using 448 the [RFC2244] vendor subtree registry. 450 / 451 Defines the top-level of entries associated with a specific body 452 part of a message. This entry itself does not contain any 453 attributes. The section-part uses the same numeric part specifier 454 syntax as the BODY message data item in the FETCH command 455 [RFC3501]. The server MUST return a BAD response if the client 456 uses an incorrect part specifier (either incorrect syntax or a 457 specifier referring to a non-existent part). The server MUST 458 return a BAD response if the client uses an empty part specifier 459 (which is used in IMAP to represent the entire message). 461 //comment 462 Defines a comment or note associated with a specific body part of 463 a message. 465 //flags 466 Defines the top-level of entries associated with flag state for a 467 specific body part of a message. All sub-entries are maintained 468 entirely by the client. There is no implicit change to any flag 469 by the server. 471 //flags/seen 472 //flags/answered 473 //flags/flagged 474 //flags/forwarded 476 Defines flags for a specific body part of a message. The "value" 477 attribute of each of the entries described above must be either 478 "1", "0" or "NIL". "1" corresponds to the flag being set. 480 //vendor/ 481 Defines the top-level of entries associated with a specific body 482 part of a message as created by a particular product of some 483 vendor. This entry can be used by vendors to provide client 484 specific attributes. The vendor-token MUST be registered with 485 IANA. 487 3.2.2 Attribute Names 489 Attribute names MUST be specified in a standards track or IESG 490 approved experimental RFC, or fall under the vendor namespace. See 491 Section 6.1 for the registration template. 493 All attribute names implicitly have a ".priv" and a ".shared" suffix 494 which maps to private and shared versions of the entry. Searching or 495 fetching without using either suffix includes both. The client MUST 496 specify either a ".priv" or ".shared" suffix when storing an 497 annotation. 499 value 500 A string or binary data representing the value of the annotation. 501 To delete an annotation, the client can store "NIL" into the 502 value. The content represented by the string is set via the 503 content-type attribute. When the content-type attribute is not 504 present, the value MUST be a "text/plain" content-type with a 505 character set of "utf-8" [RFC3629]. Clients SHOULD use the utf-8 506 character set for any text values that contain non ASCII data. 507 Note that binary data (data which may contain the NULL octet) is 508 allowed (e.g. for storing images etc), and this extension uses 509 the "literal8" syntax element [ABNFEXT] to allow such data to be 510 written to or read from the server. 512 size 513 The size of the value, in octets. Set automatically by the 514 server, read-only to clients. 516 content-type 517 A MIME [RFC2046] content type and subtype that describes the 518 nature of the content of the "value" attribute. If not present, a 519 value of "text/plain; charset=utf-8" is assumed. 521 content-language 522 Indicates the language used for the value. This follows the 523 format described in [RFC3282]. Clients SHOULD set this value when 524 storing an annotation that uses text that can be presented to the 525 user. It is not required for enumerated or numeric values such as 526 flags etc. If a value is being set, clients MUST ensure that it 527 accurately reflects the content stored in the value attribute. 529 display-name 530 A text string using the "utf-8" character set [RFC3629] that 531 describes the nature of the corresponding annotation, in a 532 language specified by the "content-language" attribute. 534 vendor. 535 Defines an attribute associated with a particular product of some 536 vendor. This attribute can be used by vendors to provide client 537 specific attributes. The vendor-token MUST be registered with 538 IANA, using the [RFC2244] vendor subtree registry. 540 3.3 Private versus Shared 542 Some IMAP mailboxes are private, accessible only to the owning user. 543 Other mailboxes are not, either because the owner has set an ACL 544 [ACLUPD] which permits access by other users, or because it is a 545 shared mailbox. 547 This raises the issue of shared versus private annotations. 549 If all annotations are private, it is impossible to set annotations 550 in a shared or otherwise non-private mailbox that are visible to 551 other users. This eliminates what could be a useful aspect of 552 annotations in a shared environment. An example of such use is a 553 shared IMAP folder containing bug reports. Engineers may want to use 554 annotations to add information to existing messages, indicate 555 assignments, status, etc. This use requires shared annotations. 557 If all annotations are shared, it is impossible to use annotations 558 for private notes on messages in shared mailboxes. Also, modifying 559 an ACL to permit access to a mailbox by other users may 560 unintentionally expose private information. 562 There are also situations in which both shared and private 563 annotations are useful. For example, an administrator may want to 564 set shared annotations on messages in a shared folder, which 565 individual users may wish to supplement with additional notes. 567 If shared and private annotations are to coexist, we need a clear way 568 to differentiate them. Also, it should be as easy as possible for a 569 client to access both and not overlook either. There is also a 570 danger in allowing a client to store an annotation without knowing if 571 it is shared or private. 573 This document proposes two standard suffixes for all attributes: 574 ".shared" and ".priv". A search, fetch, or sort which specifies 575 neither uses both. Store operations MUST explicitly use ".priv" or 576 ".shared" suffixes. 578 3.4 Access Control 580 A user needs to have appropriate rights in order to read or write 581 ".priv" or ".shared" annotation values. How those rights are 582 calculated depends on whether the ACL [RFC2086] extension or its 583 update [ACLUPD] is present or not. If a client attempts to store or 584 fetch an annotation to which they do not have the appropriate rights, 585 the server MUST respond with a NO response. 587 When the ACL extension is not present, access to annotation values is 588 governed by the nature of the selected state. In particular whether 589 the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE 590 mode. 592 When the ACL extension is present, the server MUST recognise the new 593 ACL right "n", in addition to the ones defined by the ACL extension 594 itself. 596 The "r" right controls both read and write access to ".priv" 597 annotation values. When it is on, access to ".priv" annotations is 598 allowed, when it is off, access to ".priv" annotations is disallowed. 600 The "r" right controls only the read access for ".shared" annotation 601 values. When it is on, ".shared" annotations can be read, when it is 602 off, ".shared" annotations cannot be read. 604 The "n" right controls only the write access for ".shared" annotation 605 values. When it is on, ".shared" annotations can be changed, when it 606 is off, ".shared" annotations cannot be changed. The "n" right MUST 607 NOT be present if the "r" is not present. The "n" right constitutes 608 a "shared flag right" as defined in [ACLUPD] Section 6.2. 610 A summary of all the access control restrictions is tabulated below 612 +---------------+---------------+-----------------------------------+ 613 | Server Type | Action on | Type of mailbox | 614 | | annotation | | 615 +===============+===============+===================================+ 616 | | | | 617 | | read .priv | Any mailbox that can be SELECTED | 618 | | values | or EXAMINED. | 619 | | | | 620 | +---------------+-----------------------------------+ 621 | | | | 622 | | write .priv | Any SELECTED [READ-WRITE] mailbox.| 623 | | values | SELECTED [READ-ONLY] mailboxes MAY| 624 | Server | | also permit writes. | 625 | without | | | 626 | ACL Extension +---------------+-----------------------------------+ 627 | | | | 628 | | read .shared | Any mailbox that can be SELECTED | 629 | | values | or EXAMINED. | 630 | | | | 631 | +---------------+-----------------------------------+ 632 | | | | 633 | | write .shared | Any mailbox that can be SELECTED | 634 | | values | or EXAMINED and is [READ-WRITE]. | 635 | | | | 636 +---------------+---------------+-----------------------------------+ 637 | | | | 638 | | read .priv | Any mailbox with the "r" | 639 | | values | ACL right. | 640 | | | | 641 | +---------------+-----------------------------------+ 642 | | | | 643 | | write .priv | Any mailbox with the "r" | 644 | Server | values | ACL right. | 645 | with | | | 646 | ACL Extension +---------------+-----------------------------------+ 647 | | | | 648 | | read .shared | Any mailbox with the "r" | 649 | | values | ACL right. | 650 | | | | 651 | +---------------+-----------------------------------+ 652 | | | | 653 | | write .shared | Any mailbox with the "n" | 654 | | values | ACL right. | 655 | | | | 656 +---------------+---------------+-----------------------------------+ 658 3.5 Access to Standard IMAP Flags and Keywords 660 Flags cannot be changed through annotations due to ambiguity of how 661 private and shared values would map to the base IMAP flag and keyword 662 values. As a result the /flags annotation values are treated as 663 read-only and MUST NOT be changed by a client. In turn this means 664 that the ".priv" and ".shared" values of a flag annotation are always 665 the same and represent the value of the base IMAP flag or keyword. 667 Clients that need to implement shared and private "flags" can create 668 their own annotation entries for those, completely bypassing the base 669 IMAP flag/keyword behaviour. 671 4. IMAP Protocol Changes 673 4.1 General Considerations 675 The server is allowed to impose limitations on the size of any one 676 annotation or the total number of annotations for a single message. 677 However, the server MUST accept a minimum annotation data size of at 678 least 1024 bytes, and a minimum annotation count per message of at 679 least 10. 681 The server MUST indicate the maximum size for an annotation value by 682 sending an untagged ANNOTATESIZE response containing the maximum size 683 value during a SELECT or EXAMINE command. Clients MUST NOT store 684 annotation values of a size greater than the amount indicated by the 685 server in the ANNOTATESIZE response. 687 In some cases, servers may be able to offer annotations on some 688 mailboxes and not others, or may be able to provide only read-only 689 annotations on some mailboxes. For mailboxes that cannot have 690 annotations associated with them, the server MUST return an 691 ANNOTATESIZE response with a value of "NIL" during the SELECT or 692 EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch 693 or store annotations on any messages in a mailbox for which the 694 ANNOTATESIZE response was "NIL". For mailboxes that can only have 695 read-only annotations associated with them, the server MUST return an 696 ANNOTATESIZE response with a value of "0" (zero) during the SELECT or 697 EXAMINE command for that mailbox. Clients MUST NOT attempt to store 698 annotations on any messages in a mailbox for which the ANNOTATESIZE 699 response was zero. 701 4.2 ANNOTATE parameter with the SELECT/EXAMINE commands 703 The ANNOTATE extension defines a single optional SELECT parameter 704 [ABNFEXT] "ANNOTATE", which is used to turn on unsolicited responses 705 for annotations as described in Section 4.4. This optional parameter 706 results in a per-mailbox state change, i.e. it must be used in each 707 SELECT/EXAMINE command in order to be effective, irrespective of 708 whether it was used in a previous SELECT/EXAMINE during the same 709 session. 711 4.3 ANNOTATION Message Data Item in FETCH Command 713 This extension adds an ANNOTATION message data item to the FETCH 714 command. This allows clients to retrieve annotations for a range of 715 messages in the currently selected mailbox. 717 ANNOTATION 719 The ANNOTATION message data item, when used by the client in the 720 FETCH command, takes an entry specifier and an attribute 721 specifier. 723 Example: 725 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 726 S: * 1 FETCH (ANNOTATION ("/comment" 727 ("value.priv" "My comment" 728 "value.shared" "Group note"))) 729 S: a OK Fetch complete 731 In the above example, the content of the "value" attribute for the 732 "/comment" entry is requested by the client and returned by the 733 server. Since neither ".shared" nor ".priv" was specified, both 734 are returned. 736 "*" and "%" wildcard characters can be used in either specifier to 737 match one or more characters at that position, with the exception 738 that "%" does not match the hierarchy delimiter for the specifier it 739 appears in (that is, "/" for an entry specifier or "." for an 740 attribute specifier). Thus an entry specifier of "/%" matches 741 entries such as "/comment" and "/altsubject", but not "/flags/ 742 $redirected". 744 Example: 746 C: a UID FETCH 1123 (UID ANNOTATION 747 ("/*" ("value.priv" "size.priv"))) 748 S: * 12 FETCH (UID 1123 ANNOTATION 749 ("/comment" ("value.priv" "My comment" 750 "size.priv" "10") 751 "/altsubject" ("value.priv" "Rhinoceroses!" 752 "size.priv" "13") 753 "/vendor/foobar/label.priv" 754 ("value.priv" "label43" 755 "size.priv" "7") 756 "/vendor/foobar/personality" 757 ("value.priv" "Tallulah Bankhead" 758 "size.priv" "17"))) 759 S: a OK Fetch complete 761 In the above example, the contents of the private "value" and 762 "size" attributes for any entries in the "/" hierarchy are 763 requested by the client and returned by the server. 765 Example: 767 C: a FETCH 1 (ANNOTATION ("/%" "value.shared")) 768 S: * 1 FETCH (ANNOTATION 769 ("/comment" ("value.shared" "Patch Mangler") 770 "/altsubject" ("value.shared" "Patches? We don't 771 need no steenkin patches!"))) 772 S: a OK Fetch complete 774 In the above example, the contents of the shared "value" 775 attributes for entries at the top level only of the "/" hierarchy 776 are requested by the client and returned by the server. 778 Entry and attribute specifiers can be lists of atomic specifiers, so 779 that multiple items of each type may be returned in a single FETCH 780 command. 782 Example: 784 C: a FETCH 1 (ANNOTATION 785 (("/comment" "/altsubject") "value.priv")) 786 S: * 1 FETCH (ANNOTATION 787 ("/comment" ("value.priv" "What a chowder-head") 788 "/altsubject" ("value.priv" "How to crush beer cans"))) 789 S: a OK Fetch complete 791 In the above example, the contents of the private "value" 792 attributes for the two entries "/comment" and "/altsubject" are 793 requested by the client and returned by the server. 795 4.4 ANNOTATION Message Data Item in FETCH Response 797 The ANNOTATION message data item in the FETCH response displays 798 information about annotations in a message. 800 ANNOTATION parenthesised list 802 The response consists of a list of entries, each of which has a 803 list of attribute-value pairs. 805 Example: 807 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 808 S: * 1 FETCH (ANNOTATION ("/comment" 809 ("value.priv" "My comment" 810 "value.shared" NIL))) 811 S: a OK Fetch complete 813 In the above example, a single entry with a single attribute-value 814 pair is returned by the server. Since the client did not specify 815 a ".shared" or ".priv" suffix, both are returned. Only the 816 private attribute has a value (the shared value is "NIL"). 818 Example: 820 C: a FETCH 1 (ANNOTATION 821 (("/comment" "/altsubject") "value")) 822 S: * 1 FETCH (ANNOTATION 823 ("/comment" ("value.priv" "My comment" 824 "value.shared" NIL) 825 "/altsubject" ("value.priv" "My subject" 826 "value.shared" NIL))) 827 S: a OK Fetch complete 829 In the above example, two entries each with a single 830 attribute-value pair are returned by the server. Since the client 831 did not specify a ".shared" or ".priv" suffix, both are returned. 832 Only the private attributes have values; the shared attributes are 833 "NIL". 835 Example: 837 C: a FETCH 1 (ANNOTATION 838 ("/comment" ("value" "size"))) 839 S: * 1 FETCH (ANNOTATION 840 ("/comment" 841 ("value.priv" "My comment" 842 "value.shared" NIL 843 "size.priv" "10" 844 "size.shared" "0"))) 845 S: a OK Fetch complete 847 In the above example, a single entry with two attribute-value 848 pairs is returned by the server. Since the client did not specify 849 a ".shared" or ".priv" suffix, both are returned. Only the 850 private attributes have values; the shared attributes are "NIL". 852 Servers SHOULD send ANNOTATION message data items in unsolicited 853 FETCH responses if an annotation entry is changed by a third-party, 854 and the ANNOTATE select parameter was used. This allows servers to 855 keep clients updated with changes to annotations by other clients. 857 Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data 858 values - only the entry name of the ANNOTATION that has changed. 859 This restriction avoids sending ANNOTATION data values (which may be 860 large) to a client unless the client explicitly asks for the value. 862 Example: 864 C: a STORE 1 +FLAGS (\Seen) 865 S: * 1 FETCH (FLAGS (\Seen)) 866 ANNOTATION ("/comment")) 867 S: a OK STORE complete 869 In the above example, an unsolicited ANNOTATION response is 870 returned during a STORE command. The unsolicited response 871 contains only the entry name of the annotation that changed, and 872 not its value. 874 4.5 ANNOTATION Message Data Item in STORE 876 ANNOTATION 878 Sets the specified list of entries by adding or replacing the 879 specified attributes with the values provided. Clients can use 880 "NIL" for values of attributes it wants to remove from entries. 882 The ANNOTATION message data item used with the STORE command has an 883 implicit ".SILENT" behaviour. This means the server does not 884 generate an untagged FETCH in response to the STORE command and 885 assumes that the client updates its own cache if the command 886 succeeds. 888 If the server is unable to store an annotation because the size of 889 its value is too large, the server MUST return a tagged NO response 890 with a "[ANNOTATE TOOBIG]" response code. 892 If the server is unable to store a new annotation because the maximum 893 number of allowed annotations has already been reached, the server 894 MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response 895 code. 897 Example: 899 C: a STORE 1 ANNOTATION ("/comment" 900 ("value.priv" "My new comment")) 901 S: a OK Store complete 903 In the above example, the entry "/comment" is created (if not 904 already present) and the private attribute "value" with data set 905 to "My new comment" is created if not already present, or replaced 906 if it exists. 908 Example: 910 C: a STORE 1 ANNOTATION ("/comment" 911 ("value.shared" NIL)) 912 S: a OK Store complete 914 In the above example, the shared "value" attribute of the entry "/ 915 comment" is removed by storing "NIL" into the attribute. 917 Multiple entries can be set in a single STORE command by listing 918 entry-attribute-value pairs in the list. 920 Example: 922 C: a STORE 1 ANNOTATION ("/comment" 923 ("value.priv" "Get tix Tuesday") 924 "/altsubject" 925 ("value.priv" "Wots On")) 926 S: a OK Store complete 928 In the above example, the entries "/comment" and "/altsubject" are 929 created (if not already present) and the private attribute "value" 930 is created for each entry if not already present, or replaced if 931 they exist. 933 Multiple attributes can be set in a single STORE command by listing 934 multiple attribute-value pairs in the entry list. 936 Example: 938 C: a STORE 1 ANNOTATION ("/comment" 939 ("value.priv" "My new comment" 940 "vendor.foobar.priv" "foo's bar")) 941 S: a OK Store complete 943 In the above example, the entry "/comment" is created (if not already 944 present) and the private attributes "value" and "vendor.foobar" are 945 created if not already present, or replaced if they exist. 947 4.6 ANNOTATION interaction with COPY 949 The COPY command can be used to move messages from one mailbox to 950 another on the same server. Servers that support the ANNOTATION 951 extension MUST, for each message being copied, copy all ".priv" 952 annotation data for the current user only, and all ".shared" 953 annotation data along with the message to the new mailbox. The only 954 exceptions to this are if the destination mailbox permissions are 955 such that either the ".priv" or ".shared" annotations are not 956 allowed, or if the destination mailbox is of a type that does not 957 support annotations or does not support storing of annotations (a 958 mailbox that returns a zero or "NIL" value for its ANNOTATESIZE 959 response code), or if the destination mailbox cannot support the size 960 of a annotation because it exceeds the ANNOTATESIZE value. Servers 961 MUST NOT copy ".priv" annotation data for users other than the 962 current user. 964 4.7 ANNOTATION Message Data Item in APPEND 966 ANNOTATION 968 Sets the specified list of entries and attributes in the resulting 969 message. 971 The APPEND command can include annotations for the message being 972 appended via the addition of a new append data item [ABNFEXT]. The 973 new data item can also be used with the multi-append [RFC3502] 974 extension that allows multiple messages to be appended via a single 975 APPEND command. 977 Example: 979 C: a APPEND drafts ANNOTATION ("/comment" 980 ("value.priv" "Don't send until we hear from Sally")) {310} 981 S: + Ready for literal data 982 C: MIME-Version: 1.0 983 ... 984 C: 985 S: a OK APPEND completed 987 In the above example, a comment with a private value is added to a 988 new message appended to the mailbox. The ellipsis represents the 989 bulk of the message. 991 4.8 ANNOTATION Criterion in SEARCH 993 ANNOTATION 995 The ANNOTATION criterion for the SEARCH command allows a client to 996 search for a specified string in the value of an annotation entry of 997 a message. 999 Messages that have annotations with entries matching and 1000 attributes matching and the specified string 1001 in their values are returned in the SEARCH results. The "*" 1002 character can be used in the entry or attribute name fields to match 1003 any content in those items. The "%" character can be used in the 1004 entry or attribute name fields to match a single level of hierarchy 1005 only. 1007 Example: 1009 C: a SEARCH ANNOTATION "/comment" "value" "IMAP4" 1010 S: * SEARCH 2 3 5 7 11 13 17 19 23 1011 S: a OK Search complete 1013 In the above example, the message numbers of any messages 1014 containing the string "IMAP4" in the shared or private "value" 1015 attribute of the "/comment" entry are returned in the search 1016 results. 1018 Example: 1020 C: a SEARCH ANNOTATION "*" "*" "IMAP4" 1021 S: * SEARCH 1 2 3 5 8 13 21 34 1022 S: a OK Search complete 1024 In the above example, the message numbers of any messages 1025 containing the string "IMAP4" in any attribute (public or private) 1026 of any entry are returned in the search results. 1028 4.9 ANNOTATION Key in SORT 1030 ANNOTATION 1032 The ANNOTATION criterion for the SORT command [SORT] instructs the 1033 server to return the message numbers or UIDs of a mailbox, sorted 1034 using the values of the specified annotations. The ANNOTATION 1035 criterion is available if the server returns both ANNOTATE and SORT 1036 as supported capabilities in the CAPABILITY command response. 1038 Messages are sorted using the values of the 1039 attributes in the entries. (The charset argument 1040 determines sort order, as specified in the SORT extension 1041 description.) 1043 Example: 1045 C: a SORT (ANNOTATION "/altsubject" "value.shared") UTF-8 ALL 1046 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 1047 S: a OK Sort complete 1049 In the above example, the message numbers of all messages are 1050 returned, sorted according to the shared "value" attribute of the 1051 "/altsubject" entry. 1053 Note that the ANNOTATION sort key must include a fully specified 1054 entry and attribute -- wildcards are not allowed. 1056 4.10 New ACL Rights 1058 As discussed in Section 3.4 this extension adds a new "n" right to 1059 the list of rights provided by the ACL extensions [RFC2086] and 1060 [ACLUPD]. 1062 5. Formal Syntax 1064 The following syntax specification uses the Augmented Backus-Naur 1065 Form (ABNF) notation as specified in [RFC2234]. 1067 Non-terminals referenced but not defined below are as defined by 1068 [RFC3501] with the new definitions in [ABNFEXT] superceding those in 1069 [RFC3501]. 1071 Except as noted otherwise, all alphabetic characters are 1072 case-insensitive. The use of upper or lower case characters to 1073 define token strings is for editorial clarity only. Implementations 1074 MUST accept these strings in a case-insensitive fashion. 1076 append-ext =/ att-annotate 1077 ; modifies [RFC3501] extension behaviour 1079 att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 1081 att-match = string 1082 ; dot-separated attribute name 1083 ; MAY contain "*" or "%" for use as wildcards 1085 att-value = attrib SP value 1087 attrib = string 1088 ; dot-separated attribute name 1089 ; MUST NOT contain "*" or "%" 1091 attribs = att-match / 1092 "(" att-match *(SP att-match) ")" 1094 capability =/ "ANNOTATE" 1095 ; defines the capability for this extension 1097 entries = entry-match / 1098 "(" entry-match *(SP entry-match) ")" 1100 entry = string 1101 ; slash-separated path to entry 1102 ; MUST NOT contain "*" or "%" 1104 entry-att = entry SP "(" att-value *(SP att-value) ")" 1106 entry-match = string 1107 ; slash-separated path to entry 1108 ; MAY contain "*" or "%" for use as wildcards 1110 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 1111 ; modifies original IMAP fetch-att 1113 msg-att-dynamic =/ "ANNOTATION" SP 1114 ( "(" entry-att *(SP entry-att) ")" / 1115 "(" entry *(SP entry) ")" ) 1116 ; extends FETCH response with annotation data 1118 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 1119 "ANNOTATE" SP "TOOMANY" / 1120 "ANNOTATESIZE" SP (number / nil) 1121 ; new response codes 1123 search-key =/ "ANNOTATION" SP entry-match SP att-match 1124 SP value 1125 ; modifies original IMAP search-key 1127 select-param =/ "ANNOTATE" 1128 ; defines the select parameter used with 1129 ; ANNOTATE extension 1131 sort-key =/ "ANNOTATION" SP entry SP attrib 1132 ; modifies original sort-key 1134 store-att-flags =/ att-annotate 1135 ; modifies original IMAP STORE command 1137 value = nstring / literal8 1139 6. IANA Considerations 1141 Both entry names and attribute names MUST be specified in a standards 1142 track or IESG approved experimental RFC, or fall under the vendor 1143 namespace. Vendor names MUST be registered. Each entry registration 1144 MUST include a recommended content-type that is used to indicate the 1145 expected nature of the annotation value. 1147 6.1 Entry and Attribute Registration Template 1149 To: iana@iana.org 1150 Subject: IMAP Annotate Registration 1152 Please register the following IMAP Annotate item: 1154 [] Entry [] Attribute 1156 Name: ______________________________ 1158 Description: _______________________ 1160 ____________________________________ 1162 ____________________________________ 1164 Recommended Content-Type:___________ 1166 ____________________________________ 1168 Contact person: ____________________ 1170 email: ____________________ 1172 6.2 Entry Registrations 1174 The following templates specify the IANA registrations of annotation 1175 entries specified in this document. 1177 6.2.1 /comment 1179 To: iana@iana.org 1180 Subject: IMAP Annotate Registration 1182 Please register the following IMAP Annotate item: 1184 [X] Entry [] Attribute 1186 Name: /comment 1188 Description: Defined in IMAP ANNOTATE extension document. 1190 Recommended Content-Type: text/plain 1192 Contact person: Cyrus Daboo 1194 email: daboo@isamet.com 1196 6.2.2 /flags/\answered 1198 To: iana@iana.org 1199 Subject: IMAP Annotate Registration 1201 Please register the following IMAP Annotate item: 1203 [X] Entry [] Attribute 1205 Name: /flags/\answered 1207 Description: Defined in IMAP ANNOTATE extension document. 1209 Recommended Content-Type: text/plain 1211 Contact person: Cyrus Daboo 1213 email: daboo@isamet.com 1215 6.2.3 /flags/\flagged 1217 To: iana@iana.org 1218 Subject: IMAP Annotate Registration 1220 Please register the following IMAP Annotate item: 1222 [X] Entry [] Attribute 1224 Name: /flags/\flagged 1226 Description: Defined in IMAP ANNOTATE extension document. 1228 Recommended Content-Type: text/plain 1230 Contact person: Cyrus Daboo 1232 email: daboo@isamet.com 1234 6.2.4 /flags/\deleted 1236 To: iana@iana.org 1237 Subject: IMAP Annotate Registration 1239 Please register the following IMAP Annotate item: 1241 [X] Entry [] Attribute 1243 Name: /flags/\deleted 1245 Description: Defined in IMAP ANNOTATE extension document. 1247 Recommended Content-Type: text/plain 1249 Contact person: Cyrus Daboo 1251 email: daboo@isamet.com 1253 6.2.5 /flags/\seen 1255 To: iana@iana.org 1256 Subject: IMAP Annotate Registration 1258 Please register the following IMAP Annotate item: 1260 [X] Entry [] Attribute 1262 Name: /flags/\seen 1264 Description: Defined in IMAP ANNOTATE extension document. 1266 Recommended Content-Type: text/plain 1268 Contact person: Cyrus Daboo 1270 email: daboo@isamet.com 1272 6.2.6 /flags/\draft 1274 To: iana@iana.org 1275 Subject: IMAP Annotate Registration 1277 Please register the following IMAP Annotate item: 1279 [X] Entry [] Attribute 1281 Name: /flags/\draft 1283 Description: Defined in IMAP ANNOTATE extension document. 1285 Recommended Content-Type: text/plain 1287 Contact person: Cyrus Daboo 1289 email: daboo@isamet.com 1291 6.2.7 /flags/\recent 1293 To: iana@iana.org 1294 Subject: IMAP Annotate Registration 1296 Please register the following IMAP Annotate item: 1298 [X] Entry [] Attribute 1300 Name: /flags/\recent 1302 Description: Defined in IMAP ANNOTATE extension document. 1304 Recommended Content-Type: text/plain 1306 Contact person: Cyrus Daboo 1308 email: daboo@isamet.com 1310 6.2.8 /flags/$mdnsent 1312 To: iana@iana.org 1313 Subject: IMAP Annotate Registration 1315 Please register the following IMAP Annotate item: 1317 [X] Entry [] Attribute 1319 Name: /flags/$mdnsent 1321 Description: Defined in IMAP ANNOTATE extension document. 1323 Recommended Content-Type: text/plain 1325 Contact person: Cyrus Daboo 1327 email: daboo@isamet.com 1329 6.2.9 /flags/$redirected 1331 To: iana@iana.org 1332 Subject: IMAP Annotate Registration 1334 Please register the following IMAP Annotate item: 1336 [X] Entry [] Attribute 1338 Name: /flags/$redirected 1340 Description: Defined in IMAP ANNOTATE extension document. 1342 Recommended Content-Type: text/plain 1344 Contact person: Cyrus Daboo 1346 email: daboo@isamet.com 1348 6.2.10 /flags/$forwarded 1350 To: iana@iana.org 1351 Subject: IMAP Annotate Registration 1353 Please register the following IMAP Annotate item: 1355 [X] Entry [] Attribute 1357 Name: /flags/$forwarded 1359 Description: Defined in IMAP ANNOTATE extension document. 1361 Recommended Content-Type: text/plain 1363 Contact person: Cyrus Daboo 1365 email: daboo@isamet.com 1367 6.2.11 /altsubject 1369 To: iana@iana.org 1370 Subject: IMAP Annotate Registration 1372 Please register the following IMAP Annotate item: 1374 [X] Entry [] Attribute 1376 Name: /altsubject 1378 Description: Defined in IMAP ANNOTATE extension document. 1380 Recommended Content-Type: text/plain 1382 Contact person: Cyrus Daboo 1384 email: daboo@isamet.com 1386 6.2.12 //comment 1388 To: iana@iana.org 1389 Subject: IMAP Annotate Registration 1391 Please register the following IMAP Annotate item: 1393 [X] Entry [] Attribute 1395 Name: //comment 1397 Description: Defined in IMAP ANNOTATE extension document. 1399 Recommended Content-Type: text/plain 1401 Contact person: Cyrus Daboo 1403 email: daboo@isamet.com 1405 6.2.13 //flags/seen 1407 To: iana@iana.org 1408 Subject: IMAP Annotate Registration 1410 Please register the following IMAP Annotate item: 1412 [X] Entry [] Attribute 1414 Name: //flags/seen 1416 Description: Defined in IMAP ANNOTATE extension document. 1418 Recommended Content-Type: text/plain 1420 Contact person: Cyrus Daboo 1422 email: daboo@isamet.com 1424 6.2.14 //flags/answered 1426 To: iana@iana.org 1427 Subject: IMAP Annotate Registration 1429 Please register the following IMAP Annotate item: 1431 [X] Entry [] Attribute 1433 Name: //flags/answered 1435 Description: Defined in IMAP ANNOTATE extension document. 1437 Recommended Content-Type: text/plain 1439 Contact person: Cyrus Daboo 1441 email: daboo@isamet.com 1443 6.2.15 //flags/flagged 1445 To: iana@iana.org 1446 Subject: IMAP Annotate Registration 1448 Please register the following IMAP Annotate item: 1450 [X] Entry [] Attribute 1452 Name: //flags/flagged 1454 Description: Defined in IMAP ANNOTATE extension document. 1456 Recommended Content-Type: text/plain 1458 Contact person: Cyrus Daboo 1460 email: daboo@isamet.com 1462 6.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 Recommended Content-Type: text/plain 1477 Contact person: Cyrus Daboo 1479 email: daboo@isamet.com 1481 6.3 Attribute Registrations 1483 The following templates specify the IANA registrations of annotation 1484 attributes specified in this document. 1486 6.3.1 value 1488 To: iana@iana.org 1489 Subject: IMAP Annotate Registration 1491 Please register the following IMAP Annotate item: 1493 [] Entry [X] Attribute 1495 Name: value 1497 Description: Defined in IMAP ANNOTATE extension document. 1499 Contact person: Cyrus Daboo 1501 email: daboo@isamet.com 1503 6.3.2 size 1505 To: iana@iana.org 1506 Subject: IMAP Annotate Registration 1508 Please register the following IMAP Annotate item: 1510 [] Entry [X] Attribute 1512 Name: size 1514 Description: Defined in IMAP ANNOTATE extension document. 1516 Contact person: Cyrus Daboo 1518 email: daboo@isamet.com 1520 6.3.3 content-type 1522 To: iana@iana.org 1523 Subject: IMAP Annotate Registration 1525 Please register the following IMAP Annotate item: 1527 [] Entry [X] Attribute 1529 Name: content-type 1531 Description: Defined in IMAP ANNOTATE extension document. 1533 Contact person: Cyrus Daboo 1535 email: daboo@isamet.com 1537 6.3.4 content-language 1539 To: iana@iana.org 1540 Subject: IMAP Annotate Registration 1542 Please register the following IMAP Annotate item: 1544 [] Entry [X] Attribute 1546 Name: content-language 1548 Description: Defined in IMAP ANNOTATE extension document. 1550 Contact person: Cyrus Daboo 1552 email: daboo@isamet.com 1554 6.3.5 display-name 1556 To: iana@iana.org 1557 Subject: IMAP Annotate Registration 1559 Please register the following IMAP Annotate item: 1561 [] Entry [X] Attribute 1563 Name: display-name 1565 Description: Defined in IMAP ANNOTATE extension document. 1567 Contact person: Cyrus Daboo 1569 email: daboo@isamet.com 1571 7. Security Considerations 1573 Annotations whose values are intended to remain private MUST be 1574 stored in ".priv" values, and not ".shared" values which may be 1575 accessible to other users. 1577 Excluding the above issues the ANNOTATE extension does not raise any 1578 security considerations that are not present in the base IMAP 1579 protocol, and these issues are discussed in [RFC3501]. 1581 8. References 1583 8.1 Normative References 1585 [ABNFEXT] Melnikov, A., "Collected extensions to IMAP4 ABNF", 1586 draft-melnikov-imap-ext-abnf-01.txt, March 2005. 1588 [ACLUPD] Melnikov, A., "IMAP4 ACL extension", 1589 draft-ietf-imapext-2086upd-02.txt, December 2004. 1591 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1592 Extensions (MIME) Part Two: Media Types", RFC 2046, 1593 November 1996. 1595 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1598 Requirement Levels", BCP 14, RFC 2119, March 1997. 1600 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1601 Specifications: ABNF", RFC 2234, November 1997. 1603 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1604 Configuration Access Protocol", RFC 2244, November 1997. 1606 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 1607 2002. 1609 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1610 4rev1", RFC 3501, March 2003. 1612 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1613 MULTIAPPEND Extension", RFC 3502, March 2003. 1615 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1616 profile for Internet Message Access Protocol (IMAP)", RFC 1617 3503, March 2003. 1619 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1620 10646", STD 63, RFC 3629, November 2003. 1622 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 1623 Protocol - Sort and Thread Extension", 1624 draft-ietf-imapext-sort-17.txt, May 2004. 1626 8.2 Informative References 1628 [CONDSTORE] 1629 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1630 STORE operation", draft-ietf-imapext-condstore-05.txt, 1631 November 2003. 1633 Authors' Addresses 1635 Cyrus Daboo 1636 ISAMET, Inc. 1637 5001 Baum Blvd. 1638 Suite 650 1639 Pittsburgh, PA 15213 1640 US 1642 EMail: daboo@isamet.com 1643 Randall Gellens 1644 QUALCOMM Incorporated 1645 5775 Morehouse Dr. 1646 San Diego, CA 92121-2779 1647 US 1649 EMail: randy@qualcomm.com 1651 Appendix A. Acknowledgments 1653 Many thanks to Chris Newman for his detailed comments on the first 1654 draft of this document, and to the participants at the ACAP working 1655 dinner in Pittsburgh. The participants of the IMAPext working group 1656 made significant contributions to this work. 1658 Intellectual Property Statement 1660 The IETF takes no position regarding the validity or scope of any 1661 Intellectual Property Rights or other rights that might be claimed to 1662 pertain to the implementation or use of the technology described in 1663 this document or the extent to which any license under such rights 1664 might or might not be available; nor does it represent that it has 1665 made any independent effort to identify any such rights. Information 1666 on the procedures with respect to rights in RFC documents can be 1667 found in BCP 78 and BCP 79. 1669 Copies of IPR disclosures made to the IETF Secretariat and any 1670 assurances of licenses to be made available, or the result of an 1671 attempt made to obtain a general license or permission for the use of 1672 such proprietary rights by implementers or users of this 1673 specification can be obtained from the IETF on-line IPR repository at 1674 http://www.ietf.org/ipr. 1676 The IETF invites any interested party to bring to its attention any 1677 copyrights, patents or patent applications, or other proprietary 1678 rights that may cover technology that may be required to implement 1679 this standard. Please address the information to the IETF at 1680 ietf-ipr@ietf.org. 1682 Disclaimer of Validity 1684 This document and the information contained herein are provided on an 1685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1687 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1688 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1689 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1692 Copyright Statement 1694 Copyright (C) The Internet Society (2005). This document is subject 1695 to the rights, licenses and restrictions contained in BCP 78, and 1696 except as set forth therein, the authors retain all their rights. 1698 Acknowledgment 1700 Funding for the RFC Editor function is currently provided by the 1701 Internet Society.