idnits 2.17.00 (12 Aug 2021) /tmp/idnits51643/draft-ietf-imapext-annotate-11.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 1614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1604. ** 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 == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 36) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 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 (October 23, 2004) is 6418 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 80, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 80, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 569, but not defined == Missing Reference: 'READ-ONLY' is mentioned on line 558, but not defined == Missing Reference: 'MULTIAPPEND' is mentioned on line 1060, but not defined == Missing Reference: 'X' is mentioned on line 1491, but not defined == Unused Reference: 'RFC1891' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1524, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** 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: draft-ietf-imapext-sort has been published as RFC 5256 == Outdated reference: draft-ietf-imapext-condstore has been published as RFC 4551 Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group R. Gellens 2 Internet-Draft QUALCOMM Incorporated 3 Expires: April 23, 2005 C. Daboo 4 ISAMET, Inc. 5 October 23, 2004 7 IMAP ANNOTATE Extension 8 draft-ietf-imapext-annotate-11 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 April 23, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 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 -10 to -11: 49 1. Flags are now read-only and exactly match their IMAP 50 counterparts. 51 2. Added new ACL bits for annotations. 52 3. Revise security considerations. 53 4. Fixed some references. 55 Changes from -09 to -10: 56 1. Added Content-Language value. 57 2. Added IANA registrations for entries/attributes in this document. 59 Changes from -08 to -09: 60 1. Fix formatting, ID nits etc. 61 2. Fix subject -> altsubject in examples. 62 3. Added text to SELECT/EXAMINE optional parameter definition to 63 indicate that the option could trigger a global state change or a 64 mailbox specific change. 65 4. Changed entry/attribute names to be case-sensitive to avoid case 66 mapping issues with utf8 text. 67 5. Clarify COPY interaction to indicate that only the current user's 68 '.priv's are copied, not the '.priv's of other users. 70 Changes from -07 to -08: 71 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 72 does not support any type of annotations, and "0" for a mailbox 73 that only supports read-only annotations. 75 Changes from -06 to -07: 76 1. Added text to state entry and attribute names are always 77 case-insensitive. 78 2. Removed top-level entry namespace. 79 3. Added server accept minima for annotation size and count. 80 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 81 5. Added [ANNOTATESIZE <>] response code. 82 6. Added comment on suggested CONDSTORE support. 83 7. Modified append behaviour to account for MULTIAPPEND. 84 8. Tweaked ABNF. 86 Changes from -05 to -06: 87 1. Split references into Normative and Informative. 88 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 89 name. 90 3. Removed smtp-envelope annotation - a future extension can add 91 this. 92 4. Changed subject to altsubject. 93 5. Added $MDNSent flag and reference to document. 94 6. Cleaned up formal syntax to use IMAP string type for entry and 95 attributes, with requirements on how the string is formatted. 97 7. Use of ACAP vendor subtree registry for vendor tokens. 98 8. Fixed STORE syntax. 100 Changes from -04 to -05: 101 1. Fixed examples to match formal syntax for FETCH responses where 102 parenthesis do not appear around entry-att items. 104 Changes from -03 to -04: 105 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 106 2. Add text for server to reject unknown . 107 3. Do not allow empty part-specifier. 108 4. Store NIL to value to delete. 109 5. Comment on COPY interaction with ANNOTATE. 110 6. Added comment that IMAP flags are mapped one-to-one with their 111 corresponding FLAGS items. 112 7. Added comment that the recent flag annotation is read-only. 114 Changes from -02 to -03: 115 1. Removed reference to status modtime item. 116 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 117 smtp-envelope. 118 3. Added requirement to store data permanently - no 'session only' 119 annotations. 120 4. Removed Access Control section. Replaced with comments on 121 read-only/read-write mailboxes and storing private or shared 122 annotations. 123 5. Removed STORE to default .priv or .shared. 124 6. Added section on optional select parameters. 126 Changes from -01 to -02: 127 1. Now require .priv or .shared on store operations. 129 Changes from -00 to -01: 130 1. MODTIME moved to its own draft, which this draft now depends on. 131 Thus, Conditional Annotation STORE and related items deleted from 132 this draft. 133 2. Private versus Shared Annotations: both are possible (separately 134 addressable using ".priv" and ".shared" suffixes). There is a 135 per-mailbox setting for the default. It is an open issue how 136 this is viewed or changed by the client. 137 3. In ACLs, the "w" right is needed to updated shared state; the "s" 138 right is needed to update private state. 139 4. Various clarifications and text modifications. 140 5. Added 'forwarded' flag for message parts. 142 Changes from pre-imapext to -00: 143 1. Clarified text describing attributions, entries, and attributes. 145 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 146 3. Deleted 'queued' flag. 147 4. Expanded and explained smtp-envelope entry. 148 5. Restricted including ANNOTATION data in unsolicited responses 149 until the client uses it first. (Open issue as to if needed). 150 6. Examples now only use valid entries and attributes. 151 7. Updated Security Considerations. 152 8. Content-Type now defaults to text/plain. 153 9. Open Issue: Shared vs. private annotations. 154 10. Open issue: Annotation Modtime untagged response or VALIDTIME 155 FETCH data. 156 11. Open issue: Conditional annotation STORE. 157 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 158 CAPABILITY command response. 159 13. Prohibition on annotations in lieu of base spec functionality. 160 14. Specified required ACL rights. 161 15. ANNOTATION message data item in APPEND. 162 16. ANNOTATION-MODTIME message data item in STATUS. 163 17. Replaced ATOM_CHAR with utf8-char. 164 18. Updated other ABNF entries. 166 Table of Contents 168 1. Introduction and Overview . . . . . . . . . . . . . . . . . 7 169 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 170 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 171 2.2 Namespace of entries and attributes . . . . . . . . . . . 8 172 2.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 9 173 2.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 11 174 2.3 Private versus Shared . . . . . . . . . . . . . . . . . . 12 175 2.4 Access Control . . . . . . . . . . . . . . . . . . . . . . 13 176 2.5 Access to Standard IMAP Flags and Keywords . . . . . . . . 15 177 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 15 178 3.1 General Considerations . . . . . . . . . . . . . . . . . . 15 179 3.2 Optional parameters with the SELECT/EXAMINE commands . . . 15 180 3.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 17 181 3.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 19 182 3.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 20 183 3.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 22 184 3.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 22 185 3.8 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 22 186 3.9 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 23 187 3.10 New ACL Rights . . . . . . . . . . . . . . . . . . . . . 24 188 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 24 189 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 190 5.1 Entry and Attribute Registration Template . . . . . . . . 26 191 5.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 26 192 5.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 27 193 5.2.2 /flags/\\answered . . . . . . . . . . . . . . . . . . 27 194 5.2.3 /flags/\\flagged . . . . . . . . . . . . . . . . . . . 28 195 5.2.4 /flags/\\deleted . . . . . . . . . . . . . . . . . . . 28 196 5.2.5 /flags/\\seen . . . . . . . . . . . . . . . . . . . . 29 197 5.2.6 /flags/\\draft . . . . . . . . . . . . . . . . . . . . 29 198 5.2.7 /flags/\\recent . . . . . . . . . . . . . . . . . . . 30 199 5.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 30 200 5.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 31 201 5.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 31 202 5.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 32 203 5.2.12 //comment . . . . . . . . . . . . . . 32 204 5.2.13 //flags/seen . . . . . . . . . . . . . 33 205 5.2.14 //flags/answered . . . . . . . . . . . 33 206 5.2.15 //flags/flagged . . . . . . . . . . . 34 207 5.2.16 //flags/forwarded . . . . . . . . . . 34 208 5.3 Attribute Registrations . . . . . . . . . . . . . . . . . 34 209 5.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 35 210 5.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 35 211 5.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 36 212 5.3.4 content-language . . . . . . . . . . . . . . . . . . . 36 213 6. Security Considerations . . . . . . . . . . . . . . . . . . 36 214 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 215 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 216 7.2 Informative References . . . . . . . . . . . . . . . . . . . 37 217 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 218 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 38 219 Intellectual Property and Copyright Statements . . . . . . . 39 221 1. Introduction and Overview 223 The ANNOTATE extension is present in any IMAP [RFC3501] 224 implementation which returns "ANNOTATE" as one of the supported 225 capabilities in the CAPABILITY response. 227 The ANNOTATE extension adds a new message data item to the FETCH and 228 STORE commands, as well as adding SEARCH and SORT keys and an APPEND 229 modifier. 231 This extension makes the following changes to the IMAP protocol: 233 a. adds a new ANNOTATION message data item for use in FETCH 234 b. adds a new ANNOTATION message data item for use in STORE 235 c. adds a new ANNOTATION search criterion for use in SEARCH 236 d. adds a new ANNOTATION sort key for use in SORT extension 237 e. adds a new ANNOTATION data item for use in APPEND 238 f. adds a new requirement on the COPY command 239 g. adds a extension mechanism for adding parameters to the SELECT/ 240 EXAMINE commands and defines the ANNOTATE parameter 241 h. adds two new response codes to indicate store failures of 242 annotations. 243 i. adds a new untagged response codes for the SELECT or EXAMINE 244 commands to indicate the maximum size. 245 j. adds two new ACL 'bits' for use with the ACL [RFC2086] extension. 247 The data model used for the storage of annotations is based on that 248 of the Application Configuration Access Protocol [RFC2244]. Note 249 that there is no inheritance in annotations. 251 Clients MUST NOT use annotations in lieu of equivalent IMAP base 252 specification facilities. For example, use of a "seen" flag in the 253 vendor namespace together with ".PEEK" in fetches. Such behaviour 254 would significantly reduce IMAP interoperability. 256 If a server supports annotations, then it MUST store all annotation 257 data permanently, i.e. there is no concept of 'session only' 258 annotations that would correspond to the behaviour of 'session' flags 259 as defined in the IMAP base specification. The exception to this is 260 IMAP flags (which are accessible directly through annotations) which 261 may be 'session only' as determined by the FLAGS and PERMANENTFLAGS 262 responses to a SELECT or EXAMINE command. 264 This extension also introduces a generalised mechanism for adding 265 parameters to the SELECT or EXAMINE commands. It is anticipated that 266 other extensions may want to utilise this, so it is not strictly 267 dependent on the ANNOTATE extension being present. 269 In order to provide optimum support for a disconnected client (one 270 that needs to synchronise annotations for use when offline), servers 271 SHOULD also support the Conditional STORE [CONDSTORE] extension. 273 The rest of this document describes the data model and protocol 274 changes more rigorously. 276 2. Data Model 278 2.1 Overview 280 The data model used in ANNOTATE is that of a uniquely named entry 281 which contains a set of standard attributes. A single coherent unit 282 of "metadata" for a message is stored as a single entry, made up of 283 several attributes. 285 For example, a comment added to a message has an entry name of "/ 286 comment". This entry is composed of several attributes such as 287 "value", "size", etc. which contain the properties and data of the 288 entry. 290 The protocol changes to IMAP described below allow a client to access 291 or change the values of any attributes in any entries in a message 292 annotation, assuming it has sufficient access rights to do so (see 293 Section 2.4 for specifics). 295 2.2 Namespace of entries and attributes 297 Each message annotation is made up of a set of entries. Each entry 298 has a hierarchical name in UTF-8, with each component of the name 299 separated by a slash ("/"). 301 Each entry is made up of a set of attributes. Each attribute has a 302 hierarchical name in UTF-8, with each component of the name separated 303 by a period ("."). 305 The value of an attribute is NIL (has no value), or is a string of 306 zero or more octets. 308 Entry and attribute names MUST NOT contain asterisk ("*") or percent 309 ("%") characters and MUST be valid UTF-8 strings which do not contain 310 the NULL octet. Invalid entry or attribute names result in a BAD 311 response in any IMAP commands where they are used. 313 Entry and attribute names are case-sensitive. 315 Use of non-visible UTF-8 characters in entry and attribute names is 316 strongly discouraged. 318 This specification defines an initial set of entry and attribute 319 names available for use in message annotations. In addition, an 320 extension mechanism is described to allow additional names to be 321 added for extensibility. 323 2.2.1 Entry Names 325 Entry names MUST be specified in a standards track or IESG approved 326 experimental RFC, or fall under the vendor namespace. See Section 327 5.1 for the registration template. 329 / 330 Defines the top-level of entries associated with an entire 331 message. This entry itself does not contain any attributes. All 332 entries that start with a numeric character ("0" - "9") refer to 333 an annotation on a specific body part. All other entries are for 334 annotations on the entire message. 336 /comment 337 Defines a comment or note associated with an entire message. 339 /flags 340 Defines the top-level of entries for flags associated with an 341 entire message. The "value" attribute of each of the entries 342 described below must be either "1", "0" or NIL. "1" corresponds 343 to the flag being set. 345 Standard [RFC3501] flags always have a '\' prefix character. 346 Other standard flags have a '$' prefix. The annotation names used 347 for all flags uses the complete name for that flag, including the 348 prefix character. 350 Flag annotations are read-only. Clients MUST NOT attempt to 351 change them via the annotation entries, using instead the normal 352 IMAP STORE FLAGS command. 354 The set of standard IMAP flags annotations are: 356 /flags/\answered 357 /flags/\flagged 358 /flags/\deleted 359 /flags/\seen 360 /flags/\draft 361 /flags/\recent 363 Note that entry names are sent as IMAP string elements which 364 requires that '\' characters be escaped if sent as a quoted string 365 as opposed to a literal. 367 Note that flag and keyword names in IMAP are case-insensitive, 368 however the entry names for the corresponding annotations are 369 case-sensitive. Thus the IMAP flag and keyword names MUST be 370 mapped to lowercase characters before being used as entry names 371 for annotations. 373 Additional standard flags are: 375 /flags/$mdnsent 376 /flags/$redirected 377 /flags/$forwarded 379 The '$mdnsent' flag is used to indicate message disposition 380 notification processing state [RFC3503]. 382 The '$redirected' flag indicates that a message has been handed 383 off to someone else, by resending the message with minimal 384 alterations, and in such a way that a reply by the new 385 recipient is addressed to the original author, not the user who 386 performed the redirection. 388 The '$forwarded' flag indicates the message was resent to 389 another user, embedded within or attached to a new message. 391 /altsubject 392 Contains text supplied by the message recipient, to be used by the 393 client instead of the original message Subject. 395 /vendor/ 396 Defines the top-level of entries associated with an entire message 397 as created by a particular product of some vendor. These 398 sub-entries can be used by vendors to provide client-specific 399 attributes. The vendor-token MUST be registered with IANA, using 400 the [RFC2244] vendor subtree registry. 402 / 403 Defines the top-level of entries associated with a specific body 404 part of a message. This entry itself does not contain any 405 attributes. The section-part uses the same numeric part specifier 406 syntax as the BODY message data item in the FETCH command 407 [RFC3501]. The server MUST return a BAD response if the client 408 uses an incorrect part specifier (either incorrect syntax or a 409 specifier referring to a non-existent part). The server MUST 410 return a BAD response if the client uses an empty part specifier 411 (which is used in IMAP to represent the entire message). 413 //comment 414 Defines a comment or note associated with a specific body part of 415 a message. 417 //flags 418 Defines the top-level of entries associated with flag state for a 419 specific body part of a message. All sub-entries are maintained 420 entirely by the client. There is no implicit change to any flag 421 by the server. 423 //flags/seen 424 //flags/answered 425 //flags/flagged 426 //flags/forwarded 428 Defines flags for a specific body part of a message. The "value" 429 attribute of these entries must be either "1", "0" or NIL. 431 //vendor/ 432 Defines the top-level of entries associated with a specific body 433 part of a message as created by a particular product of some 434 vendor. This entry can be used by vendors to provide client 435 specific attributes. The vendor-token MUST be registered with 436 IANA. 438 2.2.2 Attribute Names 440 Attribute names MUST be specified in a standards track or IESG 441 approved experimental RFC, or fall under the vendor namespace. See 442 Section 5.1 for the registration template. 444 All attribute names implicitly have a ".priv" and a ".shared" suffix 445 which maps to private and shared versions of the entry. Searching or 446 fetching without using either suffix includes both. The client MUST 447 specify either a ".priv" or ".shared" suffix when storing an 448 annotation. 450 value 451 A UTF8 string representing the data value of the attribute. To 452 delete an annotation, the client can store NIL into the value. 454 size 455 The size of the value, in octets. Set automatically by the 456 server, read-only to clients. 458 content-type 459 A MIME [RFC2046] content type and subtype that describes the 460 nature of the content of the "value" attribute. If not present, a 461 value of "text/plain; charset=utf8" is assumed. 463 content-language 464 Indicates the language used for the value. This follows the 465 format described in [RFC3282]. Clients SHOULD set this value when 466 storing an annotation that uses text that can be presented to the 467 user. It is not required for enumerated or numeric values such as 468 flags etc. 470 vendor. 471 Defines an attribute associated with a particular product of some 472 vendor. This attribute can be used by vendors to provide client 473 specific attributes. The vendor-token MUST be registered with 474 IANA, using the [RFC2244] vendor subtree registry. 476 2.3 Private versus Shared 478 Some IMAP mailboxes are private, accessible only to the owning user. 479 Other mailboxes are not, either because the owner has set an ACL 480 [RFC2086] which permits access by other users, or because it is a 481 shared mailbox. 483 This raises the issue of shared versus private annotations. 485 If all annotations are private, it is impossible to set annotations 486 in a shared or otherwise non-private mailbox that are visible to 487 other users. This eliminates what could be a useful aspect of 488 annotations in a shared environment. An example of such use is a 489 shared IMAP folder containing bug reports. Engineers may want to use 490 annotations to add information to existing messages, indicate 491 assignments, status, etc. This use requires shared annotations. 493 If all annotations are shared, it is impossible to use annotations 494 for private notes on messages in shared mailboxes. Also, modifying 495 an ACL to permit access to a mailbox by other users may 496 unintentionally expose private information. 498 There are also situations in which both shared and private 499 annotations are useful. For example, an administrator may want to 500 set shared annotations on messages in a shared folder, which 501 individual users may wish to supplement with additional notes. 503 If shared and private annotations are to coexist, we need a clear way 504 to differentiate them. Also, it should be as easy as possible for a 505 client to access both and not overlook either. There is also a 506 danger in allowing a client to store an annotation without knowing if 507 it is shared or private. 509 This document proposes two standard suffixes for all attributes: 510 ".shared" and ".priv". A search, fetch, or sort which specifies 511 neither uses both. Store operations MUST explicitly use .priv or 512 .shared suffixes. 514 2.4 Access Control 516 A user needs to have appropriate rights in order to read or write 517 .priv or .shared annotation values. How those rights are calculated 518 depends on whether the ACL [RFC2086] extension is present or not. If 519 a client attempts to store or fetch an annotation to which they do 520 not have the appropriate rights, the server MUST respond with a NO 521 response. 523 When the ACL extension is not present, access to annotation values is 524 governed by the nature of the selected state. In particular whether 525 the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE 526 mode. 528 When the ACL extension is present, the server MUST recognise two new 529 ACL rights, 'm' and 'n', in addition to the ones defined by the ACL 530 extension itself. 532 The 'm' right controls both read and write access to .priv annotation 533 values. When it is on, access to .priv annotations is allowed, when 534 it is off, access to .priv annotations is disallowed. 536 The 'r' right controls only the read access for .shared annotation 537 values. When it is on, .shared annotations can be read, when it is 538 off, .shared annotations cannot be read. 540 The 'n' right controls only the write access for .shared annotation 541 values. When it is on, .shared annotations can be changed, when it 542 is off, .shared annotations cannot be changed. The 'n' right MUST 543 NOT be present if the 'r' is not present. 545 A summary of all the access control restrictions is tabulated below 547 +---------------+---------------+-----------------------------------+ 548 | Server Type | Action on | Type of mailbox | 549 | | annotation | | 550 +===============+===============+===================================+ 551 | | | | 552 | | read .priv | Any mailbox that can be SELECTED | 553 | | values | or EXAMINED. | 554 | | | | 555 | +---------------+-----------------------------------+ 556 | | | | 557 | | write .priv | Any SELECTED [READ-WRITE] mailbox.| 558 | | values | SELECTED [READ-ONLY] mailboxes MAY| 559 | Server | | also permit writes. | 560 | without | | | 561 | ACL Extension +---------------+-----------------------------------+ 562 | | | | 563 | | read .shared | Any mailbox that can be SELECTED | 564 | | values | or EXAMINED. | 565 | | | | 566 | +---------------+-----------------------------------+ 567 | | | | 568 | | write .shared | Any mailbox that can be SELECTED | 569 | | values | or EXAMINED and is [READ-WRITE]. | 570 | | | | 571 +---------------+---------------+-----------------------------------+ 572 | | | | 573 | | read .priv | Any mailbox with the 'm' | 574 | | values | ACL right. | 575 | | | | 576 | +---------------+-----------------------------------+ 577 | | | | 578 | | write .priv | Any mailbox with the 'm' | 579 | Server | values | ACL right. | 580 | with | | | 581 | ACL Extension +---------------+-----------------------------------+ 582 | | | | 583 | | read .shared | Any mailbox with the 'r' | 584 | | values | ACL right. | 585 | | | | 586 | +---------------+-----------------------------------+ 587 | | | | 588 | | write .shared | Any mailbox with the 'n' | 589 | | values | ACL right. | 590 | | | | 591 +---------------+---------------+-----------------------------------+ 593 2.5 Access to Standard IMAP Flags and Keywords 595 Flags cannot be changed through annotations due to ambiguity of how 596 private and shared values would map to the base IMAP flag and keyword 597 values. As a result the /flags annotation values are treated as 598 read-only and MUST NOT be changed by a client. In turn this means 599 that the .priv and .shared values of a flag annotation are always the 600 same and represent the value of the base IMAP flag or keyword. 602 Clients that need to implement shared and private 'flags' can create 603 their own annotation entries for those, completely bypassing the base 604 IMAP flag/keyword behaviour. 606 3. IMAP Protocol Changes 608 3.1 General Considerations 610 The server is allowed to impose limitations on the size of any one 611 annotation or the total number of annotations for a single message. 612 However, the server MUST accept a minimum annotation data size of at 613 least 1024 bytes, and a minimum annotation count per message of at 614 least 10. 616 The server SHOULD indicate the maximum size for an annotation value 617 by sending an untagged "ANNOTATESIZE" response during a SELECT or 618 EXAMINE command. Clients MUST NOT store annotation values of a size 619 greater than the amount indicated by the server in the "ANNOTATESIZE" 620 response. 622 In some cases, servers may be able to offer annotations on some 623 mailboxes and not others, or may be able to provide only read-only 624 annotations on some mailboxes. For mailboxes that cannot have 625 annotations associated with them, the server MUST return an 626 "ANNOTATESIZE" response with a value of "NIL" during the SELECT or 627 EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch 628 or store annotations on any messages in a mailbox for which the 629 "ANNOTATESIZE" response was "NIL". For mailboxes that can only have 630 read-only annotations associated with them, the server MUST return an 631 "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT 632 or EXAMINE command for that mailbox. Clients MUST NOT attempt to 633 store annotations on any messages in a mailbox for which the 634 "ANNOTATESIZE" response was zero. 636 3.2 Optional parameters with the SELECT/EXAMINE commands 638 This extension adds the ability to include one or more parameters 639 with the IMAP SELECT or EXAMINE commands, to turn on or off certain 640 standard behaviour, or to add new optional behaviours required for a 641 particular extension. 643 There are two possible modes of operation: 645 o A global state change where a single use of the optional parameter 646 will effect the session state from that time on, irrespective of 647 subsequent SELECT/EXAMINE commands. 649 o A per-mailbox state change that will effect the session only for 650 the duration of the new selected state. A subsequent SELECT/ 651 EXAMINE without the optional parameter will cancel its effect for 652 the newly selected mailbox. 654 It is anticipated that other extensions may want to use this 655 facility, so a generalised approach is given here. This facility is 656 not dependent on the presence of the ANNOTATE extension - other 657 extensions can use it with a server that does not implement ANNOTATE. 659 Optional parameters to the SELECT or EXAMINE commands are added as a 660 parenthesised list of atoms or strings, and appear after the mailbox 661 name in the standard SELECT or EXAMINE command. The order of 662 individual parameters is arbitrary. Individual parameters may 663 consist of one or more atoms or strings in a specific order. If a 664 parameter consists of more than one atom or string, it MUST appear in 665 its own parenthesised list. Any parameter not defined by extensions 666 that the server supports MUST be rejected with a NO response. 668 Example: 670 C: a SELECT INBOX (ANNOTATE) 671 S: ... 672 S: a OK SELECT complete 674 In the above example, a single parameter is used with the SELECT 675 command. 677 Example: 679 C: a EXAMINE INBOX (ANNOTATE (RESPONSES "UID Responses") CONDSTORE) 680 S: ... 681 S: a OK EXAMINE complete 683 In the above example, three parameters are used with the EXAMINE 684 command. The second parameter consists of two items: an atom 685 followed by a quoted string. 687 Example: 689 C: a SELECT INBOX (BLURDYBLOOP) 690 S: a NO Unknown parameter in SELECT command 692 In the above example, a parameter not supported by the server is 693 incorrectly used. 695 The ANNOTATE extension defines a single optional select parameter 696 "ANNOTATE", which is used to turn on unsolicited responses for 697 annotations as described in Section 3.4. This option al parameter is 698 results in a per-mailbox state change, i.e. it must be used in each 699 SELECT/EXAMINE command in order to be effective, irrespective of 700 whether it was used in a previous SELECT/EXAMINE during the same 701 session. 703 3.3 ANNOTATION Message Data Item in FETCH Command 705 This extension adds an ANNOTATION message data item to the FETCH 706 command. This allows clients to retrieve annotations for a range of 707 messages in the currently selected mailbox. 709 ANNOTATION 711 The ANNOTATION message data item, when used by the client in the 712 FETCH command, takes an entry specifier and an attribute 713 specifier. 715 Example: 717 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 718 S: * 1 FETCH (ANNOTATION ("/comment" 719 ("value.priv" "My comment" 720 "value.shared" "Group note"))) 721 S: a OK Fetch complete 723 In the above example, the content of the "value" attribute for the 724 "/comment" entry is requested by the client and returned by the 725 server. Since neither ".shared" nor ".priv" was specified, both 726 are returned. 728 "*" and "%" wildcard characters can be used in either specifier to 729 match one or more characters at that position, with the exception 730 that "%" does not match the hierarchy delimiter for the specifier it 731 appears in (that is, "/" for an entry specifier or "." for an 732 attribute specifier). Thus an entry specifier of "/%" matches 733 entries such as "/comment" and "/altsubject", but not "/flags/ 734 $redirected". 736 Example: 738 C: a FETCH 1 (ANNOTATION ("/*" ("value.priv" "size.priv"))) 739 S: * 1 FETCH (ANNOTATION 740 ("/comment" ("value.priv" "My comment" 741 "size.priv" "10") 742 "/altsubject" ("value.priv" "Rhinoceroses!" 743 "size.priv" "13") 744 "/vendor/foobar/label.priv" 745 ("value.priv" "label43" 746 "size.priv" "7") 747 "/vendor/foobar/personality" 748 ("value.priv" "Tallulah Bankhead" 749 "size.priv" "17"))) 750 S: a OK Fetch complete 752 In the above example, the contents of the private "value" and 753 "size" attributes for any entries in the "" hierarchy are 754 requested by the client and returned by the server. 756 Example: 758 C: a FETCH 1 (ANNOTATION ("/%" "value.shared")) 759 S: * 1 FETCH (ANNOTATION 760 ("/comment" ("value.shared" "Patch Mangler") 761 "/altsubject" ("value.shared" "Patches? We don't 762 need no steenkin patches!"))) 763 S: a OK Fetch complete 765 In the above example, the contents of the shared "value" 766 attributes for entries at the top level only of the "" hierarchy 767 are requested by the client and returned by the server. 769 Entry and attribute specifiers can be lists of atomic specifiers, so 770 that multiple items of each type may be returned in a single FETCH 771 command. 773 Example: 775 C: a FETCH 1 (ANNOTATION 776 (("/comment" "/altsubject") "value.priv")) 777 S: * 1 FETCH (ANNOTATION 778 ("/comment" ("value.priv" "What a chowder-head") 779 "/altsubject" ("value.priv" "How to crush beer cans"))) 780 S: a OK Fetch complete 782 In the above example, the contents of the private "value" 783 attributes for the two entries "/comment" and "/altsubject" are 784 requested by the client and returned by the server. 786 3.4 ANNOTATION Message Data Item in FETCH Response 788 The ANNOTATION message data item in the FETCH response displays 789 information about annotations in a message. 791 ANNOTATION parenthesised list 793 The response consists of a list of entries, each of which has a 794 list of attribute-value pairs. 796 Example: 798 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 799 S: * 1 FETCH (ANNOTATION ("/comment" 800 ("value.priv" "My comment" 801 "value.shared" NIL))) 802 S: a OK Fetch complete 804 In the above example, a single entry with a single attribute-value 805 pair is returned by the server. Since the client did not specify 806 a ".shared" or ".priv" suffix, both are returned. Only the 807 private attribute has a value (the shared value is NIL). 809 Example: 811 C: a FETCH 1 (ANNOTATION 812 (("/comment" "/altsubject") "value")) 813 S: * 1 FETCH (ANNOTATION 814 ("/comment" ("value.priv" "My comment" 815 "value.shared" NIL) 816 "/altsubject" ("value.priv" "My subject" 817 "value.shared" NIL))) 818 S: a OK Fetch complete 820 In the above example, two entries each with a single 821 attribute-value pair are returned by the server. Since the client 822 did not specify a ".shared" or ".priv" suffix, both are returned. 823 Only the private attributes have values; the shared attributes are 824 NIL. 826 Example: 828 C: a FETCH 1 (ANNOTATION 829 ("/comment" ("value" "size"))) 830 S: * 1 FETCH (ANNOTATION 831 ("/comment" 832 ("value.priv" "My comment" 833 "value.shared" NIL 834 "size.priv" "10" 835 "size.shared" "0"))) 836 S: a OK Fetch complete 838 In the above example, a single entry with two attribute-value 839 pairs is returned by the server. Since the client did not specify 840 a ".shared" or ".priv" suffix, both are returned. Only the 841 private attributes have values; the shared attributes are NIL. 843 Servers MUST NOT include ANNOTATION data in unsolicited responses 844 unless the client used the ANNOTATE select parameter when it issued 845 the last SELECT or EXAMINE command. This restriction avoids sending 846 ANNOTATION data to a client unless the client explicitly asks for it. 848 Servers SHOULD send ANNOTATION message data items in unsolicited 849 FETCH responses if an annotation entry is changed by a third-party, 850 and the ANNOTATE select parameter was used. This allows servers to 851 keep clients updated with changes to annotations by other clients. 853 3.5 ANNOTATION Message Data Item in STORE 855 ANNOTATION 857 Sets the specified list of entries by adding or replacing the 858 specified attributes with the values provided. Clients can use 859 NIL for values of attributes it wants to remove from entries. 861 The ANNOTATION message data item used with the STORE command has an 862 implicit ".SILENT" behaviour. This means the server does not 863 generate an untagged FETCH in response to the STORE command and 864 assumes that the client updates its own cache if the command 865 succeeds. 867 If the server is unable to store an annotation because the size of 868 its value is too large, the server MUST return a tagged NO response 869 with a "[ANNOTATE TOOBIG]" response code. 871 If the server is unable to store a new annotation because the maximum 872 number of allowed annotations has already been reached, the server 873 MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response 874 code. 876 Example: 878 C: a STORE 1 ANNOTATION ("/comment" 879 ("value.priv" "My new comment")) 880 S: a OK Store complete 882 In the above example, the entry "/comment" is created (if not 883 already present) and the private attribute "value" with data set 884 to "My new comment" is created if not already present, or replaced 885 if it exists. 887 Example: 889 C: a STORE 1 ANNOTATION ("/comment" 890 ("value.shared" NIL)) 891 S: a OK Store complete 893 In the above example, the shared "value" attribute of the entry "/ 894 comment" is removed by storing NIL into the attribute. 896 Multiple entries can be set in a single STORE command by listing 897 entry-attribute-value pairs in the list. 899 Example: 901 C: a STORE 1 ANNOTATION ("/comment" 902 ("value.priv" "Get tix Tuesday") 903 "/altsubject" 904 ("value.priv" "Wots On")) 905 S: a OK Store complete 907 In the above example, the entries "/comment" and "/altsubject" are 908 created (if not already present) and the private attribute "value" 909 is created for each entry if not already present, or replaced if 910 they exist. 912 Multiple attributes can be set in a single STORE command by listing 913 multiple attribute-value pairs in the entry list. 915 Example: 917 C: a STORE 1 ANNOTATION ("/comment" 918 ("value.priv" "My new comment" 919 "vendor.foobar.priv" "foo's bar")) 920 S: a OK Store complete 922 In the above example, the entry "/comment" is created (if not already 923 present) and the private attributes "value" and "vendor.foobar" are 924 created if not already present, or replaced if they exist. 926 3.6 ANNOTATION interaction with COPY 928 The COPY command can be used to move messages from one mailbox to 929 another on the same server. Servers that support the ANNOTATION 930 extension MUST, for each message being copied, copy all '.priv' 931 annotation data for the current user only, and all '.shared' 932 annotation data along with the message to the new mailbox. The only 933 exceptions to this are if the destination mailbox permissions are 934 such that either the '.priv' or '.shared' annotations are not 935 allowed, or if the destination mailbox is of a type that does not 936 support annotations or does not support storing of annotations (a 937 mailbox that returns a zero or "NIL" value for its ANNOTATESIZE 938 response code). Servers MUST NOT copy '.priv' annotation data for 939 users other than the current user. 941 3.7 ANNOTATION Message Data Item in APPEND 943 ANNOTATION 945 Sets the specified list of entries and attributes in the resulting 946 message. 948 The APPEND command can include annotations for the message being 949 appended via the addition of a new append data item. The new data 950 item can also be used with the multi-append [RFC3502] extension that 951 allows multiple messages to be appended via a single APPEND command. 953 Example: 955 C: a APPEND drafts ANNOTATION ("/comment" 956 ("value.priv" "Don't send until we hear from Sally")) {310} 957 S: + Ready for literal data 958 C: MIME-Version: 1.0 959 ... 960 C: 961 S: a OK APPEND completed 963 In the above example, a comment with a private value is added to a 964 new message appended to the mailbox. The ellipsis represents the 965 bulk of the message. 967 3.8 ANNOTATION Criterion in SEARCH 969 ANNOTATION 971 The ANNOTATION criterion for the SEARCH command allows a client to 972 search for a specified string in the value of an annotation entry of 973 a message. 975 Messages that have annotations with entries matching and 976 attributes matching and the specified string 977 in their values are returned in the SEARCH results. The "*" 978 character can be used in the entry or attribute name fields to match 979 any content in those items. The "%" character can be used in the 980 entry or attribute name fields to match a single level of hierarchy 981 only. 983 Example: 985 C: a SEARCH ANNOTATION "/comment" "value" "IMAP4" 986 S: * SEARCH 2 3 5 7 11 13 17 19 23 987 S: a OK Search complete 989 In the above example, the message numbers of any messages 990 containing the string "IMAP4" in the shared or private "value" 991 attribute of the "/comment" entry are returned in the search 992 results. 994 Example: 996 C: a SEARCH ANNOTATION "*" "*" "IMAP4" 997 S: * SEARCH 1 2 3 5 8 13 21 34 998 S: a OK Search complete 1000 In the above example, the message numbers of any messages 1001 containing the string "IMAP4" in any attribute (public or private) 1002 of any entry are returned in the search results. 1004 3.9 ANNOTATION Key in SORT 1006 ANNOTATION 1008 The ANNOTATION criterion for the SORT command [SORT] instructs the 1009 server to return the message numbers or UIDs of a mailbox, sorted 1010 using the values of the specified annotations. The ANNOTATION 1011 criterion is available if the server returns both "ANNOTATE" and 1012 "SORT" as supported capabilities in the CAPABILITY command response. 1014 Messages are sorted using the values of the 1015 attributes in the entries. (The charset argument 1016 determines sort order, as specified in the SORT extension 1017 description.) 1019 Example: 1021 C: a SORT (ANNOTATION "/altsubject" "value.shared") UTF-8 ALL 1022 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 1023 S: a OK Sort complete 1025 In the above example, the message numbers of all messages are 1026 returned, sorted according to the shared "value" attribute of the 1027 "/altsubject" entry. 1029 Note that the ANNOTATION sort key must include a fully specified 1030 entry and attribute -- wildcards are not allowed. 1032 3.10 New ACL Rights 1034 As discussed in Section 2.4 this extension adds new 'm' and 'n' 1035 rights to the list of rights provided by the ACL [RFC2086] extension. 1037 4. Formal Syntax 1039 The following syntax specification uses the Augmented Backus-Naur 1040 Form (ABNF) notation as specified in [RFC2234]. 1042 Non-terminals referenced but not defined below are as defined by 1043 [RFC3501]. 1045 Except as noted otherwise, all alphabetic characters are 1046 case-insensitive. The use of upper or lower case characters to 1047 define token strings is for editorial clarity only. Implementations 1048 MUST accept these strings in a case-insensitive fashion. 1050 annotate-param = "ANNOTATE" 1051 ; defines the select parameter used with 1052 ; ANNOTATE extension 1054 append = "APPEND" SP mailbox [SP flag-list] [SP date-time] 1055 [SP "ANNOTATION" SP att-annotate] SP literal 1056 ; modifies original IMAP APPEND command 1058 append-message = [SP flag-list] [SP date-time] 1059 [SP "ANNOTATION" SP att-annotate] SP literal 1060 ; modifies [MULTIAPPEND] extension behaviour 1062 att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 1064 att-match = string 1065 ; dot-separated attribute name 1066 ; MAY contain "*" or "%" for use as wildcards 1068 att-value = attrib SP value 1069 attrib = string 1070 ; dot-separated attribute name 1071 ; MUST NOT contain "*" or "%" 1073 attribs = att-match / 1074 "(" att-match *(SP att-match) ")" 1076 entries = entry-match / 1077 "(" entry-match *(SP entry-match) ")" 1079 entry = string 1080 ; slash-separated path to entry 1081 ; MUST NOT contain "*" or "%" 1083 entry-att = entry SP "(" att-value *(SP att-value) ")" 1085 entry-match = string 1086 ; slash-separated path to entry 1087 ; MAY contain "*" or "%" for use as wildcards 1089 examine =/ *(SP "(" select-param *(SP select-param) ")" 1090 ; modifies the original IMAP examine command to 1091 ; accept optional parameters 1093 fetch-ann-resp = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 1095 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 1096 ; modifies original IMAP fetch-att 1098 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 1099 "ANNOTATE" SP "TOOMANY" / 1100 "ANNOTATESIZE" SP (number / "NIL") 1101 ; new response codes 1103 search-key =/ "ANNOTATION" SP entry-match SP att-match 1104 SP value 1105 ; modifies original IMAP search-key 1107 select =/ *(SP "(" select-param *(SP select-param) ")" 1108 ; modifies the original IMAP select command to 1109 ; accept optional parameters 1111 select-param = astring / "(" astring SP astring *(SP astring) ")" 1112 ; parameters to SELECT may contain one or 1113 ; more atoms or strings - multiple items 1114 ; are always parenthesised 1116 sort-key =/ "ANNOTATION" SP entry SP attrib 1117 ; modifies original sort-key 1119 store-att-flags =/ att-annotate 1120 ; modifies original IMAP STORE command 1122 value = nstring 1124 5. IANA Considerations 1126 Both entry names and attribute names MUST be specified in a standards 1127 track or IESG approved experimental RFC, or fall under the vendor 1128 namespace. Vendor names MUST be registered. 1130 5.1 Entry and Attribute Registration Template 1132 To: iana@iana.org 1133 Subject: IMAP Annotate Registration 1135 Please register the following IMAP Annotate item: 1137 [] Entry [] Attribute 1139 Name: ______________________________ 1141 Description: _______________________ 1143 ____________________________________ 1145 ____________________________________ 1147 Contact person: ____________________ 1149 email: ____________________ 1151 5.2 Entry Registrations 1153 The following templates specify the IANA registrations of annotation 1154 entries specified in this document. 1156 5.2.1 /comment 1158 To: iana@iana.org 1159 Subject: IMAP Annotate Registration 1161 Please register the following IMAP Annotate item: 1163 [X] Entry [] Attribute 1165 Name: /comment 1167 Description: Defined in IMAP ANNOTATE extension document. 1169 Contact person: Cyrus Daboo 1171 email: daboo@isamet.com 1173 5.2.2 /flags/\\answered 1175 To: iana@iana.org 1176 Subject: IMAP Annotate Registration 1178 Please register the following IMAP Annotate item: 1180 [X] Entry [] Attribute 1182 Name: /flags/\answered 1184 Description: Defined in IMAP ANNOTATE extension document. 1186 Contact person: Cyrus Daboo 1188 email: daboo@isamet.com 1190 5.2.3 /flags/\\flagged 1192 To: iana@iana.org 1193 Subject: IMAP Annotate Registration 1195 Please register the following IMAP Annotate item: 1197 [X] Entry [] Attribute 1199 Name: /flags/\flagged 1201 Description: Defined in IMAP ANNOTATE extension document. 1203 Contact person: Cyrus Daboo 1205 email: daboo@isamet.com 1207 5.2.4 /flags/\\deleted 1209 To: iana@iana.org 1210 Subject: IMAP Annotate Registration 1212 Please register the following IMAP Annotate item: 1214 [X] Entry [] Attribute 1216 Name: /flags/\deleted 1218 Description: Defined in IMAP ANNOTATE extension document. 1220 Contact person: Cyrus Daboo 1222 email: daboo@isamet.com 1224 5.2.5 /flags/\\seen 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/\seen 1235 Description: Defined in IMAP ANNOTATE extension document. 1237 Contact person: Cyrus Daboo 1239 email: daboo@isamet.com 1241 5.2.6 /flags/\\draft 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/\draft 1252 Description: Defined in IMAP ANNOTATE extension document. 1254 Contact person: Cyrus Daboo 1256 email: daboo@isamet.com 1258 5.2.7 /flags/\\recent 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/\recent 1269 Description: Defined in IMAP ANNOTATE extension document. 1271 Contact person: Cyrus Daboo 1273 email: daboo@isamet.com 1275 5.2.8 /flags/$mdnsent 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/$mdnsent 1286 Description: Defined in IMAP ANNOTATE extension document. 1288 Contact person: Cyrus Daboo 1290 email: daboo@isamet.com 1292 5.2.9 /flags/$redirected 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/$redirected 1303 Description: Defined in IMAP ANNOTATE extension document. 1305 Contact person: Cyrus Daboo 1307 email: daboo@isamet.com 1309 5.2.10 /flags/$forwarded 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/$forwarded 1320 Description: Defined in IMAP ANNOTATE extension document. 1322 Contact person: Cyrus Daboo 1324 email: daboo@isamet.com 1326 5.2.11 /altsubject 1328 To: iana@iana.org 1329 Subject: IMAP Annotate Registration 1331 Please register the following IMAP Annotate item: 1333 [X] Entry [] Attribute 1335 Name: /altsubject 1337 Description: Defined in IMAP ANNOTATE extension document. 1339 Contact person: Cyrus Daboo 1341 email: daboo@isamet.com 1343 5.2.12 //comment 1345 To: iana@iana.org 1346 Subject: IMAP Annotate Registration 1348 Please register the following IMAP Annotate item: 1350 [X] Entry [] Attribute 1352 Name: //comment 1354 Description: Defined in IMAP ANNOTATE extension document. 1356 Contact person: Cyrus Daboo 1358 email: daboo@isamet.com 1360 5.2.13 //flags/seen 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/seen 1371 Description: Defined in IMAP ANNOTATE extension document. 1373 Contact person: Cyrus Daboo 1375 email: daboo@isamet.com 1377 5.2.14 //flags/answered 1379 To: iana@iana.org 1380 Subject: IMAP Annotate Registration 1382 Please register the following IMAP Annotate item: 1384 [X] Entry [] Attribute 1386 Name: //flags/answered 1388 Description: Defined in IMAP ANNOTATE extension document. 1390 Contact person: Cyrus Daboo 1392 email: daboo@isamet.com 1394 5.2.15 //flags/flagged 1396 To: iana@iana.org 1397 Subject: IMAP Annotate Registration 1399 Please register the following IMAP Annotate item: 1401 [X] Entry [] Attribute 1403 Name: //flags/flagged 1405 Description: Defined in IMAP ANNOTATE extension document. 1407 Contact person: Cyrus Daboo 1409 email: daboo@isamet.com 1411 5.2.16 //flags/forwarded 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/forwarded 1422 Description: Defined in IMAP ANNOTATE extension document. 1424 Contact person: Cyrus Daboo 1426 email: daboo@isamet.com 1428 5.3 Attribute Registrations 1430 The following templates specify the IANA registrations of annotation 1431 attributes specified in this document. 1433 5.3.1 value 1435 To: iana@iana.org 1436 Subject: IMAP Annotate Registration 1438 Please register the following IMAP Annotate item: 1440 [] Entry [X] Attribute 1442 Name: value 1444 Description: Defined in IMAP ANNOTATE extension document. 1446 Contact person: Cyrus Daboo 1448 email: daboo@isamet.com 1450 5.3.2 size 1452 To: iana@iana.org 1453 Subject: IMAP Annotate Registration 1455 Please register the following IMAP Annotate item: 1457 [] Entry [X] Attribute 1459 Name: size 1461 Description: Defined in IMAP ANNOTATE extension document. 1463 Contact person: Cyrus Daboo 1465 email: daboo@isamet.com 1467 5.3.3 content-type 1469 To: iana@iana.org 1470 Subject: IMAP Annotate Registration 1472 Please register the following IMAP Annotate item: 1474 [] Entry [X] Attribute 1476 Name: content-type 1478 Description: Defined in IMAP ANNOTATE extension document. 1480 Contact person: Cyrus Daboo 1482 email: daboo@isamet.com 1484 5.3.4 content-language 1486 To: iana@iana.org 1487 Subject: IMAP Annotate Registration 1489 Please register the following IMAP Annotate item: 1491 [] Entry [X] Attribute 1493 Name: content-language 1495 Description: Defined in IMAP ANNOTATE extension document. 1497 Contact person: Cyrus Daboo 1499 email: daboo@isamet.com 1501 6. Security Considerations 1503 Annotations whose values are intended to remain private MUST be 1504 stored in .priv values, and not .shared values which may be 1505 accessible to other users. 1507 Excluding the above issues the ANNOTATE extension does not raise any 1508 security considerations that are not present in the base IMAP 1509 protocol, and these issues are discussed in [RFC3501]. 1511 7. References 1513 7.1 Normative References 1515 [RFC1891] Moore, K., "SMTP Service Extension for Delivery Status 1516 Notifications", RFC 1891, January 1996. 1518 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1519 Extensions (MIME) Part Two: Media Types", RFC 2046, 1520 November 1996. 1522 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1525 Requirement Levels", BCP 14, RFC 2119, March 1997. 1527 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1528 Specifications: ABNF", RFC 2234, November 1997. 1530 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1531 Configuration Access Protocol", RFC 2244, November 1997. 1533 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 1534 2002. 1536 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1537 4rev1", RFC 3501, March 2003. 1539 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1540 MULTIAPPEND Extension", RFC 3502, March 2003. 1542 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1543 profile for Internet Message Access Protocol (IMAP)", RFC 1544 3503, March 2003. 1546 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 1547 Protocol - Sort and Thread Extension", 1548 draft-ietf-imapext-sort-17.txt, May 2004. 1550 7.2 Informative References 1552 [CONDSTORE] 1553 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1554 STORE operation", draft-ietf-imapext-condstore-05.txt, 1555 November 2003. 1557 Authors' Addresses 1559 Randall Gellens 1560 QUALCOMM Incorporated 1561 5775 Morehouse Dr. 1562 San Diego, CA 92121-2779 1563 US 1565 EMail: randy@qualcomm.com 1567 Cyrus Daboo 1568 ISAMET, Inc. 1569 5001 Baum Blvd. 1570 Suite 650 1571 Pittsburgh, PA 15213 1572 US 1574 EMail: daboo@isamet.com 1576 Appendix A. Acknowledgments 1578 Many thanks to Chris Newman for his detailed comments on the first 1579 draft of this document, and to the participants at the ACAP working 1580 dinner in Pittsburgh. 1582 Intellectual Property Statement 1584 The IETF takes no position regarding the validity or scope of any 1585 Intellectual Property Rights or other rights that might be claimed to 1586 pertain to the implementation or use of the technology described in 1587 this document or the extent to which any license under such rights 1588 might or might not be available; nor does it represent that it has 1589 made any independent effort to identify any such rights. Information 1590 on the procedures with respect to rights in RFC documents can be 1591 found in BCP 78 and BCP 79. 1593 Copies of IPR disclosures made to the IETF Secretariat and any 1594 assurances of licenses to be made available, or the result of an 1595 attempt made to obtain a general license or permission for the use of 1596 such proprietary rights by implementers or users of this 1597 specification can be obtained from the IETF on-line IPR repository at 1598 http://www.ietf.org/ipr. 1600 The IETF invites any interested party to bring to its attention any 1601 copyrights, patents or patent applications, or other proprietary 1602 rights that may cover technology that may be required to implement 1603 this standard. Please address the information to the IETF at 1604 ietf-ipr@ietf.org. 1606 Disclaimer of Validity 1608 This document and the information contained herein are provided on an 1609 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1610 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1611 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1612 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1613 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1616 Copyright Statement 1618 Copyright (C) The Internet Society (2004). This document is subject 1619 to the rights, licenses and restrictions contained in BCP 78, and 1620 except as set forth therein, the authors retain all their rights. 1622 Acknowledgment 1624 Funding for the RFC Editor function is currently provided by the 1625 Internet Society.