idnits 2.17.1 draft-daboo-imap-annotatemore-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([IMAP4]), 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 (November 2002) is 7823 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) == Outdated reference: A later version (-16) exists of draft-ietf-imapext-annotate-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-imapext-annotate (ref. 'ANNOTATE') ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2192 (ref. 'IMAPURL') (Obsoleted by RFC 5092) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-10 -- Possible downref: Normative reference to a draft: ref. 'THREAD' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Daboo 2 Internet Draft: IMAP ANNOTATEMORE Extension 3 Document: draft-daboo-imap-annotatemore-01.txt November 2002 5 IMAP ANNOTATEMORE Extension 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 22 Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Copyright Notice 27 Copyright (C) The Internet Society 2002. All Rights Reserved. 29 Table of Contents 30 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 31 2 Conventions Used in This Document . . . . . . . . . . . . . 2 32 3 Open Issues: . . . . . . . . . . . . . . . . . . . . . . . . 2 33 4 Change History . . . . . . . . . . . . . . . . . . . . . . . 3 34 5 Introduction and Overview . . . . . . . . . . . . . . . . . . 3 35 6 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 36 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 37 6.2 Namespace of entries and attributes . . . . . . . . . . 4 38 6.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 4 39 6.2.1.1 Server Entries . . . . . . . . . . . . . . . . . 5 40 6.2.1.2 Mailbox Entries . . . . . . . . . . . . . . . . . 5 41 6.2.2 Attribute Names . . . . . . . . . . . . . . . . . . 6 42 7 Private versus Shared and Access Control . . . . . . . . . . 7 43 8 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . 7 44 8.1 GETANNOTATION Command . . . . . . . . . . . . . . . . . . 7 45 8.2 SETANNOTATION command . . . . . . . . . . . . . . . . . 9 46 8.3 ANNOTATION Response . . . . . . . . . . . . . . . . . . . 10 47 8.3.1 ANNOTATION response with attributes and values . . . 10 48 8.3.2 Unsolicited ANNOTATION response without attributes an 11 49 9 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 50 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 51 10.1 Entry and Attribute Registration Template . . . . . . . 13 52 11 Security Considerations . . . . . . . . . . . . . . . . . . . 13 53 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 54 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 55 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 57 1 Abstract 59 The ANNOTATEMORE extension to the Internet Message Access Protocol 60 [IMAP4] permits clients and servers to maintain "metadata" on IMAP4 61 servers. This document describes two "profiles" for mailbox and 62 server metadata. 64 2 Conventions Used in This Document 66 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 67 NOT", and "MAY" in this document are to be interpreted as described 68 in "Key words for use in RFCs to Indicate Requirement Levels" 69 [KEYWORDS]. 71 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 73 In examples, "C:" and "S:" indicate lines sent by the client and 74 server respectively. 76 3 Open Issues: 78 1 Handling of failures in SETANNOTATION with multiple mailbox 79 entries specified, and at least one fails but others succeed. 81 2 Do we want explicit access control for the /server hierarchy, 82 beyond simply defining certain attributes as read-only in the spec? 84 3 Should mailbox name in entry use IMAPURL encoding or should it 85 be pure UTF8? 87 4 SETANNOTATION does not currently implement conditional store 88 behaviour. Do we want this? 90 5 Should LIST flags, mailbox referrals, STATUS info be attributes 91 of the /mailbox annotations? 93 6 Do we want the ability to search for annotations in the /server 94 or /mailbox hierarchies? 96 4 Change History 98 Changes from -00 to -01: 99 1. Multiple entry-att responses are now simply delimited by 100 spaces in line with ANNOTATE spec. Adjusted examples to match. 101 2. Fixed entry-list formal syntax item to account for unsolicited 102 parenthesised list of entries. 103 3. Removed setentries formal syntax item for simplicity since 104 its only used once. 105 4. Removed reference to 'message annotation' in section 5.1. 106 5. Changed formal syntax to restrict top level entries to 107 /server and /mailbox/{...} only. Re-arranged entry names 108 section to account for this change. 109 6. Added comment and example for ANNOTATION response to allow 110 servers to return separate responses for each entry if desired. 112 5 Introduction and Overview 114 The ANNOTATEMORE extension is present in any IMAP4 implementation 115 which returns "ANNOTATEMORE" as one of the supported capabilities in 116 the CAPABILITY command response. 118 The goal of ANNOTATEMORE is to provide a means for clients to store 119 and retrieve "metadata" on an IMAP4 server. This draft defines 120 "profiles" for storing metadata associated with specific mailboxes 121 and the server as a whole. 123 The ANNOTATEMORE extension adds two new commands and one new 124 untagged response to the IMAP4 base protocol. 126 This extension makes the following changes to the IMAP4 protocol: 128 a adds a new SETANNOTATION command 129 b adds a new GETANNOTATION command 130 c adds a new ANNOTATION untagged response 131 The data model used in ANNOTATEMORE is exactly the same as that used 132 in the ANNOTATE [ANNOTATE] extension to IMAP4. This is modeled 133 after that of the Application Configuration Access Protocol [ACAP] 134 with the exception of inheritance which is not deemed necessary 135 here. 137 The rest of this document describes the data model and protocol 138 changes more rigorously. 140 6 Data Model 142 6.1 Overview 144 The data model used in ANNOTATEMORE is one of a uniquely named entry 145 with a set of uniquely named attributes, each of which has a value. 146 An annotation can contain multiple named entries. For example, a 147 general comment being added to a mailbox may have an entry name of 148 "/mailbox/{INBOX}/comment". This entry could include named 149 attributes such as "value", "modifiedsince", "acl" etc to represent 150 properties and data associated with the entry. 152 The protocol changes to IMAP described below allow a client to 153 access or change the values of any attributes in any entries in an 154 annotation, assuming it has sufficient access rights to do so. 156 6.2 Namespace of entries and attributes 158 Each annotation is made up of a set of entries. Each entry has a 159 hierarchical name in UTF-8, with each component of the name 160 separated by a slash ("/"). 162 Each entry is made up of a set of attributes. Each attribute has a 163 hierarchical name in UTF-8, with each component of the name 164 separated by a period ("."). 166 The value of an attribute is NIL (has no value), or a string of zero 167 or more octets. 169 Entry and attribute names are not permitted to contain asterisk 170 ("*") or percent ("%") characters and MUST be valid UTF-8 strings 171 which do not contain NUL. Invalid entry or attribute names result 172 in a BAD response in any IMAP commands where they are used. 174 Use of non-visible UTF-8 characters in entry and attribute names is 175 discouraged. 177 This specification defines an initial set of entry and attribute 178 names available for use with mailbox and server annotations. In 179 addition an extension mechanism is described to allow additional 180 names to be added for extensibility. 182 6.2.1 Entry Names 184 Entry names MUST be specified in a standards track or IESG approved 185 experimental RFC, or fall under the vendor namespace. See Section 186 10.1 for the registration template. This specification only allows 187 two top-level entry types for servers and mailboxes. 189 6.2.1.1 Server Entries 191 /server 192 Defines the top-level of entries associated with the server. 193 This entry itself cannot be accessed directly. 195 /server/comment 196 Defines a comment or note associated with the server. 198 /server/motd 199 Defines a "message of the day" for the server. This entry is 200 always read-only - clients cannot change it. 202 /server/admin 203 Indicates a method for contacting the server administrator. 204 This may be a URL (e.g. a mailto URL) or other contact 205 information, such as a telephone number. This entry is always 206 read-only - clients cannot change it. 208 /server/vendor/ 209 Defines the top-level of entries associated with the server as 210 created by a particular product of some vendor. This entry can 211 be used by vendors to provide server or client specific 212 attributes. The vendor-token MUST be registered with IANA. 214 6.2.1.2 Mailbox Entries 216 /mailbox 217 Defines the top-level of entries associated with mailboxes. 218 This entry itself cannot be accessed directly. 220 /mailbox/{} 221 Defines the top-level of entries associated with a specific 222 mailbox. The is the name of the mailbox encoded 223 using the mailbox name encoding rules described in the IMAP URL 224 standard [IMAPURL]. The mailbox name appears inside 225 curly-braces to delimit it from the following levels of entry 226 name hierarchy, since it is possible that the mailbox name 227 itself contains the '/' characters used to delimit entry name 228 hierarchical components. This entry itself cannot be accessed 229 directly. 231 /mailbox/{}/comment 232 Defines a comment or note associated with a mailbox. 234 /mailbox/{}/sort 235 Defines the default sort criteria [SORT] to use when first 236 displaying the mailbox contents to the user, or NIL if sorting 237 is not required. 239 /mailbox/{}/thread 240 Defines the default thread criteria [THREAD] to use when first 241 displaying the mailbox contents to the user, or NIL if threading 242 is not required. If both sort and thread are not NIL, then 243 threading should take precedence over sorting. 245 /mailbox/{}/check 246 Boolean value "true" or "false" that indicates whether this 247 mailbox should be checked at regular intervals by the client. 248 The interval in minutes is specified by the checkperiod 249 attribute. 251 /mailbox/{}/checkperiod 252 Numeric value indicating a period of minutes to use for checking 253 a mailbox that has the check attribute set to "true". 255 /mailbox/{}/vendor/ 256 Defines the top-level of entries associated with a specific 257 mailbox as created by a particular product of some vendor. This 258 entry can be used by vendors to provide client specific 259 attributes. The vendor-token MUST be registered with IANA. 261 6.2.2 Attribute Names 263 Attribute names MUST be specified in a standards track or IESG 264 approved experimental RFC, or fall under the vendor namespace. See 265 Section 10.1 for the registration template. 267 All attribute names implicitly have a ".priv" and a ".shared" suffix 268 which maps to private and shared versions of the entry. Searching 269 or fetching without using either suffix includes both. The client 270 MUST specify either a ".priv" or ".shared" suffix when storing an 271 annotation. 273 value 274 The data value of the attribute. 276 size 277 The size of the value, in octets. Set automatically by the 278 server, read-only to clients. 280 modifiedsince 281 An opaque value set by the server when this entry is modified. 282 It can be used by the client to request notification of which 283 entries have changed since a particular point in time and is 284 useful for disconnected/synchronisation operations. 286 content-type 287 A MIME [MIME] content type and subtype that describes the nature 288 of the content of the "value" attribute. 290 vendor. 291 Defines an attribute associated with a particular product of 292 some vendor. This attribute can be used by vendors to provide 293 client specific attributes. The vendor-token MUST be registered 294 with IANA. 296 7 Private versus Shared and Access Control 298 As discussed in the ANNOTATE extension [ANNOTATE] there is a need to 299 support both private and shared annotations. This document adopts 300 the scheme used in [ANNOTATE] that adds two standard suffixes for 301 all attributes: ".shared" and ".priv". A GETANNOTATION command 302 which specifies neither uses both. SETANNOTATION commands MUST 303 explicitly use .priv or .shared suffixes. 305 A user can only store and retrieve private annotations on a mailbox 306 which is returned to them via a LIST or LSUB command. A user can 307 only store and retrieve shared annotations on a mailbox that they 308 can SELECT and which opens READ-WRITE. If a client attempts to 309 store or retrieve a shared annotation on a READ-ONLY mailbox, the 310 server MUST respond with a NO response. 312 8 IMAP Protocol Changes 314 8.1 GETANNOTATION Command 316 This extension adds the GETANNOTATION command. This allows clients 317 to retrieve annotations. 319 This command is only available in authenticated state [IMAP4]. 321 Arguments: entry-specifier 322 attribute-specifier 324 Responses: required ANNOTATION response 326 Result: OK - command completed 327 NO - command failure: can't access annotations on that mailbox 328 BAD - command unknown or arguments invalid 330 Example: 332 C: a GETANNOTATION "/server/comment" "value.priv" 333 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 334 S: a OK GETANNOTATION complete 336 In the above example, the contents of the "value" attribute 337 for the "/server/comment" entry is requested by the client 338 and returned by the server. 340 "*" and "%" wildcard characters can be used in either specifier to 341 match one or more characters at that position, with the exception 342 that "%" does not match the hierarchy delimiter for the specifier it 343 appears in (i.e. "/" for an entry specifier or "." for an attribute 344 specifier). Thus an entry specifier of "/server/%" would match 345 entries such as "/server/comment" and "/server/version", but not 346 "/server/comment/note". 348 Examples: 350 C: a GETANNOTATION "/server/*" "value.priv" 351 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 352 "/server/version" ("value.priv" "1.1") 353 "/server/motd/today" ("value.priv" "Closed at 1 pm") 354 S: a OK GETANNOTATION complete 356 In the above example, the contents of the "value" attributes 357 for any entries in the "/server" hierarchy are requested by 358 the client and returned by the server. 360 C: a GETANNOTATION "/server/%" "value" 361 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 362 ("value.shared" "Your comment") 363 "/server/motd" ("value.priv" "Its sunny outside!" 364 ("value.shared" "Today is a Holiday") 365 S: a OK GETANNOTATION complete 367 In the above example, the contents of the "value" attributes 368 for entries at the top level of the "/server" hierarchy 369 only, are requested by the client and returned by the 370 server. Both the .priv and .shared values are returned, as 371 neither were explicitly requested. 373 Entry and attribute specifiers can be lists of atomic specifiers, so 374 that multiple items of each type may be returned in a single 375 GETANNOTATION command. 377 Examples: 379 C: a GETANNOTATION ("/server/comment" "/server/motd") "value.priv" 380 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 381 "/server/motd" ("value.priv" "Its sunny outside!") 382 S: a OK GETANNOTATION complete 384 In the above example, the contents of the "value" attributes 385 for the two entries "/server/comment" and "/server/motd" are 386 requested by the client and returned by the server. 388 C: a GETANNOTATION "/server/comment" ("value.priv" "modifiedsince.priv") 389 S: * ANNOTATION "/server/comment" 390 ("value.priv" "My comment" 391 "modifiedsince.priv" "19990203205432") 392 S: a OK GETANNOTATION complete 394 In the above example, the contents of the "value" and 395 "modifiedsince" attributes for the "/server/comment" entry 396 are requested by the client and returned by the server. 398 8.2 SETANNOTATION command 400 This extension adds the SETANNOTATION command. This allows clients 401 to set annotations. 403 This command is only available in authenticated state [IMAP4]. 405 Arguments: entry 406 attribute-value 407 list of entry, attribute-values 409 Responses: no specific responses for this command 411 Result: OK - command completed 412 NO - command failure: can't set annotations 413 BAD - command unknown or arguments invalid 415 Sets the specified list of entries by adding or replacing the 416 specified attributes with the values provided. Clients can use NIL 417 for values of attributes it wants to remove from entries. The 418 server MAY return an unsolicited ANNOTATION response containing the 419 updated annotation data. Clients MUST NOT assume that an 420 unsolicited ANNOTATION response will be sent, and MUST assume that 421 if the command succeeds then the annotation has been changed. 423 Examples: 425 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 426 ("value.priv" "My new comment") 427 S: a OK SETANNOTATION complete 429 In the above example, the entry "/mailbox/{INBOX}/comment" 430 is created (if not already present) and the private 431 attribute "value" with data set to "My new comment" is 432 created if not already present, or replaced if it previously 433 exists. 435 C: a SETANNOTATION "/mailbox/{INBOX}/comment" ("value.priv" NIL) 436 S: a OK SETANNOTATION complete 438 In the above example, the private "value" attribute of the 439 entry "/mailbox/{INBOX}/comment" is removed. 441 Multiple entries can be set in a single SETANNOTATION command by 442 listing entry-attribute-value pairs in the list. 444 Example: 445 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 446 ("value.priv" "My new comment") 447 "/mailbox/{INBOX.shared}/comment" 448 ("value.shared" "This is a shared mailbox") 449 S: a OK SETANNOTATION complete 451 In the above example, the entries "/mailbox/{INBOX}/comment" 452 and "/mailbox/{INBOX.shared}/comment" are created (if not 453 already present) and the private and shared attributes 454 "value" are created respectively for each entry if not 455 already present, or replaced if they previously existed. 457 Multiple attributes can be set in a single SETANNOTATION command by 458 listing multiple attribute-value pairs in the entry list. 460 Example: 461 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 462 ("value.priv" "My new comment" 463 "vendor.foobar.bloop.priv" "foo's bar") 464 S: a OK SETANNOTATION complete 466 In the above example, the entry "/mailbox/{INBOX}/comment" 467 is created (if not already present) and the private 468 attributes "value" and "vendor.foobar.bloop" are created if 469 not already present, or replaced if they previously existed. 471 8.3 ANNOTATION Response 473 The ANNOTATION response displays results of a GETANNOTATION command, 474 or can be returned as a unsolicited response at anytime by the 475 server in response to a change in an annotation. 477 Servers SHOULD send unsolicited ANNOTATION responses if an 478 annotation is changed by a third-party, allowing servers to keep 479 clients updated with changes to annotations by other clients. In 480 this case, only the entries are returned in the ANNOTATION response, 481 not the attributes and values. If the client wants to update any 482 cached values it must explicitly retrieve those using a 483 GETANNOTATION command. 485 The ANNOTATION response can contain multiple entries in a single 486 response, but the server is free to return multiple responses for 487 each entry or group of entries if it desires. 489 This response is only available in authenticated state [IMAP4]. 491 8.3.1 ANNOTATION response with attributes and values 492 The response consists of a list of entries each of which has a 493 list of attribute-value pairs. 495 Examples: 497 C: a GETANNOTATION "/server/comment" "value.priv" 498 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 499 S: a OK GETANNOTATION complete 501 In the above example, a single entry with a single 502 attribute-value pair is returned by the server. 504 C: a GETANNOTATION ("/server/comment" "/server/motd") "value.priv" 505 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 506 "/server/motd" ("value.priv" "Its sunny outside!") 507 S: a OK GETANNOTATION complete 509 In the above example, two entries each with a single 510 attribute-value pair is returned by the server. 512 C: a GETANNOTATION ("/server/comment" "/server/motd") "value.priv" 513 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 514 S: * ANNOTATION "/server/motd" ("value.priv" "Its sunny outside!") 515 S: a OK GETANNOTATION complete 517 In the above example, the server returns two separate 518 response for each of the two entries requested. 520 C: a GETANNOTATION "/server/comment" ("value.priv" "modifiedsince.priv") 521 S: * ANNOTATION "/server/comment" ("value.priv" "My comment" 522 "modifiedsince.priv" "19990203205432") 523 S: a OK GETANNOTATION complete 525 In the above example, a single entry with two 526 attribute-value pairs is returned by the server. 528 8.3.2 Unsolicited ANNOTATION response without attributes and values 529 The response consists of a parenthesised list of entries, each 530 of which have changed on the server. 532 Examples: 534 C: a NOOP 535 S: * ANNOTATION ("/server/comment") 536 S: a OK NOOP complete 538 In the above example, the server indicates that the 539 "/server/comment" entry has been changed. 541 C: a NOOP 542 S: * ANNOTATION ("/server/comment" "/server/motd") 543 S: a OK NOOP complete 544 In the above example, the server indicates a change to two 545 entries. 547 9 Formal Syntax 549 The following syntax specification uses the Augmented Backus-Naur 550 Form (ABNF) notation as specified in [ABNF]. 552 Non-terminals referenced but not defined below are as defined by 553 [IMAP4]. 555 Except as noted otherwise, all alphabetic characters are case- 556 insensitive. The use of upper or lower case characters to define 557 token strings is for editorial clarity only. Implementations MUST 558 accept these strings in a case-insensitive fashion. 560 command-auth /= setannotation / getannotation 561 ; adds to original IMAP4 command 563 response-data /= "*" SP annotate-data CRLF 564 ; adds to original IMAP4 data responses 566 getannotation = "GETANNOTATION" SP entries SP attribs 567 ; new command 569 setannotation = "SETANNOTATION" SP entry-att *(SP entry-att) 570 ; new command 572 annotate-data = "ANNOTATION" SP entry-list 573 ; new response 575 entries = entry-match / "(" entry-match *(SP entry-match) ")" 576 ; entry specifiers that can include wildcards 578 attribs = attrib-match / "(" attrib-match *(SP attrib-match) ")" 579 ; attribute specifiers that can include wildcards 581 entry-list = entry-att *(SP entry-att) / 582 "(" entry *(SP entry) ")" 583 ; entry attribute-value pairs list for 584 ; GETANNOTATION response, or 585 ; parenthesised entry list for unsolicited 586 ; notification of annotation changes 588 entry-att = entry SP "(" att-value *(SP att-value) ")" 589 att-value = attrib SP value 591 atom-slash = any ATOM-CHAR except "/" 592 atom-dot = any ATOM-CHAR except "." 594 entry = DQUOTE (entry-server / entry-mbox) DQUOTE 595 entry-server = "/server/" sub-entry 596 entry-mbox = "/mailbox/{" entry-mname "}/" sub-entry 597 entry-mname = string 598 sub-entry = 1*atom-slash *("/" 1*atom-slash) 600 entry-match = DQUOTE (entry-m-server / entry-m-mbox) DQUOTE 601 entry-m-server = "/server/" sub-m-entry 602 entry-m-mbox = "/mailbox/{" entry-m-mname "}/" sub-m-entry 603 entry-m-mname = list-mailbox 604 sub-m-entry = 1*entry-m-atom *("/" 1*entry-m-atom) 605 entry-m-atom = 1*(list-wildcards / atom-slash) 607 attrib = DQUOTE 1*atom-dot *("." 1*atom-dot) DQUOTE 608 attrib-match = DQUOTE 1*attrib-match-atom 609 *("." 1*attrib-match-atom) DQUOTE 610 attrib-match-atom = 1*(list-wildcards / atom-dot) 612 value = nstring 614 10 IANA Considerations 616 Both entry names and attribute names MUST be specified in a 617 standards track or IESG approved experimental RFC, or fall under the 618 vendor namespace. Vendor names MUST be registered. 620 10.1 Entry and Attribute Registration Template 622 To: iana@iana.org 623 Subject: IMAP Annotate More Registration 625 Please register the following IMAP Annotate More item: 627 [] Entry [] Attribute 628 [] Vendor [] Open: RFC _______ 630 Name: ______________________________ 632 Description: _______________________ 634 ____________________________________ 636 ____________________________________ 638 Contact person: ____________________ 640 email: ____________________ 642 11 Security Considerations 644 There are no known security issues with this extension. 646 12 References 648 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 649 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 650 November 1997. 652 [ACAP] Newman, C., and Myers, J. "ACAP -- Application Configuration 653 Access Protocol", RFC 2244, November 1997. 655 [ANNOTATE] Daboo, C., Gellens, R., "IMAP ANNOTATE Extension", 656 draft-ietf-imapext-annotate-05.txt, November 2002. 658 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 659 4rev1", RFC 2060, University of Washington, December 1996. 661 [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, 662 September 1997. 664 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 665 Requirement Levels", RFC 2119, Harvard University, March 1997. 667 [MIME] Freed, N., and Borenstein, N. "MIME (Multipurpose Internet 668 Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. 670 [SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol 671 - Sort Extension", draft-ietf-imapext-sort-10.txt, University of 672 Washington, Oceana Matrix Ltd., October 2002. 674 [THREAD] Crispin, M., Murchison, K., "Internet Message Access 675 Protocol - Thread Extension", draft-ietf-imapext-thread-12.txt, 676 University of Washington, Oceana Matrix Ltd., October 2001. 678 13 Acknowledgments 680 The ideas expressed in this document are based on the message 681 annotation document that was co-authored by Randall Gellens. 683 14 Author's Address 685 Cyrus Daboo 686 Cyrusoft International, Inc. 687 Suite 780, 5001 Baum Blvd. 688 Pittsburgh, PA 15213 689 U.S.A. 691 Email: daboo@cyrusoft.com