idnits 2.17.1 draft-daboo-imap-annotatemore-00.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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 115 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 (February 2002) is 8105 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-03 ** 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-07 == Outdated reference: A later version (-12) exists of draft-ietf-imapext-thread-07 -- Possible downref: Normative reference to a draft: ref. 'THREAD' Summary: 12 errors (**), 0 flaws (~~), 6 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-00.txt February 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 Introduction and Overview . . . . . . . . . . . . . . . . . 3 34 5 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 35 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 36 5.2 Namespace of entries and attributes . . . . . . . . . . . 4 37 5.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . 4 38 5.2.2 Attribute Names . . . . . . . . . . . . . . . . . . . 6 39 6 Private versus Shared and Access Control . . . . . . . . . . 6 40 7 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7 41 7.1 GETANNOTATION Command . . . . . . . . . . . . . . . . . 7 42 7.2 SETANNOTATION command . . . . . . . . . . . . . . . . . . 8 43 7.3 ANNOTATION Response . . . . . . . . . . . . . . . . . . 10 44 7.3.1 ANNOTATION response with attributes and values . . . 10 45 7.3.2 Unsolicted ANNOTATION response without attributes and 11 46 8 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 47 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 48 9.1 Entry and Attribute Registration Template . . . . . . . . 13 49 10 Security Considerations . . . . . . . . . . . . . . . . . . 13 50 11 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 51 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 52 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 54 1 Abstract 56 The ANNOTATEMORE extension to the Internet Message Access Protocol 57 [IMAP4] permits clients and servers to maintain "metadata" on IMAP4 58 servers. This document describes two "profiles" for mailbox and 59 server metadata. 61 2 Conventions Used in This Document 63 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 64 NOT", and "MAY" in this document are to be interpreted as described 65 in "Key words for use in RFCs to Indicate Requirement Levels" 66 [KEYWORDS]. 68 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 70 In examples, "C:" and "S:" indicate lines sent by the client and 71 server respectively. 73 3 Open Issues: 75 1 Handling of failures in SETANNOTATION with multiple mailbox 76 entries specified, and at least one fails but others succeed. 78 2 Do we want explicit access control for the /server hierarchy, 79 beyond simply defining certain attributes as read-only in the spec? 80 3 Should mailbox name in entry use IMAPURL encoding or should it 81 be pure UTF8? 83 4 SETANNOTATION does not currently implement conditional store 84 behaviour. Do we want this? 86 5 Should LIST flags, mailbox referrals, STATUS info be attributes 87 of the /mailbox annotations? 89 6 Do we want the ability to search for annotations in the /server 90 or /mailbox hierarchies? 92 4 Introduction and Overview 94 The ANNOTATEMORE extension is present in any IMAP4 implementation 95 which returns "ANNOTATEMORE" as one of the supported capabilities in 96 the CAPABILITY command response. 98 The goal of ANNOTATEMORE is to provide a means for clients to store 99 and retrieve "metadata" on an IMAP4 server. This draft defines 100 "profiles" for storing metadata associated with specific mailboxes 101 and the server as a whole. 103 The ANNOTATEMORE extension adds two new commands and one new 104 untagged response to the IMAP4 base protocol. 106 This extension makes the following changes to the IMAP4 protocol: 108 1 adds a new SETANNOTATION command 109 2 adds a new GETANNOTATION command 110 3 adds a new ANNOTATION untagged response 112 The data model used in ANNOTATEMORE is exactly the same as that used 113 in the ANNOTATE [ANNOTATE] extension to IMAP4. This is modeled 114 after that of the Application Configuration Access Protocol [ACAP] 115 with the exception of inheritance which is not deemed necessary 116 here. 118 The rest of this document describes the data model and protocol 119 changes more rigorously. 121 5 Data Model 123 5.1 Overview 125 The data model used in ANNOTATEMORE is one of a uniquely named entry 126 with a set of uniquely named attributes, each of which has a value. 127 An annotation can contain multiple named entries. For example, a 128 general comment being added to a mailbox may have an entry name of 129 "/mailbox/{INBOX}/comment". This entry could include named 130 attributes such as "value", "modifiedsince", "acl" etc to represent 131 properties and data associated with the entry. 133 The protocol changes to IMAP described below allow a client to 134 access or change the values of any attributes in any entries in a 135 message annotation, assuming it has sufficient access rights to do 136 so. 138 5.2 Namespace of entries and attributes 140 Each annotation is made up of a set of entries. Each entry has a 141 hierarchical name in UTF-8, with each component of the name 142 separated by a slash ("/"). 144 Each entry is made up of a set of attributes. Each attribute has a 145 hierarchical name in UTF-8, with each component of the name 146 separated by a period ("."). 148 The value of an attribute is NIL (has no value), or a string of zero 149 or more octets. 151 Entry and attribute names are not permitted to contain asterisk 152 ("*") or percent ("%") characters and MUST be valid UTF-8 strings 153 which do not contain NUL. Invalid entry or attribute names result 154 in a BAD response in any IMAP commands where they are used. 156 Use of non-visible UTF-8 characters in entry and attribute names is 157 discouraged. 159 This specification defines an initial set of entry and attribute 160 names available for use with mailbox and server annotations. In 161 addition an extension mechanism is described to allow additional 162 names to be added for extensibility. 164 5.2.1 Entry Names 166 Entry names MUST be specified in a standards track or IESG approved 167 experimental RFC, or fall under the vendor namespace. See Section 168 9.1 for the registration template. 170 /mailbox 171 Defines the top-level of entries associated with mailboxes. 172 This entry itself does not have any associated attributes. 174 /mailbox/{} 175 Defines the top-level of entries associated with a specific 176 mailbox. The is the name of the mailbox encoded 177 using the mailbox name encoding rules described in the IMAP URL 178 standard [IMAPURL]. The mailbox name appears inside 179 curly-braces to delimit it from the following levels of entry 180 name hierarchy, since it is possible that the mailbox name 181 itself contains the '/' characters uses to delimit entry name 182 hierarchical components. This entry itself does not have any 183 associated attributes. 185 /mailbox/{}/comment 186 Defines a comment or note associated with a mailbox. 188 /mailbox/{}/sort 189 Defines the default sort criteria [SORT] to use when first 190 displaying the mailbox contents to the user, or NIL if sorting 191 is not required. 193 /mailbox/{}/thread 194 Defines the default thread criteria [THREAD] to use when first 195 displaying the mailbox contents to the user, or NIL if threading 196 is not required. If both sort and thread are not NIL, then 197 threading should take precedence over sorting. 199 /mailbox/{}/check 200 Boolean value "true" or "false" that indicates whether this 201 mailbox should be checked at regular intervals by the client. 202 The interval in minutes is specified by the checkperiod 203 attribute. 205 /mailbox/{}/checkperiod 206 Numeric value indicating a period of minutes to use for checking 207 a mailbox that has the check attribute set to "true". 209 /mailbox/{}/vendor/ 210 Defines the top-level of entries associated with a specific 211 mailbox as created by a particular product of some vendor. This 212 entry can be used by vendors to provide client specific 213 attributes. The vendor-token MUST be registered with IANA. 215 /server 216 Defines the top-level of entries associated with the server. 217 This entry itself does not have any associated attributes. 219 /server/comment 220 Defines a comment or note associated with the server. 222 /server/motd 223 Defines a "message of the day" for the server. This entry is 224 always read-only - clients cannot change it. 226 /server/admin 227 Indicates a method for contacting the server administrator. 228 This may be a URL (e.g. a mailto URL) or other contact 229 information, such as a telephone number. This entry is always 230 read-only - clients cannot change it. 232 /server/vendor/ 233 Defines the top-level of entries associated with the server as 234 created by a particular product of some vendor. This entry can 235 be used by vendors to provide server or client specific 236 attributes. The vendor-token MUST be registered with IANA. 238 5.2.2 Attribute Names 240 Attribute names MUST be specified in a standards track or IESG 241 approved experimental RFC, or fall under the vendor namespace. See 242 Section 9.1 for the registration template. 244 All attribute names implicitly have a ".priv" and a ".shared" suffix 245 which maps to private and shared versions of the entry. Searching 246 or fetching without using either suffix includes both. The client 247 MUST specify either a ".priv" or ".shared" suffix when storing an 248 annotation. 250 value 251 The data value of the attribute. 253 size 254 The size of the value, in octets. Set automatically by the 255 server, read-only to clients. 257 modifiedsince 258 An opaque value set by the server when this entry is modified. 259 It can be used by the client to request notification of which 260 entries have changed since a particular point in time and is 261 useful for disconnected/synchronisation operations. 263 content-type 264 A MIME [MIME] content type and subtype that describes the nature 265 of the content of the "value" attribute. 267 vendor. 268 Defines an attribute associated with a particular product of 269 some vendor. This attribute can be used by vendors to provide 270 client specific attributes. The vendor-token MUST be registered 271 with IANA. 273 6 Private versus Shared and Access Control 275 As discussed in the ANNOTATE extension [ANNOTATE] there is a need to 276 support both private and shared annotations. This document adopts 277 the scheme used in [ANNOTATE] that adds two standard suffixes for 278 all attributes: ".shared" and ".priv". A GETANNOTATION command 279 which specifies neither uses both. SETANNOTATION commands MUST 280 explicitly use .priv or .shared suffixes. 282 A user can only store and retrieve private annotations on a mailbox 283 which is returned to them via a LIST or LSUB command. A user can 284 only store and retrieve shared annotations on a mailbox that they 285 can SELECT and which opens READ-WRITE. If a client attempts to 286 store or retrieve a shared annotation on a READ-ONLY mailbox, the 287 server MUST respond with a NO response. 289 7 IMAP Protocol Changes 291 7.1 GETANNOTATION Command 293 This extension adds the GETANNOTATION command. This allows clients 294 to retrieve annotations. 296 This command is only available in authenticated state [IMAP4]. 298 Arguments: entry-specifier 299 attribute-specifier 301 Responses: required ANNOTATION response 303 Result: OK - command completed 304 NO - command failure: can't access annotations on that mailbox 305 BAD - command unknown or arguments invalid 307 Example: 309 C: a GETANNOTATION "/server/comment" "value.priv" 310 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 311 S: a OK GETANNOTATION complete 313 In the above example, the contents of the "value" attribute 314 for the "/server/comment" entry is requested by the client 315 and returned by the server. 317 "*" and "%" wildcard characters can be used in either specifier to 318 match match one or more characters at that position, with the 319 exception that "%" does not match the hierarchy delimiter for the 320 specifier it appears in (i.e. "/" for an entry specifier or "." for 321 an attribute specifer). Thus an entry specifier of "/server/%" 322 would match entries such as "/server/comment" and "/server/version", 323 but not "/server/comment/note". 325 Examples: 327 C: a GETANNOTATION "/server/*" "value.priv" 328 S: * ANNOTATION ("/server/comment" ("value.priv" "My comment")) 329 ("/server/version" ("value.priv" "1.1")) 330 ("/server/motd/today" ("value.priv" "Closed at 1 pm")) 331 S: a OK GETANNOTATION complete 333 In the above example, the contents of the "value" attributes 334 for any entries in the "/server" hierarchy are requested by 335 the client and returned by the server. 337 C: a GETANNOTATION "/server/%" "value" 338 S: * ANNOTATION ("/server/comment" ("value.priv" "My comment") 339 ("value.shared" "Your comment")) 340 ("/server/motd" ("value.priv" "Its sunny outside!") 341 ("value.shared" "Today is a Holiday")) 342 S: a OK GETANNOTATION complete 344 In the above example, the contents of the "value" attributes 345 for entries at the top level of the "/server" hierarchy 346 only, are requested by the client and returned by the 347 server. Both the .priv and .shared values are returned, as 348 neither were explicitly requested. 350 Entry and attribute specifiers can be lists of atomic specifiers, so 351 that multiple items of each type may be returned in a single 352 GETANNOTATION command. 354 Examples: 356 C: a GETANNOTATION ("/server/comment" "/server/motd") "value.priv" 357 S: * ANNOTATION ("/server/comment" ("value.priv" "My comment")) 358 ("/server/motd" ("value.priv" "Its sunny outside!")) 359 S: a OK GETANNOTATION complete 361 In the above example, the contents of the "value" attributes 362 for the two entries "/server/comment" and "/server/motd" are 363 requested by the client and returned by the server. 365 C: a GETANNOTATION "/server/comment" ("value.priv" "modifiedsince.priv") 366 S: * ANNOTATION "/server/comment" 367 ("value.priv" "My comment" 368 "modifiedsince.priv" "19990203205432") 369 S: a OK GETANNOTATION complete 371 In the above example, the contents of the "value" and 372 "modifiedsince" attributes for the "/server/comment" entry 373 are requested by the client and returned by the server. 375 7.2 SETANNOTATION command 377 This extension adds the SETANNOTATION command. This allows clients 378 to set annotations. 380 This command is only available in authenticated state [IMAP4]. 382 Arguments: entry 383 attribute-value 384 list of entry, attribute-values 386 Responses: no specific responses for this command 388 Result: OK - command completed 389 NO - command failure: can't set annotations 390 BAD - command unknown or arguments invalid 392 Sets the specified list of entries by adding or replacing the 393 specified attributes with the values provided. Clients can use NIL 394 for values of attributes it wants to remove from entries. The 395 server MAY return an unsolicited ANNOTATION response containing the 396 updated annotation data. Clients MUST NOT assume that an 397 unsolicited ANNOTATION response will be sent, and MUST assume that 398 if the command succeeds then the annotation has been changed. 400 Examples: 402 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 403 ("value.priv" "My new comment") 404 S: a OK SETANNOTATION complete 406 In the above example, the entry "/mailbox/{INBOX}/comment" 407 is created (if not already present) and the private 408 attribute "value" with data set to "My new comment" is 409 created if not already present, or replaced if it previously 410 exists. 412 C: a SETANNOTATION "/mailbox/{INBOX}/comment" ("value.priv" NIL) 413 S: a OK SETANNOTATION complete 415 In the above example, the private "value" attribute of the 416 entry "/mailbox/{INBOX}/comment" is removed. 418 Multiple entries can be set in a single SETANNOTATION command by 419 listing entry-attribute-value pairs in the list. 421 Example: 422 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 423 ("value.priv" "My new comment") 424 "/mailbox/{INBOX.shared}/comment" 425 ("value.shared" "This is a shared mailbox") 426 S: a OK SETANNOTATION complete 428 In the above example, the entries "/mailbox/{INBOX}/comment" 429 and "/mailbox/{INBOX.shared}/comment" are created (if not 430 already present) and the private and shared attributes 431 "value" are created respectively for each entry if not 432 already present, or replaced if they previously existed. 434 Multiple attributes can be set in a single SETANNOTATION command by 435 listing multiple attribute-value pairs in the entry list. 437 Example: 438 C: a SETANNOTATION "/mailbox/{INBOX}/comment" 439 ("value.priv" "My new comment" 440 "vendor.foobar.bloop.priv" "foo's bar") 441 S: a OK SETANNOTATION complete 443 In the above example, the entry "/mailbox/{INBOX}/comment" 444 is created (if not already present) and the private 445 attributes "value" and "vendor.foobar.bloop" are created if 446 not already present, or replaced if they previously existed. 448 7.3 ANNOTATION Response 450 The ANNOTATION response displays results of a GETANNOTATION command, 451 or can be returned as a unsolicited response at anytime by the 452 server in response to a change in an annotation. 454 Servers SHOULD send unsolicited ANNOTATION responses if an 455 annotation is changed by a third-party, allowing servers to keep 456 clients updated with changes to annotations by other clients. In 457 this case, only the entries are returned in the ANNOTATION response, 458 not the attributes and values. If the client wants to update any 459 cached values it must explicitly retrieve those using a 460 GETANNOTATION command. 462 This response is only available in authenticated state [IMAP4]. 464 7.3.1 ANNOTATION response with attributes and values 465 The response consists of a list of entries each of which has a 466 list of attribute-value pairs. 468 Examples: 470 C: a GETANNOTATION "/server/comment" "value.priv" 471 S: * ANNOTATION "/server/comment" ("value.priv" "My comment") 472 S: a OK GETANNOTATION complete 474 In the above example, a single entry with a single 475 attribute-value pair is returned by the server. 477 C: a GETANNOTATION ("/server/comment" "/server/motd") "value.priv" 478 S: * ANNOTATION ("/server/comment" ("value.priv" "My comment")) 479 ("/server/motd" ("value.priv" "Its sunny outside!")) 480 S: a OK GETANNOTATION complete 482 In the above example, two entries each with a single 483 attribute-value pair is returned by the server. 485 C: a GETANNOTATION "/server/comment" ("value.priv" "modifiedsince.priv") 486 S: * ANNOTATION "/server/comment" (("value.priv" "My comment") 487 ("modifiedsince.priv" "19990203205432")) 488 S: a OK GETANNOTATION complete 490 In the above example, a single entry with two 491 attribute-value pairs is returned by the server. 493 7.3.2 Unsolicted ANNOTATION response without attributes and values 494 The response consists of a list of entries each which have 495 changed on the server. 497 Examples: 499 C: a NOOP 500 S: * ANNOTATION "/server/comment" 501 S: a OK NOOP complete 503 In the above example, the server indicates that the 504 "/server/comment" entry has been changed. 506 C: a NOOP 507 S: * ANNOTATION ("/server/comment")("/server/motd") 508 S: a OK NOOP complete 510 In the above example, the server indicates a change to two 511 entries. 513 8 Formal Syntax 515 The following syntax specification uses the Augmented Backus-Naur 516 Form (ABNF) notation as specified in [ABNF]. 518 Non-terminals referenced but not defined below are as defined by 519 [IMAP4]. 521 Except as noted otherwise, all alphabetic characters are case- 522 insensitive. The use of upper or lower case characters to define 523 token strings is for editorial clarity only. Implementations MUST 524 accept these strings in a case-insensitive fashion. 526 command-auth /= setannotation / getannotation 527 ; adds to original IMAP4 command 529 response-data /= "*" SP annotate-data CRLF 530 ; adds to original IMAP4 data responses 532 getannotation = "GETANNOTATION" SP entries SP attribs 533 ; new command 535 setannotation = "SETANNOTATION" SP setentries 536 ; new command 537 annotate-data = "ANNOTATION" SP entry-list 538 ; new response 540 entries = entry-match / "(" entry-match *(SP entry-match) ")" 541 ; entry specifiers that can include wildcards 543 attribs = attrib-match / "(" attrib-match *(SP attrib-match) ")" 544 ; attribute specifiers that can include wildcards 546 entry-list = entry-att / "(" entry-att *(SP entry-att) ")" 547 ; entry, attribute-value pairs list 549 setentries = entry-att *(SP entry-att) 550 ; multiple entry, attribute-value pairs list 552 entry-att = entry SP "(" att-value *(SP att-value) ")" 553 att-value = attrib SP value 555 atom-slash = any ATOM-CHAR except "/" 556 atom-dot = any ATOM-CHAR except "." 558 entry = DQUOTE 1*atom-slash *("/" 1*atom-slash) DQUOTE 559 entry-match = DQUOTE 1*entry-match-atom 560 *("/" 1*entry-match-atom) DQUOTE 561 entry-match-atom = 1*(list-wildcards / atom-slash) 563 attrib = DQUOTE 1*atom-dot *("." 1*atom-dot) DQUOTE 564 attrib-match = DQUOTE 1*attrib-match-atom 565 *("." 1*attrib-match-atom) DQUOTE 566 attrib-match-atom = 1*(list-wildcards / atom-dot) 568 value = nstring 569 9 IANA Considerations 571 Both entry names and attribute names MUST be specified in a 572 standards track or IESG approved experimental RFC, or fall under the 573 vendor namespace. Vendor names MUST be registered. 575 9.1 Entry and Attribute Registration Template 577 To: iana@iana.org 578 Subject: IMAP Annotate More Registration 580 Please register the following IMAP Annotate More item: 582 [] Entry [] Attribute 583 [] Vendor [] Open: RFC _______ 585 Name: ______________________________ 587 Description: _______________________ 589 ____________________________________ 591 ____________________________________ 593 Contact person: ____________________ 595 email: ____________________ 597 10 Security Considerations 599 There are no known security issues with this extension. 601 11 References 603 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 604 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 605 November 1997. 607 [ACAP] Newman, C., and Myers, J. "ACAP -- Application Configuration 608 Access Protocol", RFC 2244, November 1997. 610 [ANNOTATE] Daboo, C., Gellens, R., "IMAP ANNOTATE Extension", 611 draft-ietf-imapext-annotate-03.txt, January 2002. 613 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 614 4rev1", RFC 2060, University of Washington, December 1996. 616 [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, 617 September 1997. 619 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 620 Requirement Levels", RFC 2119, Harvard University, March 1997. 622 [MIME] Freed, N., and Borenstein, N. "MIME (Multipurpose Internet 623 Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. 625 [SORT] Crispin, M., Murchison, K., "Internet Message Access Protocol 626 - Sort Extension", draft-ietf-imapext-sort-07.txt, University of 627 Washington, Oceana Matrix Ltd., September 2001. 629 [THREAD] Crispin, M., Murchison, K., "Internet Message Access 630 Protocol - Thread Extension", draft-ietf-imapext-thread-07.txt, 631 University of Washington, Oceana Matrix Ltd., September 2001. 633 12 Acknowledgments 635 The ideas expressed in this document are based on the message 636 annotation document that was co-authored by Randall Gellens. 638 13 Author's Address 640 Cyrus Daboo 641 Cyrusoft International, Inc. 642 Suite 780, 5001 Baum Blvd. 643 Pittsburgh, PA 15213 644 U.S.A. 646 Email: daboo@cyrusoft.com