idnits 2.17.00 (12 Aug 2021) /tmp/idnits54042/draft-ietf-imapext-annotate-10.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1502. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1518), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 33) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 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], [IMAP4], [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 (July 18, 2004) is 6515 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: 'IMAP4' is mentioned on line 1411, but not defined == Missing Reference: 'ANNOTATE TOOBIG' is mentioned on line 73, but not defined == Missing Reference: 'ANNOTATE TOOMANY' is mentioned on line 73, but not defined == Missing Reference: 'ACAP' is mentioned on line 463, but not defined == Missing Reference: 'MDNSENT' is mentioned on line 369, but not defined == Missing Reference: 'MIME' is mentioned on line 448, but not defined == Missing Reference: 'ACL' is mentioned on line 469, but not defined == Missing Reference: 'MULTIAPPEND' is mentioned on line 959, but not defined == Missing Reference: 'ABNF' is mentioned on line 939, but not defined == Missing Reference: 'X' is mentioned on line 1391, but not defined == Unused Reference: 'RFC1891' is defined on line 1417, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'RFC2244' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC3501' is defined on line 1432, but no explicit reference was found in the text == Unused Reference: 'RFC3502' is defined on line 1435, but no explicit reference was found in the text == Unused Reference: 'RFC3503' is defined on line 1438, but no explicit reference was found in the text == Unused Reference: 'RFC2086' is defined on line 1453, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: draft-ietf-imapext-sort has been published as RFC 5256 == Outdated reference: draft-ietf-imapext-condstore has been published as RFC 4551 -- Obsolete informational reference (is this intentional?): RFC 2086 (Obsoleted by RFC 4314) Summary: 11 errors (**), 0 flaws (~~), 25 warnings (==), 9 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: January 16, 2005 C. Daboo 4 ISAMET, Inc. 5 July 18, 2004 7 IMAP ANNOTATE Extension 8 draft-ietf-imapext-annotate-10 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 16, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The ANNOTATE extension to the Internet Message Access Protocol 42 [IMAP4] permits clients and servers to maintain "metadata" for 43 messages stored in an IMAP4 mailbox. 45 Change History (to be removed prior to publication as an RFC) 47 Changes from -09 to -10: 49 1. Added Content-Language value. 50 2. Added IANA registrations for entries/attributes in this document. 52 Changes from -08 to -09: 53 1. Fix formatting, ID nits etc. 54 2. Fix subject -> altsubject in examples. 55 3. Added text to SELECT/EXAMINE optional parameter definition to 56 indicate that the option could trigger a global state change or a 57 mailbox specific change. 58 4. Changed entry/attribute names to be case-sensitive to avoid case 59 mapping issues with utf8 text. 60 5. Clarify COPY interaction to indicate that only the current user's 61 '.priv's are copied, not the '.priv's of other users. 63 Changes from -07 to -08: 64 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that 65 does not support any type of annotations, and "0" for a mailbox 66 that only supports read-only annotations. 68 Changes from -06 to -07: 69 1. Added text to state entry and attribute names are always 70 case-insensitive. 71 2. Removed top-level entry namespace. 72 3. Added server accept minima for annotation size and count. 73 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. 74 5. Added [ANNOTATESIZE <>] response code. 75 6. Added comment on suggested CONDSTORE support. 76 7. Modified append behaviour to account for MULTIAPPEND. 77 8. Tweaked ABNF. 79 Changes from -05 to -06: 80 1. Split references into Normative and Informative. 81 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation 82 name. 83 3. Removed smtp-envelope annotation - a future extension can add 84 this. 85 4. Changed subject to altsubject. 86 5. Added $MDNSent flag and reference to document. 87 6. Cleaned up formal syntax to use IMAP string type for entry and 88 attributes, with requirements on how the string is formatted. 89 7. Use of ACAP vendor subtree registry for vendor tokens. 90 8. Fixed STORE syntax. 92 Changes from -04 to -05: 93 1. Fixed examples to match formal syntax for FETCH responses where 94 parenthesis do not appear around entry-att items. 96 Changes from -03 to -04: 98 1. Fixed attrib/attrib-match grammar to use "." instead of "/". 99 2. Add text for server to reject unknown . 100 3. Do not allow empty part-specifier. 101 4. Store NIL to value to delete. 102 5. Comment on COPY interaction with ANNOTATE. 103 6. Added comment that IMAP flags are mapped one-to-one with their 104 corresponding FLAGS items. 105 7. Added comment that the recent flag annotation is read-only. 107 Changes from -02 to -03: 108 1. Removed reference to status modtime item. 109 2. Added missing 'notify' and 'ret' dsn annotations for /message/ 110 smtp-envelope. 111 3. Added requirement to store data permanently - no 'session only' 112 annotations. 113 4. Removed Access Control section. Replaced with comments on 114 read-only/read-write mailboxes and storing private or shared 115 annotations. 116 5. Removed STORE to default .priv or .shared. 117 6. Added section on optional select parameters. 119 Changes from -01 to -02: 120 1. Now require .priv or .shared on store operations. 122 Changes from -00 to -01: 123 1. MODTIME moved to its own draft, which this draft now depends on. 124 Thus, Conditional Annotation STORE and related items deleted from 125 this draft. 126 2. Private versus Shared Annotations: both are possible (separately 127 addressable using ".priv" and ".shared" suffixes). There is a 128 per-mailbox setting for the default. It is an open issue how 129 this is viewed or changed by the client. 130 3. In ACLs, the "w" right is needed to updated shared state; the "s" 131 right is needed to update private state. 132 4. Various clarifications and text modifications. 133 5. Added 'forwarded' flag for message parts. 135 Changes from pre-imapext to -00: 136 1. Clarified text describing attributions, entries, and attributes. 137 2. Changed 'modifiedsince' to 'modtime'; referenced ACAP spec. 138 3. Deleted 'queued' flag. 139 4. Expanded and explained smtp-envelope entry. 140 5. Restricted including ANNOTATION data in unsolicited responses 141 until the client uses it first. (Open issue as to if needed). 142 6. Examples now only use valid entries and attributes. 143 7. Updated Security Considerations. 144 8. Content-Type now defaults to text/plain. 146 9. Open Issue: Shared vs. private annotations. 147 10. Open issue: Annotation Modtime untagged response or VALIDTIME 148 FETCH data. 149 11. Open issue: Conditional annotation STORE. 150 12. ANNOTATION criterion available if both "ANNOTATE" and "SORT" in 151 CAPABILITY command response. 152 13. Prohibition on annotations in lieu of base spec functionality. 153 14. Specified required ACL rights. 154 15. ANNOTATION message data item in APPEND. 155 16. ANNOTATION-MODTIME message data item in STATUS. 156 17. Replaced ATOM_CHAR with utf8-char. 157 18. Updated other ABNF entries. 159 Table of Contents 161 1. Introduction and Overview . . . . . . . . . . . . . . . . . 6 162 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 7 163 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 164 2.2 Namespace of entries and attributes . . . . . . . . . . . 7 165 2.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 8 166 2.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 10 167 2.3 Private versus Shared and Access Control . . . . . . . . . 11 168 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 12 169 3.1 General Considerations . . . . . . . . . . . . . . . . . . 12 170 3.2 Optional parameters with the SELECT/EXAMINE commands . . . 12 171 3.3 ANNOTATION Message Data Item in FETCH Command . . . . . . 14 172 3.4 ANNOTATION Message Data Item in FETCH Response . . . . . . 16 173 3.5 ANNOTATION Message Data Item in STORE . . . . . . . . . . 17 174 3.6 ANNOTATION interaction with COPY . . . . . . . . . . . . . 19 175 3.7 ANNOTATION Message Data Item in APPEND . . . . . . . . . . 19 176 3.8 ANNOTATION Criterion in SEARCH . . . . . . . . . . . . . . 19 177 3.9 ANNOTATION Key in SORT . . . . . . . . . . . . . . . . . . 20 178 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 21 179 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 180 5.1 Entry and Attribute Registration Template . . . . . . . . 23 181 5.2 Entry Registrations . . . . . . . . . . . . . . . . . . . 23 182 5.2.1 /comment . . . . . . . . . . . . . . . . . . . . . . . 24 183 5.2.2 /flags/\answered . . . . . . . . . . . . . . . . . . 24 184 5.2.3 /flags/\flagged . . . . . . . . . . . . . . . . . . . 25 185 5.2.4 /flags/\deleted . . . . . . . . . . . . . . . . . . . 25 186 5.2.5 /flags/\seen . . . . . . . . . . . . . . . . . . . . 26 187 5.2.6 /flags/\draft . . . . . . . . . . . . . . . . . . . . 26 188 5.2.7 /flags/\recent . . . . . . . . . . . . . . . . . . . 27 189 5.2.8 /flags/$mdnsent . . . . . . . . . . . . . . . . . . . 27 190 5.2.9 /flags/$redirected . . . . . . . . . . . . . . . . . . 28 191 5.2.10 /flags/$forwarded . . . . . . . . . . . . . . . . . 28 192 5.2.11 /altsubject . . . . . . . . . . . . . . . . . . . . 29 193 5.2.12 //comment . . . . . . . . . . . . . . 29 194 5.2.13 //flags/seen . . . . . . . . . . . . . 30 195 5.2.14 //flags/answered . . . . . . . . . . . 30 196 5.2.15 //flags/flagged . . . . . . . . . . . 31 197 5.2.16 //flags/forwarded . . . . . . . . . . 31 198 5.3 Attribute Registrations . . . . . . . . . . . . . . . . . 31 199 5.3.1 value . . . . . . . . . . . . . . . . . . . . . . . . 32 200 5.3.2 size . . . . . . . . . . . . . . . . . . . . . . . . . 32 201 5.3.3 content-type . . . . . . . . . . . . . . . . . . . . . 33 202 5.3.4 content-language . . . . . . . . . . . . . . . . . . . 33 203 6. Security Considerations . . . . . . . . . . . . . . . . . . 33 204 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 205 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 34 206 7.2 Informative References . . . . . . . . . . . . . . . . . . . 34 207 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 208 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35 209 Intellectual Property and Copyright Statements . . . . . . . 36 211 1. Introduction and Overview 213 The ANNOTATE extension is present in any IMAP4 implementation which 214 returns "ANNOTATE" as one of the supported capabilities in the 215 CAPABILITY response. 217 The ANNOTATE extension adds a new message data item to the FETCH and 218 STORE commands, as well as adding SEARCH and SORT keys and an APPEND 219 modifier. 221 This extension makes the following changes to the IMAP4 protocol: 223 a. adds a new ANNOTATION message data item for use in FETCH 224 b. adds a new ANNOTATION message data item for use in STORE 225 c. adds a new ANNOTATION search criterion for use in SEARCH 226 d. adds a new ANNOTATION sort key for use in SORT extension 227 e. adds a new ANNOTATION data item for use in APPEND 228 f. adds a new requirement on the COPY command 229 g. adds a extension mechanism for adding parameters to the SELECT/ 230 EXAMINE commands and defines the ANNOTATE parameter 231 h. adds two new response codes to indicate store failures of 232 annotations. 233 i. adds a new untagged response codes for the SELECT or EXAMINE 234 commands to indicate the maximum size. 236 The data model used for the storage of annotations is based on that 237 of the Application Configuration Access Protocol [ACAP]. Note that 238 there is no inheritance in annotations. 240 Clients MUST NOT use annotations in lieu of equivalent IMAP base 241 specification facilities. For example, use of a "seen" flag in the 242 vendor namespace together with ".PEEK" in fetches. Such behaviour 243 would significantly reduce IMAP interoperability. 245 If a server supports annotations, then it MUST store all annotation 246 data permanently, i.e. there is no concept of 'session only' 247 annotations that would correspond to the behaviour of 'session' flags 248 as defined in the IMAP base specification. The exception to this is 249 IMAP flags (which are accessible directly through annotations) which 250 may be 'session only' as determined by the FLAGS and PERMANENTFLAGS 251 responses to a SELECT or EXAMINE command. 253 This extension also introduces a generalised mechanism for adding 254 parameters to the SELECT or EXAMINE commands. It is anticipated that 255 other extensions may want to utilise this, so it is not strictly 256 dependent on the ANNOTATE extension being present. 258 In order to provide optimum support for a disconnected client (one 259 that needs to synchronise annotations for use when offline), servers 260 SHOULD also support the Conditional STORE [CONDSTORE] extension. 262 The rest of this document describes the data model and protocol 263 changes more rigorously. 265 2. Data Model 267 2.1 Overview 269 The data model used in ANNOTATE is that of a uniquely named entry 270 which contains a set of standard attributes. A single coherent unit 271 of "metadata" for a message is stored as a single entry, made up of 272 several attributes. 274 For example, a comment added to a message has an entry name of "/ 275 comment". This entry is composed of several attributes such as 276 "value", "size", etc. which contain the properties and data of the 277 entry. 279 The protocol changes to IMAP described below allow a client to access 280 or change the values of any attributes in any entries in a message 281 annotation, assuming it has sufficient access rights to do so (see 282 Section 2.3 for specifics). 284 2.2 Namespace of entries and attributes 286 Each message annotation is made up of a set of entries. Each entry 287 has a hierarchical name in UTF-8, with each component of the name 288 separated by a slash ("/"). 290 Each entry is made up of a set of attributes. Each attribute has a 291 hierarchical name in UTF-8, with each component of the name separated 292 by a period ("."). 294 The value of an attribute is NIL (has no value), or is a string of 295 zero or more octets. 297 Entry and attribute names MUST NOT contain asterisk ("*") or percent 298 ("%") characters and MUST be valid UTF-8 strings which do not contain 299 the NULL octet. Invalid entry or attribute names result in a BAD 300 response in any IMAP commands where they are used. 302 Entry and attribute names are case-sensitive. 304 Use of non-visible UTF-8 characters in entry and attribute names is 305 strongly discouraged. 307 This specification defines an initial set of entry and attribute 308 names available for use in message annotations. In addition, an 309 extension mechanism is described to allow additional names to be 310 added for extensibility. 312 2.2.1 Entry Names 314 Entry names MUST be specified in a standards track or IESG approved 315 experimental RFC, or fall under the vendor namespace. See Section 316 5.1 for the registration template. 318 / 319 Defines the top-level of entries associated with an entire 320 message. This entry itself does not contain any attributes. All 321 entries that start with a numeric character ("0" - "9") refer to 322 an annotation on a specific body part. All other entries are for 323 annotations on the entire message. 325 /comment 326 Defines a comment or note associated with an entire message. 328 /flags 329 Defines the top-level of entries for flags associated with an 330 entire message. The "value" attribute of each of the entries 331 described below must be either "1", "0" or NIL. "1" corresponds 332 to the flag being set. 334 Standard [IMAP4] flags always have a '\' prefix character. Other 335 standard flags have a '$' prefix. The annotation names used for 336 all flags uses the complete name for that flag, including the 337 prefix character. 339 The set of standard IMAP flags annotations are: 341 /flags/\answered 342 /flags/\flagged 343 /flags/\deleted 344 /flags/\seen 345 /flags/\draft 346 /flags/\recent 348 Changes to these annotations are reflected in the standard IMAP 349 flags. The \recent attribute is read only, clients MUST NOT 350 attempt to change it. 352 Note that entry names are sent as [IMAP4] string elements which 353 requires that '\' characters be escaped if sent as a quoted string 354 as opposed to a literal. 356 Note that flag and keyword names in [IMAP4] are case-insensitive, 357 however the entry names for the corresponding annotations are 358 case-sensitive. Thus the [IMAP4] flag and keyword names MUST be 359 mapped to lowercase characters before being used as entry names 360 for annotations. 362 Additional standard flags are: 364 /flags/$mdnsent 365 /flags/$redirected 366 /flags/$forwarded 368 The '$mdnsent' flag is used to indicate message disposition 369 notification processing state [MDNSENT]. 371 The '$redirected' flag indicates that a message has been handed 372 off to someone else, by resending the message with minimal 373 alterations, and in such a way that a reply by the new 374 recipient is addressed to the original author, not the user who 375 performed the redirection. 377 The '$forwarded' flag indicates the message was resent to 378 another user, embedded within or attached to a new message. 380 /altsubject 381 Contains text supplied by the message recipient, to be used by the 382 client instead of the original message Subject. 384 /vendor/ 385 Defines the top-level of entries associated with an entire message 386 as created by a particular product of some vendor. These 387 sub-entries can be used by vendors to provide client-specific 388 attributes. The vendor-token MUST be registered with IANA, using 389 the [ACAP] vendor subtree registry. 391 / 392 Defines the top-level of entries associated with a specific body 393 part of a message. This entry itself does not contain any 394 attributes. The section-part uses the same numeric part specifier 395 syntax as the BODY message data item in the FETCH command [IMAP4]. 396 The server MUST return a BAD response if the client uses an 397 incorrect part specifier (either incorrect syntax or a specifier 398 referring to a non-existent part). The server MUST return a BAD 399 response if the client uses an empty part specifier (which is used 400 in [IMAP4] to represent the entire message). 402 //comment 403 Defines a comment or note associated with a specific body part of 404 a message. 406 //flags 407 Defines the top-level of entries associated with flag state for a 408 specific body part of a message. All sub-entries are maintained 409 entirely by the client. There is no implicit change to any flag 410 by the server. 412 //flags/seen 413 //flags/answered 414 //flags/flagged 415 //flags/forwarded 417 Defines flags for a specific body part of a message. The "value" 418 attribute of these entries must be either "1", "0" or NIL. 420 //vendor/ 421 Defines the top-level of entries associated with a specific body 422 part of a message as created by a particular product of some 423 vendor. This entry can be used by vendors to provide client 424 specific attributes. The vendor-token MUST be registered with 425 IANA. 427 2.2.2 Attribute Names 429 Attribute names MUST be specified in a standards track or IESG 430 approved experimental RFC, or fall under the vendor namespace. See 431 Section 5.1 for the registration template. 433 All attribute names implicitly have a ".priv" and a ".shared" suffix 434 which maps to private and shared versions of the entry. Searching or 435 fetching without using either suffix includes both. The client MUST 436 specify either a ".priv" or ".shared" suffix when storing an 437 annotation. 439 value 440 A UTF8 string representing the data value of the attribute. To 441 delete an annotation, the client can store NIL into the value. 443 size 444 The size of the value, in octets. Set automatically by the 445 server, read-only to clients. 447 content-type 448 A MIME [MIME] content type and subtype that describes the nature 449 of the content of the "value" attribute. If not present, a value 450 of "text/plain; charset=utf8" is assumed. 452 content-language 453 Indicates the language used for the value. This follows the 454 format described in [RFC3282]. Clients SHOULD set this value when 455 storing an annotation that uses text that can be presented to the 456 user. It is not required for enumerated or numeric values such as 457 flags etc. 459 vendor. 460 Defines an attribute associated with a particular product of some 461 vendor. This attribute can be used by vendors to provide client 462 specific attributes. The vendor-token MUST be registered with 463 IANA, using the [ACAP] vendor subtree registry. 465 2.3 Private versus Shared and Access Control 467 Some IMAP mailboxes are private, accessible only to the owning user. 468 Other mailboxes are not, either because the owner has set an ACL 469 [ACL] which permits access by other users, or because it is a shared 470 mailbox. 472 This raises the issue of shared versus private annotations. 474 If all annotations are private, it is impossible to set annotations 475 in a shared or otherwise non-private mailbox that are visible to 476 other users. This eliminates what could be a useful aspect of 477 annotations in a shared environment. An example of such use is a 478 shared IMAP folder containing bug reports. Engineers may want to use 479 annotations to add information to existing messages, indicate 480 assignments, status, etc. This use requires shared annotations. 482 If all annotations are shared, it is impossible to use annotations 483 for private notes on messages in shared mailboxes. Also, modifying 484 an ACL to permit access to a mailbox by other users may 485 unintentionally expose private information. 487 There are also situations in which both shared and private 488 annotations are useful. For example, an administrator may want to 489 set shared annotations on messages in a shared folder, which 490 individual users may wish to supplement with additional notes. 492 If shared and private annotations are to coexist, we need a clear way 493 to differentiate them. Also, it should be as easy as possible for a 494 client to access both and not overlook either. There is also a 495 danger in allowing a client to store an annotation without knowing if 496 it is shared or private. 498 This document proposes two standard suffixes for all attributes: 499 ".shared" and ".priv". A search, fetch, or sort which specifies 500 neither uses both. Store operations MUST explicitly use .priv or 501 .shared suffixes. 503 A user can only store and fetch private annotations on messages in 504 any mailbox which they can SELECT or EXAMINE, including ones which 505 only open READ-ONLY. A user can only store and fetch shared 506 annotations on messages in any mailbox that they can SELECT and which 507 opens READ-WRITE. If a client attempts to store or fetch a shared 508 annotation on a READ-ONLY mailbox, the server MUST respond with a NO 509 response. 511 3. IMAP Protocol Changes 513 3.1 General Considerations 515 The server is allowed to impose limitations on the size of any one 516 annotation or the total number of annotations for a single message. 517 However, the server MUST accept a minimum annotation data size of at 518 least 1024 bytes, and a minimum annotation count per message of at 519 least 10. 521 The server SHOULD indicate the maximum size for an annotation value 522 by sending an untagged "ANNOTATESIZE" response during a SELECT or 523 EXAMINE command. Clients MUST NOT store annotation values of a size 524 greater than the amount indicated by the server in the "ANNOTATESIZE" 525 response. 527 In some cases, servers may be able to offer annotations on some 528 mailboxes and not others, or may be able to provide only read-only 529 annotations on some mailboxes. For mailboxes that cannot have 530 annotations associated with them, the server MUST return an 531 "ANNOTATESIZE" response with a value of "NIL" during the SELECT or 532 EXAMINE command for that mailbox. Clients MUST NOT attempt to fetch 533 or store annotations on any messages in a mailbox for which the 534 "ANNOTATESIZE" response was "NIL". For mailboxes that can only have 535 read-only annotations associated with them, the server MUST return an 536 "ANNOTATESIZE" response with a value of "0" (zero) during the SELECT 537 or EXAMINE command for that mailbox. Clients MUST NOT attempt to 538 store annotations on any messages in a mailbox for which the 539 "ANNOTATESIZE" response was zero. 541 3.2 Optional parameters with the SELECT/EXAMINE commands 543 This extension adds the ability to include one or more parameters 544 with the IMAP SELECT or EXAMINE commands, to turn on or off certain 545 standard behaviour, or to add new optional behaviours required for a 546 particular extension. 548 There are two possible modes of operation: 550 o A global state change where a single use of the optional parameter 551 will effect the session state from that time on, irrespective of 552 subsequent SELECT/EXAMINE commands. 554 o A per-mailbox state change that will effect the session only for 555 the duration of the new selected state. A subsequent SELECT/ 556 EXAMINE without the optional parameter will cancel its effect for 557 the newly selected mailbox. 559 It is anticipated that other extensions may want to use this 560 facility, so a generalised approach is given here. This facility is 561 not dependent on the presence of the ANNOTATE extension - other 562 extensions can use it with a server that does not implement ANNOTATE. 564 Optional parameters to the SELECT or EXAMINE commands are added as a 565 parenthesised list of atoms or strings, and appear after the mailbox 566 name in the standard SELECT or EXAMINE command. The order of 567 individual parameters is arbitrary. Individual parameters may 568 consist of one or more atoms or strings in a specific order. If a 569 parameter consists of more than one atom or string, it MUST appear in 570 its own parenthesised list. Any parameter not defined by extensions 571 that the server supports MUST be rejected with a NO response. 573 Example: 575 C: a SELECT INBOX (ANNOTATE) 576 S: ... 577 S: a OK SELECT complete 579 In the above example, a single parameter is used with the SELECT 580 command. 582 Example: 584 C: a EXAMINE INBOX (ANNOTATE (RESPONSES "UID Responses") CONDSTORE) 585 S: ... 586 S: a OK EXAMINE complete 588 In the above example, three parameters are used with the EXAMINE 589 command. The second parameter consists of two items: an atom 590 followed by a quoted string. 592 Example: 594 C: a SELECT INBOX (BLURDYBLOOP) 595 S: a NO Unknown parameter in SELECT command 597 In the above example, a parameter not supported by the server is 598 incorrectly used. 600 The ANNOTATE extension defines a single optional select parameter 601 "ANNOTATE", which is used to turn on unsolicited responses for 602 annotations as described in Section 3.4. This option al parameter is 603 results in a per-mailbox state change, i.e. it must be used in each 604 SELECT/EXAMINE command in order to be effective, irrespective of 605 whether it was used in a previous SELECT/EXAMINE during the same 606 session. 608 3.3 ANNOTATION Message Data Item in FETCH Command 610 This extension adds an ANNOTATION message data item to the FETCH 611 command. This allows clients to retrieve annotations for a range of 612 messages in the currently selected mailbox. 614 ANNOTATION 616 The ANNOTATION message data item, when used by the client in the 617 FETCH command, takes an entry specifier and an attribute 618 specifier. 620 Example: 622 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 623 S: * 1 FETCH (ANNOTATION ("/comment" 624 ("value.priv" "My comment" 625 "value.shared" "Group note"))) 626 S: a OK Fetch complete 628 In the above example, the content of the "value" attribute for the 629 "/comment" entry is requested by the client and returned by the 630 server. Since neither ".shared" nor ".priv" was specified, both 631 are returned. 633 "*" and "%" wildcard characters can be used in either specifier to 634 match one or more characters at that position, with the exception 635 that "%" does not match the hierarchy delimiter for the specifier it 636 appears in (that is, "/" for an entry specifier or "." for an 637 attribute specifier). Thus an entry specifier of "/%" matches 638 entries such as "/comment" and "/altsubject", but not "/flags/ 639 $redirected". 641 Example: 643 C: a FETCH 1 (ANNOTATION ("/*" ("value.priv" "size.priv"))) 644 S: * 1 FETCH (ANNOTATION 645 ("/comment" ("value.priv" "My comment" 646 "size.priv" "10") 647 "/altsubject" ("value.priv" "Rhinoceroses!" 648 "size.priv" "13") 649 "/vendor/foobar/label.priv" 650 ("value.priv" "label43" 651 "size.priv" "7") 652 "/vendor/foobar/personality" 653 ("value.priv" "Tallulah Bankhead" 654 "size.priv" "17"))) 655 S: a OK Fetch complete 657 In the above example, the contents of the private "value" and 658 "size" attributes for any entries in the "" hierarchy are 659 requested by the client and returned by the server. 661 Example: 663 C: a FETCH 1 (ANNOTATION ("/%" "value.shared")) 664 S: * 1 FETCH (ANNOTATION 665 ("/comment" ("value.shared" "Patch Mangler") 666 "/altsubject" ("value.shared" "Patches? We don't 667 need no steenkin patches!"))) 668 S: a OK Fetch complete 670 In the above example, the contents of the shared "value" 671 attributes for entries at the top level only of the "" hierarchy 672 are requested by the client and returned by the server. 674 Entry and attribute specifiers can be lists of atomic specifiers, so 675 that multiple items of each type may be returned in a single FETCH 676 command. 678 Example: 680 C: a FETCH 1 (ANNOTATION 681 (("/comment" "/altsubject") "value.priv")) 682 S: * 1 FETCH (ANNOTATION 683 ("/comment" ("value.priv" "What a chowder-head") 684 "/altsubject" ("value.priv" "How to crush beer cans"))) 685 S: a OK Fetch complete 687 In the above example, the contents of the private "value" 688 attributes for the two entries "/comment" and "/altsubject" are 689 requested by the client and returned by the server. 691 3.4 ANNOTATION Message Data Item in FETCH Response 693 The ANNOTATION message data item in the FETCH response displays 694 information about annotations in a message. 696 ANNOTATION parenthesised list 698 The response consists of a list of entries, each of which has a 699 list of attribute-value pairs. 701 Example: 703 C: a FETCH 1 (ANNOTATION ("/comment" "value")) 704 S: * 1 FETCH (ANNOTATION ("/comment" 705 ("value.priv" "My comment" 706 "value.shared" NIL))) 707 S: a OK Fetch complete 709 In the above example, a single entry with a single attribute-value 710 pair is returned by the server. Since the client did not specify 711 a ".shared" or ".priv" suffix, both are returned. Only the 712 private attribute has a value (the shared value is NIL). 714 Example: 716 C: a FETCH 1 (ANNOTATION 717 (("/comment" "/altsubject") "value")) 718 S: * 1 FETCH (ANNOTATION 719 ("/comment" ("value.priv" "My comment" 720 "value.shared" NIL) 721 "/altsubject" ("value.priv" "My subject" 722 "value.shared" NIL))) 723 S: a OK Fetch complete 725 In the above example, two entries each with a single 726 attribute-value pair are returned by the server. Since the client 727 did not specify a ".shared" or ".priv" suffix, both are returned. 728 Only the private attributes have values; the shared attributes are 729 NIL. 731 Example: 733 C: a FETCH 1 (ANNOTATION 734 ("/comment" ("value" "size"))) 735 S: * 1 FETCH (ANNOTATION 736 ("/comment" 737 ("value.priv" "My comment" 738 "value.shared" NIL 739 "size.priv" "10" 740 "size.shared" "0"))) 741 S: a OK Fetch complete 743 In the above example, a single entry with two attribute-value 744 pairs is returned by the server. Since the client did not specify 745 a ".shared" or ".priv" suffix, both are returned. Only the 746 private attributes have values; the shared attributes are NIL. 748 Servers MUST NOT include ANNOTATION data in unsolicited responses 749 unless the client used the ANNOTATE select parameter when it issued 750 the last SELECT or EXAMINE command. This restriction avoids sending 751 ANNOTATION data to a client unless the client explicitly asks for it. 753 Servers SHOULD send ANNOTATION message data items in unsolicited 754 FETCH responses if an annotation entry is changed by a third-party, 755 and the ANNOTATE select parameter was used. This allows servers to 756 keep clients updated with changes to annotations by other clients. 758 3.5 ANNOTATION Message Data Item in STORE 760 ANNOTATION 762 Sets the specified list of entries by adding or replacing the 763 specified attributes with the values provided. Clients can use 764 NIL for values of attributes it wants to remove from entries. 766 The ANNOTATION message data item used with the STORE command has an 767 implicit ".SILENT" behaviour. This means the server does not 768 generate an untagged FETCH in response to the STORE command and 769 assumes that the client updates its own cache if the command 770 succeeds. 772 If the server is unable to store an annotation because the size of 773 its value is too large, the server MUST return a tagged NO response 774 with a "[ANNOTATE TOOBIG]" response code. 776 If the server is unable to store a new annotation because the maximum 777 number of allowed annotations has already been reached, the server 778 MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response 779 code. 781 Example: 783 C: a STORE 1 ANNOTATION ("/comment" 784 ("value.priv" "My new comment")) 785 S: a OK Store complete 787 In the above example, the entry "/comment" is created (if not 788 already present) and the private attribute "value" with data set 789 to "My new comment" is created if not already present, or replaced 790 if it exists. 792 Example: 794 C: a STORE 1 ANNOTATION ("/comment" 795 ("value.shared" NIL)) 796 S: a OK Store complete 798 In the above example, the shared "value" attribute of the entry "/ 799 comment" is removed by storing NIL into the attribute. 801 Multiple entries can be set in a single STORE command by listing 802 entry-attribute-value pairs in the list. 804 Example: 806 C: a STORE 1 ANNOTATION ("/comment" 807 ("value.priv" "Get tix Tuesday") 808 "/altsubject" 809 ("value.priv" "Wots On")) 810 S: a OK Store complete 812 In the above example, the entries "/comment" and "/altsubject" are 813 created (if not already present) and the private attribute "value" 814 is created for each entry if not already present, or replaced if 815 they exist. 817 Multiple attributes can be set in a single STORE command by listing 818 multiple attribute-value pairs in the entry list. 820 Example: 822 C: a STORE 1 ANNOTATION ("/comment" 823 ("value.priv" "My new comment" 824 "vendor.foobar.priv" "foo's bar")) 825 S: a OK Store complete 827 In the above example, the entry "/comment" is created (if not already 828 present) and the private attributes "value" and "vendor.foobar" are 829 created if not already present, or replaced if they exist. 831 3.6 ANNOTATION interaction with COPY 833 The COPY command can be used to move messages from one mailbox to 834 another on the same server. Servers that support the ANNOTATION 835 extension MUST, for each message being copied, copy all '.priv' 836 annotation data for the current user only, and all '.shared' 837 annotation data along with the message to the new mailbox. The only 838 exceptions to this are if the destination mailbox permissions are 839 such that either the '.priv' or '.shared' annotations are not 840 allowed, or if the destination mailbox is of a type that does not 841 support annotations or does not support storing of annotations (a 842 mailbox that returns a zero or "NIL" value for its ANNOTATESIZE 843 response code). Servers MUST NOT copy '.priv' annotation data for 844 users other than the current user. 846 3.7 ANNOTATION Message Data Item in APPEND 848 ANNOTATION 850 Sets the specified list of entries and attributes in the resulting 851 message. 853 The APPEND command can include annotations for the message being 854 appended via the addition of a new append data item. The new data 855 item can also be used with the multi-append [MULTIAPPEND] extension 856 that allows multiple messages to be appended via a single APPEND 857 command. 859 Example: 861 C: a APPEND drafts ANNOTATION ("/comment" 862 ("value.priv" "Don't send until we hear from Sally")) {310} 863 S: + Ready for literal data 864 C: MIME-Version: 1.0 865 ... 866 C: 867 S: a OK APPEND completed 869 In the above example, a comment with a private value is added to a 870 new message appended to the mailbox. The ellipsis represents the 871 bulk of the message. 873 3.8 ANNOTATION Criterion in SEARCH 875 ANNOTATION 876 The ANNOTATION criterion for the SEARCH command allows a client to 877 search for a specified string in the value of an annotation entry of 878 a message. 880 Messages that have annotations with entries matching and 881 attributes matching and the specified string 882 in their values are returned in the SEARCH results. The "*" 883 character can be used in the entry or attribute name fields to match 884 any content in those items. The "%" character can be used in the 885 entry or attribute name fields to match a single level of hierarchy 886 only. 888 Example: 890 C: a SEARCH ANNOTATION "/comment" "value" "IMAP4" 891 S: * SEARCH 2 3 5 7 11 13 17 19 23 892 S: a OK Search complete 894 In the above example, the message numbers of any messages 895 containing the string "IMAP4" in the shared or private "value" 896 attribute of the "/comment" entry are returned in the search 897 results. 899 Example: 901 C: a SEARCH ANNOTATION "*" "*" "IMAP4" 902 S: * SEARCH 1 2 3 5 8 13 21 34 903 S: a OK Search complete 905 In the above example, the message numbers of any messages 906 containing the string "IMAP4" in any attribute (public or private) 907 of any entry are returned in the search results. 909 3.9 ANNOTATION Key in SORT 911 ANNOTATION 913 The ANNOTATION criterion for the SORT command [SORT] instructs the 914 server to return the message numbers or UIDs of a mailbox, sorted 915 using the values of the specified annotations. The ANNOTATION 916 criterion is available if the server returns both "ANNOTATE" and 917 "SORT" as supported capabilities in the CAPABILITY command response. 919 Messages are sorted using the values of the 920 attributes in the entries. (The charset argument 921 determines sort order, as specified in the SORT extension 922 description.) 923 Example: 925 C: a SORT (ANNOTATION "/altsubject" "value.shared") UTF-8 ALL 926 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 927 S: a OK Sort complete 929 In the above example, the message numbers of all messages are 930 returned, sorted according to the shared "value" attribute of the 931 "/altsubject" entry. 933 Note that the ANNOTATION sort key must include a fully specified 934 entry and attribute -- wildcards are not allowed. 936 4. Formal Syntax 938 The following syntax specification uses the Augmented Backus-Naur 939 Form (ABNF) notation as specified in [ABNF]. 941 Non-terminals referenced but not defined below are as defined by 942 [IMAP4]. 944 Except as noted otherwise, all alphabetic characters are 945 case-insensitive. The use of upper or lower case characters to 946 define token strings is for editorial clarity only. Implementations 947 MUST accept these strings in a case-insensitive fashion. 949 annotate-param = "ANNOTATE" 950 ; defines the select parameter used with 951 ; ANNOTATE extension 953 append = "APPEND" SP mailbox [SP flag-list] [SP date-time] 954 [SP "ANNOTATION" SP att-annotate] SP literal 955 ; modifies original IMAP4 APPEND command 957 append-message = [SP flag-list] [SP date-time] 958 [SP "ANNOTATION" SP att-annotate] SP literal 959 ; modifies [MULTIAPPEND] extension behaviour 961 att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 963 att-match = string 964 ; dot-separated attribute name 965 ; MAY contain "*" or "%" for use as wildcards 967 att-value = attrib SP value 969 attrib = string 970 ; dot-separated attribute name 971 ; MUST NOT contain "*" or "%" 973 attribs = att-match / 974 "(" att-match *(SP att-match) ")" 976 entries = entry-match / 977 "(" entry-match *(SP entry-match) ")" 979 entry = string 980 ; slash-separated path to entry 981 ; MUST NOT contain "*" or "%" 983 entry-att = entry SP "(" att-value *(SP att-value) ")" 985 entry-match = string 986 ; slash-separated path to entry 987 ; MAY contain "*" or "%" for use as wildcards 989 examine =/ *(SP "(" select-param *(SP select-param) ")" 990 ; modifies the original IMAP4 examine command to 991 ; accept optional parameters 993 fetch-ann-resp = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 995 fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")" 996 ; modifies original IMAP4 fetch-att 998 resp-text-code =/ "ANNOTATE" SP "TOOBIG" / 999 "ANNOTATE" SP "TOOMANY" / 1000 "ANNOTATESIZE" SP (number / "NIL") 1001 ; new response codes 1003 search-key =/ "ANNOTATION" SP entry-match SP att-match 1004 SP value 1005 ; modifies original IMAP4 search-key 1007 select =/ *(SP "(" select-param *(SP select-param) ")" 1008 ; modifies the original IMAP4 select command to 1009 ; accept optional parameters 1011 select-param = astring / "(" astring SP astring *(SP astring) ")" 1012 ; parameters to SELECT may contain one or 1013 ; more atoms or strings - multiple items 1014 ; are always parenthesised 1016 sort-key =/ "ANNOTATION" SP entry SP attrib 1017 ; modifies original sort-key [SORT] 1019 store-att-flags =/ att-annotate 1020 ; modifies original IMAP4 STORE command 1022 value = nstring 1024 5. IANA Considerations 1026 Both entry names and attribute names MUST be specified in a standards 1027 track or IESG approved experimental RFC, or fall under the vendor 1028 namespace. Vendor names MUST be registered. 1030 5.1 Entry and Attribute Registration Template 1032 To: iana@iana.org 1033 Subject: IMAP Annotate Registration 1035 Please register the following IMAP Annotate item: 1037 [] Entry [] Attribute 1039 Name: ______________________________ 1041 Description: _______________________ 1043 ____________________________________ 1045 ____________________________________ 1047 Contact person: ____________________ 1049 email: ____________________ 1051 5.2 Entry Registrations 1053 The following templates specify the IANA registrations of annotation 1054 entries specified in this document. 1056 5.2.1 /comment 1058 To: iana@iana.org 1059 Subject: IMAP Annotate Registration 1061 Please register the following IMAP Annotate item: 1063 [X] Entry [] Attribute 1065 Name: /comment 1067 Description: Defined in IMAP ANNOTATE extension document. 1069 Contact person: Cyrus Daboo 1071 email: daboo@isamet.com 1073 5.2.2 /flags/\answered 1075 To: iana@iana.org 1076 Subject: IMAP Annotate Registration 1078 Please register the following IMAP Annotate item: 1080 [X] Entry [] Attribute 1082 Name: /flags/\answered 1084 Description: Defined in IMAP ANNOTATE extension document. 1086 Contact person: Cyrus Daboo 1088 email: daboo@isamet.com 1090 5.2.3 /flags/\flagged 1092 To: iana@iana.org 1093 Subject: IMAP Annotate Registration 1095 Please register the following IMAP Annotate item: 1097 [X] Entry [] Attribute 1099 Name: /flags/\flagged 1101 Description: Defined in IMAP ANNOTATE extension document. 1103 Contact person: Cyrus Daboo 1105 email: daboo@isamet.com 1107 5.2.4 /flags/\deleted 1109 To: iana@iana.org 1110 Subject: IMAP Annotate Registration 1112 Please register the following IMAP Annotate item: 1114 [X] Entry [] Attribute 1116 Name: /flags/\deleted 1118 Description: Defined in IMAP ANNOTATE extension document. 1120 Contact person: Cyrus Daboo 1122 email: daboo@isamet.com 1124 5.2.5 /flags/\seen 1126 To: iana@iana.org 1127 Subject: IMAP Annotate Registration 1129 Please register the following IMAP Annotate item: 1131 [X] Entry [] Attribute 1133 Name: /flags/\seen 1135 Description: Defined in IMAP ANNOTATE extension document. 1137 Contact person: Cyrus Daboo 1139 email: daboo@isamet.com 1141 5.2.6 /flags/\draft 1143 To: iana@iana.org 1144 Subject: IMAP Annotate Registration 1146 Please register the following IMAP Annotate item: 1148 [X] Entry [] Attribute 1150 Name: /flags/\draft 1152 Description: Defined in IMAP ANNOTATE extension document. 1154 Contact person: Cyrus Daboo 1156 email: daboo@isamet.com 1158 5.2.7 /flags/\recent 1160 To: iana@iana.org 1161 Subject: IMAP Annotate Registration 1163 Please register the following IMAP Annotate item: 1165 [X] Entry [] Attribute 1167 Name: /flags/\recent 1169 Description: Defined in IMAP ANNOTATE extension document. 1171 Contact person: Cyrus Daboo 1173 email: daboo@isamet.com 1175 5.2.8 /flags/$mdnsent 1177 To: iana@iana.org 1178 Subject: IMAP Annotate Registration 1180 Please register the following IMAP Annotate item: 1182 [X] Entry [] Attribute 1184 Name: /flags/$mdnsent 1186 Description: Defined in IMAP ANNOTATE extension document. 1188 Contact person: Cyrus Daboo 1190 email: daboo@isamet.com 1192 5.2.9 /flags/$redirected 1194 To: iana@iana.org 1195 Subject: IMAP Annotate Registration 1197 Please register the following IMAP Annotate item: 1199 [X] Entry [] Attribute 1201 Name: /flags/$redirected 1203 Description: Defined in IMAP ANNOTATE extension document. 1205 Contact person: Cyrus Daboo 1207 email: daboo@isamet.com 1209 5.2.10 /flags/$forwarded 1211 To: iana@iana.org 1212 Subject: IMAP Annotate Registration 1214 Please register the following IMAP Annotate item: 1216 [X] Entry [] Attribute 1218 Name: /flags/$forwarded 1220 Description: Defined in IMAP ANNOTATE extension document. 1222 Contact person: Cyrus Daboo 1224 email: daboo@isamet.com 1226 5.2.11 /altsubject 1228 To: iana@iana.org 1229 Subject: IMAP Annotate Registration 1231 Please register the following IMAP Annotate item: 1233 [X] Entry [] Attribute 1235 Name: /altsubject 1237 Description: Defined in IMAP ANNOTATE extension document. 1239 Contact person: Cyrus Daboo 1241 email: daboo@isamet.com 1243 5.2.12 //comment 1245 To: iana@iana.org 1246 Subject: IMAP Annotate Registration 1248 Please register the following IMAP Annotate item: 1250 [X] Entry [] Attribute 1252 Name: //comment 1254 Description: Defined in IMAP ANNOTATE extension document. 1256 Contact person: Cyrus Daboo 1258 email: daboo@isamet.com 1260 5.2.13 //flags/seen 1262 To: iana@iana.org 1263 Subject: IMAP Annotate Registration 1265 Please register the following IMAP Annotate item: 1267 [X] Entry [] Attribute 1269 Name: //flags/seen 1271 Description: Defined in IMAP ANNOTATE extension document. 1273 Contact person: Cyrus Daboo 1275 email: daboo@isamet.com 1277 5.2.14 //flags/answered 1279 To: iana@iana.org 1280 Subject: IMAP Annotate Registration 1282 Please register the following IMAP Annotate item: 1284 [X] Entry [] Attribute 1286 Name: //flags/answered 1288 Description: Defined in IMAP ANNOTATE extension document. 1290 Contact person: Cyrus Daboo 1292 email: daboo@isamet.com 1294 5.2.15 //flags/flagged 1296 To: iana@iana.org 1297 Subject: IMAP Annotate Registration 1299 Please register the following IMAP Annotate item: 1301 [X] Entry [] Attribute 1303 Name: //flags/flagged 1305 Description: Defined in IMAP ANNOTATE extension document. 1307 Contact person: Cyrus Daboo 1309 email: daboo@isamet.com 1311 5.2.16 //flags/forwarded 1313 To: iana@iana.org 1314 Subject: IMAP Annotate Registration 1316 Please register the following IMAP Annotate item: 1318 [X] Entry [] Attribute 1320 Name: //flags/forwarded 1322 Description: Defined in IMAP ANNOTATE extension document. 1324 Contact person: Cyrus Daboo 1326 email: daboo@isamet.com 1328 5.3 Attribute Registrations 1330 The following templates specify the IANA registrations of annotation 1331 attributes specified in this document. 1333 5.3.1 value 1335 To: iana@iana.org 1336 Subject: IMAP Annotate Registration 1338 Please register the following IMAP Annotate item: 1340 [] Entry [X] Attribute 1342 Name: value 1344 Description: Defined in IMAP ANNOTATE extension document. 1346 Contact person: Cyrus Daboo 1348 email: daboo@isamet.com 1350 5.3.2 size 1352 To: iana@iana.org 1353 Subject: IMAP Annotate Registration 1355 Please register the following IMAP Annotate item: 1357 [] Entry [X] Attribute 1359 Name: size 1361 Description: Defined in IMAP ANNOTATE extension document. 1363 Contact person: Cyrus Daboo 1365 email: daboo@isamet.com 1367 5.3.3 content-type 1369 To: iana@iana.org 1370 Subject: IMAP Annotate Registration 1372 Please register the following IMAP Annotate item: 1374 [] Entry [X] Attribute 1376 Name: content-type 1378 Description: Defined in IMAP ANNOTATE extension document. 1380 Contact person: Cyrus Daboo 1382 email: daboo@isamet.com 1384 5.3.4 content-language 1386 To: iana@iana.org 1387 Subject: IMAP Annotate Registration 1389 Please register the following IMAP Annotate item: 1391 [] Entry [X] Attribute 1393 Name: content-language 1395 Description: Defined in IMAP ANNOTATE extension document. 1397 Contact person: Cyrus Daboo 1399 email: daboo@isamet.com 1401 6. Security Considerations 1403 Care must be taken to ensure that annotations whose values are 1404 intended to remain private are not stored in mailboxes which are 1405 accessible to other users. This includes mailboxes owned by the user 1406 by whose ACLs permit access by others as well as any shared 1407 mailboxes. 1409 Excluding the above issues the ANNOTATE extension does not raise any 1410 security considerations that are not present in the base [IMAP4] 1411 protocol, and these issues are discussed in [IMAP4]. 1413 7. References 1415 7.1 Normative References 1417 [RFC1891] Moore, K., "SMTP Service Extension for Delivery Status 1418 Notifications", RFC 1891, January 1996. 1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1421 Requirement Levels", BCP 14, RFC 2119, March 1997. 1423 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1424 Specifications: ABNF", RFC 2234, November 1997. 1426 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1427 Configuration Access Protocol", RFC 2244, November 1997. 1429 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 1430 2002. 1432 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1433 4rev1", RFC 3501, March 2003. 1435 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 1436 MULTIAPPEND Extension", RFC 3502, March 2003. 1438 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 1439 profile for Internet Message Access Protocol (IMAP)", RFC 1440 3503, March 2003. 1442 [SORT] Crispin, M. and K. Murchison, "Internet Message Access 1443 Protocol - Sort and Thread Extension", 1444 draft-ietf-imapext-sort-17.txt, May 2004. 1446 7.2 Informative References 1448 [CONDSTORE] 1449 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1450 STORE operation", draft-ietf-imapext-condstore-05.txt, 1451 November 2003. 1453 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 1455 Authors' Addresses 1457 Randall Gellens 1458 QUALCOMM Incorporated 1459 5775 Morehouse Dr. 1460 San Diego, CA 92121-2779 1461 US 1463 EMail: randy@qualcomm.com 1465 Cyrus Daboo 1466 ISAMET, Inc. 1467 5001 Baum Blvd. 1468 Suite 650 1469 Pittsburgh, PA 15213 1470 US 1472 EMail: daboo@isamet.com 1474 Appendix A. Acknowledgments 1476 Many thanks to Chris Newman for his detailed comments on the first 1477 draft of this document, and to the participants at the ACAP working 1478 dinner in Pittsburgh. 1480 Intellectual Property Statement 1482 The IETF takes no position regarding the validity or scope of any 1483 Intellectual Property Rights or other rights that might be claimed to 1484 pertain to the implementation or use of the technology described in 1485 this document or the extent to which any license under such rights 1486 might or might not be available; nor does it represent that it has 1487 made any independent effort to identify any such rights. Information 1488 on the procedures with respect to rights in RFC documents can be 1489 found in BCP 78 and BCP 79. 1491 Copies of IPR disclosures made to the IETF Secretariat and any 1492 assurances of licenses to be made available, or the result of an 1493 attempt made to obtain a general license or permission for the use of 1494 such proprietary rights by implementers or users of this 1495 specification can be obtained from the IETF on-line IPR repository at 1496 http://www.ietf.org/ipr. 1498 The IETF invites any interested party to bring to its attention any 1499 copyrights, patents or patent applications, or other proprietary 1500 rights that may cover technology that may be required to implement 1501 this standard. Please address the information to the IETF at 1502 ietf-ipr@ietf.org. 1504 Disclaimer of Validity 1506 This document and the information contained herein are provided on an 1507 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1508 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1509 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1510 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1511 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1514 Copyright Statement 1516 Copyright (C) The Internet Society (2004). This document is subject 1517 to the rights, licenses and restrictions contained in BCP 78, and 1518 except as set forth therein, the authors retain all their rights. 1520 Acknowledgment 1522 Funding for the RFC Editor function is currently provided by the 1523 Internet Society.