idnits 2.17.1 draft-daboo-imap-annotatemore-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1372. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2006) is 6601 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: 'METADATA TOOMANY' is mentioned on line 837, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-imapext-i18n-06 == Outdated reference: A later version (-18) exists of draft-ietf-imapext-list-extensions-16 == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-16) exists of draft-ietf-imapext-annotate-15 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft March 29, 2006 4 Expires: September 30, 2006 6 IMAP METADATA Extension 7 draft-daboo-imap-annotatemore-09 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 30, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The METADATA extension to the Internet Message Access Protocol 41 permits clients and servers to maintain "annotations" or "meta data" 42 on IMAP servers. It is possible to have annotations on a per-mailbox 43 basis or on the server as a whole. For example, this would allow 44 comments about the purpose of a particular mailbox to be "attached" 45 to that mailbox, or a "message of the day" containing server status 46 information to be made available to anyone logging in to the server. 48 Change History (to be removed prior to publication as an RFC) 49 Changes from -08 to -09: 50 1. Remove content-language attribute and reference. 51 2. Changed capability and command names. 52 3. Revised abstract. 54 Changes from -07 to -08: 55 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 56 for entry/attribute names. 57 2. Updated examples to match new astring syntax. 58 3. Changed CAPABILITY name due to incompatible syntax change. 59 4. Removed content-type attribute. 60 5. Added Content-type to IANA registration for entries. 61 6. Removed vendor attributes. 62 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 63 cases. 64 8. Removed wildcards for attributes. 65 9. Entry/attributes can now only be ASCII. 66 10. Tied up text wrt storing/fetching. 67 11. Added Conventions section 68 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 69 '.'. 70 13. Changed to use IMAP ABNF extensions document for some formal 71 syntax items. 73 Changes from -06 to -07: 74 1. Reworded /checkperiod item. 75 2. Clarified unsolicited response behaviour. 77 Changes from -05 to -06: 78 1. Removed 'modifiedsince' attribute as there is currently no use 79 for it. 80 2. Added content-language attribute. 81 3. Changed access to allow .priv and .shared on any mailbox returned 82 by LIST/LSUB. 83 4. Added IANA registrations for items defined in this document. 84 5. Added latest IPR statement. 85 6. Updated references. 87 Changes from -04 to -05: 88 1. Fix for valid IMAP state of commands. 89 2. Fix formatting, ID nits etc. 91 Changes from -03 to -04: 92 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 93 2. Clarification of annotation loss on implicit removal of \Noselect 94 mailboxes. 96 3. Now requires roll-back of all changes to matching mailboxes if 97 there is a partial failure in SETANNOTATION. 99 Changes from -02 to -03: 100 1. Reworked entry naming scheme to split out mailbox name and use 101 empty string for server items. 103 Changes from -01 to -02: 104 1. SETANNOTATION lists use (..). 105 2. Explicitly state behaviour of unsolicited responses. 106 3. Adding SHOULD behaviour for rename/delete of mailboxes. 107 4. Added statement about supporting annotations on \Noselect 108 mailboxes. 109 5. Cleaned up formal syntax to use IMAP string type for entry and 110 attributes, with requirements on how the string is formatted. 111 6. Use of ACAP vendor subtree registry for vendor tokens. 113 Changes from -00 to -01: 114 1. Multiple entry-att responses are now simply delimited by spaces 115 in line with ANNOTATE spec. Adjusted examples to match. 116 2. Fixed entry-list formal syntax item to account for unsolicited 117 parenthesised list of entries. 118 3. Removed setentries formal syntax item for simplicity since its 119 only used once. 120 4. Removed reference to 'message annotation' in section 5.1. 121 5. Changed formal syntax to restrict top level entries to /server 122 and /mailbox/{...} only. Re-arranged entry names section to 123 account for this change. 124 6. Added comment and example for ANNOTATION response to allow 125 servers to return separate responses for each entry if desired. 127 Table of Contents 129 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 130 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 131 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 132 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 133 3.2. Namespace of entries and attributes . . . . . . . . . . . 6 134 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 7 135 3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 8 136 3.3. Private versus Shared and Access Control . . . . . . . . . 9 137 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 9 138 4.1. General Considerations . . . . . . . . . . . . . . . . . . 9 139 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 10 140 4.3. Extended LIST Command Extensions . . . . . . . . . . . . . 12 141 4.3.1. Unsolicited LIST repsonse . . . . . . . . . . . . . . 16 142 4.4. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 16 143 4.5. METADATA Response . . . . . . . . . . . . . . . . . . . . 19 144 4.5.1. METADATA response with attributes and values . . . . . 19 145 4.5.2. Unsolicited METADATA response without attributes 146 and values . . . . . . . . . . . . . . . . . . . . . . 20 147 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 148 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 149 6.1. Entry and Attribute Registration Template . . . . . . . . 23 150 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 23 151 6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 24 152 6.2.2. /motd . . . . . . . . . . . . . . . . . . . . . . . . 24 153 6.2.3. /admin . . . . . . . . . . . . . . . . . . . . . . . . 25 154 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 25 155 6.3.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 25 156 6.3.2. /sort . . . . . . . . . . . . . . . . . . . . . . . . 26 157 6.3.3. /thread . . . . . . . . . . . . . . . . . . . . . . . 26 158 6.3.4. /check . . . . . . . . . . . . . . . . . . . . . . . . 27 159 6.3.5. /checkperiod . . . . . . . . . . . . . . . . . . . . . 27 160 6.4. Attribute Registrations . . . . . . . . . . . . . . . . . 27 161 6.4.1. value . . . . . . . . . . . . . . . . . . . . . . . . 28 162 6.4.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 28 163 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 164 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 165 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 166 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 167 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 168 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 169 Intellectual Property and Copyright Statements . . . . . . . . . . 32 171 1. Introduction and Overview 173 The METADATA extension is present in any IMAP [RFC3501] 174 implementation which returns "METADATA" as one of the supported 175 capabilities in the CAPABILITY command response. The "LISTEXT" 176 [I-D.ietf-imapext-list-extensions] extension MUST also be present. 178 The goal of METADATA is to provide a means for clients to set and 179 retrieve "annotations" or "meta data" on an IMAP server. The 180 annotations can be associated with specific mailboxes or the server 181 as a whole. 183 The METADATA extension adds two new commands and one new untagged 184 response to the IMAP base protocol. It adds one new LISTEXT 185 "selection" [I-D.ietf-imapext-list-extensions] option type and one 186 new LISTEXT "return" [I-D.ietf-imapext-list-extensions] option type. 188 This extension makes the following changes to the IMAP protocol: 190 adds a new SETMETADATA command 191 adds a new GETMETADATA command 192 adds a new METADATA untagged response 193 adds a new METADATA response code 194 adds a new METADATA LISTEXT selection option type 195 adds a new METADATA LISTEXT return option typer 197 The data model used in METADATA is exactly the same as that used in 198 the ANNOTATE [I-D.ietf-imapext-annotate] extension to IMAP. This is 199 modeled after that of the Application Configuration Access Protocol 200 [RFC2244] with the exception of inheritance which is not deemed 201 necessary here. 203 The rest of this document describes the data model and protocol 204 changes more rigorously. 206 2. Conventions Used in This Document 208 In examples, "C:" and "S:" indicate lines sent by the client and 209 server respectively. 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 3. Data Model 216 3.1. Overview 218 The data model used in METADATA is one of a uniquely named entry with 219 a set of uniquely named attributes, each of which has a value. 220 Annotations can be added to mailboxes when a mailbox name is provided 221 as the first argument to the new commands, or to the server as a 222 whole when the empty string is provided as the first argument to the 223 new commands. 225 An annotation can contain multiple named entries. For example, a 226 general comment being added to a mailbox may have an entry name of 227 "/comment". This entry could include named attributes such as 228 "value" and "size" etc to represent properties and data associated 229 with the entry. 231 The protocol changes to IMAP described below allow a client to access 232 or change the values of any attributes in any entries in an 233 annotation, assuming it has sufficient access rights to do so. 235 3.2. Namespace of entries and attributes 237 Each annotation is made up of a set of entries. Each entry has a 238 hierarchical name, with each component of the name separated by a 239 slash ("/"). An entry name MUST NOT contain two consecutive "/" 240 characters and MUST NOT end with a "/" character. 242 Each entry is made up of a set of attributes. Each attribute has a 243 hierarchical name, with each component of the name separated by a 244 period ("."). An attribute name MUST NOT contain two consecutive "." 245 characters and MUST NOT end with a "." character. 247 The value of an attribute is NIL (has no value), or a string of zero 248 or more octets. 250 Entry and attribute names MUST NOT contain asterisk ("*") or percent 251 ("%") characters and MUST NOT contain non-ASCII characters or the 252 NULL octet. Invalid entry or attribute names result in a BAD 253 response in any IMAP commands where they are used. 255 Attribute names MUST NOT contain any hierarchical components with the 256 names "priv" or "shared" as those have special meaning (see 257 Section 3.3). 259 Entry and attribute names are case-sensitive. 261 Use of control or punctuation characters in entry and attribute names 262 is strongly discouraged. 264 This specification defines an initial set of entry and attribute 265 names available for use with mailbox and server annotations. In 266 addition an extension mechanism is described to allow additional 267 names to be added for extensibility. 269 3.2.1. Entry Names 271 Entry names MUST be specified in a standards track or IESG approved 272 experimental RFC, or fall under the vendor namespace. See 273 Section 6.1 for the registration template. 275 3.2.1.1. Server Entries 277 These entries are used when the mailbox name argument to the new 278 SETMATADATA command is the empty string or with the new GETMETADATA 279 command. 281 /comment 282 Defines a comment or note associated with the server. 284 /motd 285 Defines a "message of the day" for the server. This entry is 286 always read-only - clients cannot change it. 288 /admin 289 Indicates a method for contacting the server administrator. This 290 may be a URI (e.g. a mailto URL) or other contact information, 291 such as a telephone number. This entry is always read-only - 292 clients cannot change it. 294 /vendor/ 295 Defines the top-level of entries associated with the server as 296 created by a particular product of some vendor. This entry can be 297 used by vendors to provide server or client specific annotations. 298 The vendor-token MUST be registered with IANA, using the ACAP 299 [RFC2244] vendor subtree registry. 301 3.2.1.2. Mailbox Entries 303 These entries are used when the mailbox name argument to the new 304 SETMETADATA command is not the empty string, or with the new LISTEXT 305 selection option type. 307 /comment 308 Defines a comment or note associated with a mailbox. 310 /sort 311 Defines the default sort criteria [I-D.ietf-imapext-sort] to use 312 when first displaying the mailbox contents to the user, or NIL if 313 sorting is not required. 315 /thread 316 Defines the default thread criteria [I-D.ietf-imapext-sort] to use 317 when first displaying the mailbox contents to the user, or NIL if 318 threading is not required. If both sort and thread are not NIL, 319 then threading should take precedence over sorting. 321 /check 322 Boolean value "true" or "false" that indicates whether this 323 mailbox should be checked at regular intervals by the client. The 324 interval in minutes is specified by the /checkperiod entry. 326 /checkperiod 327 Numeric value indicating a period of minutes that the client uses 328 to determine the interval of regular 'new mail' checks for the 329 corresponding mailbox. 331 /vendor/ 332 Defines the top-level of entries associated with a specific 333 mailbox as created by a particular product of some vendor. This 334 entry can be used by vendors to provide client specific 335 annotations. The vendor-token MUST be registered with IANA, using 336 the ACAP [RFC2244] vendor subtree registry. 338 3.2.2. Attribute Names 340 Attribute names MUST be specified in a standards track or IESG 341 approved experimental RFC. See Section 6.1 for the registration 342 template. 344 All attribute names implicitly have a ".priv" and a ".shared" suffix 345 which maps to private and shared versions of the entry. Retrieving 346 an annotation without using either suffix includes both. The client 347 MUST specify either a ".priv" or ".shared" suffix when setting an 348 annotation. 350 value 351 A string or binary data representing the value of the annotation. 352 To delete an annotation, the client can store "NIL" into the 353 value. The content represented by the string is determined by the 354 Content-Type used to register the entry (see Section 6.1 for entry 355 registration templates). Where applicable, the registered 356 Content-Type MUST include a charset parameter. Text values SHOULD 357 use the utf-8 [RFC3629] character set. 359 Note that binary data (data which may contain the NULL octet) is 360 allowed (e.g. for storing images etc), and this extension uses the 361 "literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow 362 such data to be written to or read from the server. 364 size 365 The size of the value, in octets. Set automatically by the 366 server, read-only to clients. 368 3.3. Private versus Shared and Access Control 370 As discussed in the ANNOTATE [I-D.ietf-imapext-annotate] extension 371 there is a need to support both private and shared annotations. This 372 document adopts the scheme used in [I-D.ietf-imapext-annotate] that 373 adds two standard suffixes for all attributes: ".shared" and ".priv". 374 A GETMETADATA or extended LIST command which specifies neither uses 375 both. SETMETADATA commands MUST explicitly use .priv or .shared 376 suffixes. 378 A user can only set and retrieve private or shared annotations on a 379 mailbox which is returned to them via a LIST or LSUB command, 380 irrespective of whether they have read or write access to the actual 381 message content of the mailbox. If the client attempts to set or 382 retrieve annotations on other mailboxes, the server MUST respond with 383 a NO response. 385 If the METADATA extension is present, support for shared annotations 386 is REQUIRED, whilst support for private annotations is OPTIONAL. 387 This recognises the fact that support for private annotations may 388 introduce significantly more complexity to a server in terms of 389 tracking ownership of the annotations, how quota is determined for 390 users based on their own annotations etc. Clients that support the 391 METADATA extension MUST handle both shared and private annotations. 393 4. IMAP Protocol Changes 395 4.1. General Considerations 397 The new SETMETADATA command and the METADATA response each have a 398 mailbox name argument, indicating that the annotations being referred 399 to are attached to the specified mailbox. An empty string can be 400 used for the mailbox name to signify server annotations. 402 Both "*" and "%" list wildcard characters MAY be used in the mailbox 403 name argument in the SETMETADATA command to match all possible 404 occurrences of a mailbox name pattern. However, "*" or "%" by 405 themselves MUST NOT match the empty string (server) entries. Server 406 entries can only be accessed by explicitly using the empty string as 407 the mailbox name. 409 Servers SHOULD ensure that mailbox annotations are automatically 410 moved when the mailbox they refer to is renamed, i.e. the annotations 411 follow the mailbox. Servers SHOULD delete annotations for a mailbox 412 when the mailbox is deleted, so that a mailbox created with the same 413 name as a previously existing mailbox does not inherit the old 414 mailbox annotations. Servers SHOULD allow annotations on all 'types' 415 of mailbox, including ones reporting \Noselect for their LIST 416 response. Servers can implicitly remove \Noselect mailboxes when all 417 child mailboxes are removed, and as such any annotations associated 418 with the \Noselect mailbox SHOULD be removed. 420 The server is allowed to impose limitations on the size of any one 421 annotation or the total number of annotations for a single mailbox or 422 for the server as a whole. However, the server MUST accept a minimum 423 annotation data size of at least 1024 bytes, and a minimum annotation 424 count per server or mailbox of at least 10. 426 4.2. GETMETADATA Command 428 This extension adds the GETMETADATA command. This allows clients to 429 retrieve server annotations. Mailbox annotations are retrieved via 430 the extended LIST command described in the next section. 432 This command is only available in authenticated or selected state 433 [RFC3501]. 435 Arguments: entry-specifier 436 attribute-specifier 438 Responses: required METADATA response 440 Result: OK - command completed 441 NO - command failure: can't access annotations on 442 the server 443 BAD - command unknown or arguments invalid 445 Example: 447 C: a GETMETADATA /comment value.priv 448 S: * METADATA /comment (value.priv "My comment") 449 S: a OK GETMETADATA complete 451 In the above example, the contents of the "value.priv" attribute 452 for the "/comment" server entry is requested by the client and 453 returned by the server. 455 "*" and "%" wildcard characters can be used in the entry specifier to 456 match one or more characters at that position, with the exception 457 that "%" does not match the "/" hierarchy delimiter. Thus an entry 458 specifier of "/%" would match entries such as "/comment" and 459 "/version", but not "/comment/note". 461 Example: 463 C: a GETMETADATA /* value.priv 464 S: * METADATA /comment (value.priv "My comment") 465 /version (value.priv "1.1") 466 /motd/today (value.priv "Closed at 1 pm") 467 S: a OK GETMETADATA complete 469 In the above example, the contents of the "value.priv" attributes 470 for any server entries are requested by the client and returned by 471 the server. 473 Example: 475 C: a GETMETADATA /% value 476 S: * METADATA /comment (value.priv "My comment") 477 (value.shared "Your comment") 478 /motd (value.priv "Its sunny outside!" 479 (value.shared "Today is a Holiday") 480 S: a OK GETMETADATA complete 482 In the above example, the contents of the "value" attributes for 483 server entries at the top level of the entry hierarchy only, are 484 requested by the client and returned by the server. Both the 485 .priv and .shared values are returned, as neither were explicitly 486 requested. 488 Entry and attribute specifiers can be lists of atomic specifiers, so 489 that multiple items of each type may be returned in a single 490 GETMETADATA command. 492 Example: 494 C: a GETMETADATA (/comment /motd) value.priv 495 S: * METADATA /comment (value.priv "My comment") 496 /motd (value.priv "Its sunny outside!") 497 S: a OK GETMETADATA complete 499 In the above example, the contents of the "value.priv" attributes 500 for the two server entries "/comment" and "/motd" are requested by 501 the client and returned by the server. 503 Example: 505 C: a GETMETADATA /comment (value.priv 506 size.priv) 507 S: * METADATA /comment (value.priv "My comment" 508 size.priv "1234") 509 S: a OK GETMETADATA complete 511 In the above example, the contents of the "value.priv" and 512 "size.priv" attributes for the "/comment" server entry are 513 requested by the client and returned by the server. 515 4.3. Extended LIST Command Extensions 517 This extension adds the METADATA LIST command selection and return 518 option types, extending the LISTEXT extension. This allows clients 519 to retrieve mailbox annotations. 521 The LISTEXT "METADATA" selection option type is used to request that 522 the extended LIST command match mailboxes which have an annotation 523 with a specific entry and value. It can also be used to test for the 524 existence of a particular annotation entry on a mailbox. This 525 selection option takes one or more entry/attribute/value triples to 526 use as tests. A mailbox matches this criteria if it has an entry, 527 attribute and value matching the ones specified. In the case of 528 multiple criteria being specified, mailbox MUST only match when all 529 criteria match ("and" operation). To test for the existence of an 530 entry, a test for the attribute "value" with the empty string "" as 531 the value argument can be used. To test for the absence of an entry, 532 a test for the attribute "value" with NIL as the value argument can 533 be used. If the COMPARATOR [I-D.ietf-imapext-i18n] extension is 534 present, then the active comparator MUST be used when doing text 535 comparisons of the value. Clients SHOULD only use entries defined 536 with a "text" Content-Type in the selection option arguments. 538 The LISTEXT "METADATA" return option type is used to request that the 539 extended LIST command return specific annotation entries for each 540 mailbox returned in the LIST responses. A list of entries and 541 attributes to return can be specified in a manner similar to the 542 GETMETADATA command. 544 Example: 546 C: a LIST "" "INBOX" RETURN (METADATA /comment value.priv) 547 S: * LIST (\metadata /comment (value.priv "My comment")) 548 "/" "INBOX" 549 S: a OK LIST complete 551 In the above example, the contents of the "value.priv" attribute 552 for the "/comment" entry for the mailbox INBOX is requested by the 553 client and returned by the server. 555 "*" and "%" wildcard characters can be used in the entry specifier to 556 match one or more characters at that position, with the exception 557 that "%" does not match the "/" hierarchy delimiter. Thus an entry 558 specifier of "/%" would match entries such as "/comment" and 559 "/version", but not "/comment/note". 561 Example: 563 C: a LIST "" "INBOX" RETURN (METADATA /* value.priv) 564 S: * LIST (\metadata /comment (value.priv "My comment") 565 /version (value.priv "1.1") 566 /motd/today (value.priv "Closed at 1 pm")) 567 "/" "INBOX" 568 S: a OK LIST complete 570 In the above example, the contents of the "value.priv" attributes 571 for any entries for the mailbox INBOX are requested by the client 572 and returned by the server. 574 Example: 576 C: a LIST "" "INBOX" RETURN (METADATA /% value) 577 S: * LIST (\metadata /comment (value.priv "My comment") 578 (value.shared "Your comment") 579 /motd (value.priv "Its sunny outside!" 580 (value.shared "Today is a Holiday")) 581 "/" "INBOX" 582 S: a OK LIST complete 584 In the above example, the contents of the "value" attributes for 585 entries for the mailbox INBOX at the top level of the entry 586 hierarchy only, are requested by the client and returned by the 587 server. Both the .priv and .shared values are returned, as 588 neither were explicitly requested. 590 Entry and attribute specifiers can be lists of atomic specifiers, so 591 that multiple items of each type may be returned in a single LIST 592 command. 594 Example: 596 C: a LIST "" "INBOX" RETURN (METADATA (/comment /motd) 597 value.priv) 598 S: * LIST (\metadata /comment (value.priv "My comment") 599 /motd (value.priv "Its sunny outside!")) 600 "/" "INBOX" 601 S: a OK LIST complete 603 In the above example, the contents of the "value.priv" attributes 604 for the two entries "/comment" and "/motd" for the mailbox INBOX 605 are requested by the client and returned by the server. 607 Example: 609 C: a LIST "" "INBOX" RETURN (METADATA /comment 610 (value.priv size.priv)) 611 S: * LIST (\metadata /comment (value.priv "My comment" 612 size.priv "1234")) 613 "/" "INBOX" 614 S: a OK LIST complete 616 In the above example, the contents of the "value.priv" and 617 "size.priv" attributes for the "/comment" entry for the mailbox 618 INBOX are requested by the client and returned by the server. 620 Example: 622 C: a LIST "" ("INBOX" "FOOBOX" "BARBOX") RETURN 623 (METADATA /comment value.priv) 624 S: * LIST (\metadata /comment (value.priv "My comment")) 625 "/" "INBOX" 626 S: * LIST (\metadata /comment (value.priv "Another comment")) 627 "/" "FOOBOX" 628 S: * LIST (\metadata /comment (value.priv NIL)) 629 "/" "BARBOX" 630 S: a OK LIST complete 632 In the above example, the contents of the "value.priv" attribute 633 for the "/comment" entry for the mailboxes INBOX, FOOBOX and 634 BARBOX are requested by the client and returned by the server. 635 Note that the mailbox BARBOX does not contain the entry, hence NIL 636 is returned for the attribute value. 638 Example: 640 C: a LIST (METADATA ("/comment" "value" "comm") 641 "" "*" 642 S: * LIST () "/" "INBOX" 643 S: * LIST (\NoInferiors) "/" "FOOBOX" 644 S: a OK LIST complete 646 In the above example, the client requests that any mailbox in the 647 entire hierarchy containing the text "comm" in any "value" 648 attribute of the "/comment" entry be returned. Two mailboxes are 649 returned in separate responses. Note that the client did not ask 650 for annotations to be returned in the responses. 652 Example: 654 C: a LIST (METADATA ("/comment" "value" "") 655 "" "*" 656 S: * LIST () "/" "INBOX" 657 S: * LIST (\NoInferiors) "/" "FOOBOX" 658 S: a OK LIST complete 660 In the above example, the client requests that any mailbox in the 661 entire hierarchy containing the "/comment" entry be returned. Two 662 mailboxes are returned in separate responses. Note that the 663 client did not ask for annotations to be returned in the 664 responses. 666 Example: 668 C: a LIST (METADATA ("/comment" "value" NIL) 669 "" "*" 670 S: * LIST (\NoInferiors) "/" "BARBOX" 671 S: a OK LIST complete 673 In the above example, the client requests that any mailbox in the 674 entire hierarchy that does not have a "/comment" entry be 675 returned. One mailbox is returned in a response. Note that the 676 client did not ask for annotations to be returned in the 677 responses. 679 Example: 681 C: a LIST (METADATA ("/comment" "value" "comm") 682 "" "*" RETURN (METADATA /comment size.priv) 683 S: * LIST (\metadata /comment (size.priv "10")) 684 "/" "INBOX" 685 S: * LIST (\metadata /comment (size.priv "15")) 686 "/" "FOOBOX" 687 S: a OK LIST complete 689 In the above example, the client requests that any mailbox in the 690 entire hierarchy containing the text "comm" in any "value" 691 attribute of the "/comment" entry be returned. Two mailboxes are 692 returned in separate responses. The client also asked for 693 annotations to be returned in the responses. 695 4.3.1. Unsolicited LIST repsonse 697 Servers SHOULD send unsolicited LIST responses if mailbox annotations 698 are changed by a third-party, allowing servers to keep clients 699 updated with changes. Unsolicited mailbox annotations MUST only be 700 returned for the currently selected mailbox. 702 Unsolicited LIST responses MUST only contain entry names, not the 703 attributes and values. If the client wants to update any cached 704 values it must explicitly retrieve those using a LIST command. 706 The LIST response can contain multiple entries in a single response, 707 but the server is free to return multiple responses for each entry or 708 group of entries if it desires. 710 Example: 712 C: a NOOP 713 S: * LIST (\metadata /comment) "/" "INBOX" 714 S: a OK NOOP complete 716 In the above example, the server sends an unsolicited LIST 717 response indicating that the "/comment" entry of the mailbox 718 "INBOX" has been changed. 720 4.4. SETMETADATA Command 722 This extension adds the SETMETADATA command. This allows clients to 723 set annotations. 725 This command is only available in authenticated or selected state 726 [RFC3501]. 728 Arguments: mailbox-name 729 entry 730 attribute-value 731 list of entry, attribute-values 733 Responses: no specific responses for this command 735 Result: OK - command completed 736 NO - command failure: can't set annotations, 737 or annotation too big or too many 738 BAD - command unknown or arguments invalid 740 This command sets the specified list of entries by adding or 741 replacing the specified attributes with the values provided. Clients 742 can use NIL for values of attributes it wants to remove from entries. 743 The server MAY return a METADATA response containing the updated 744 annotation data. Clients MUST NOT assume that a METADATA response 745 will be sent, and MUST assume that if the command succeeds then the 746 annotation has been changed. 748 If the server is unable to set an annotation because the size of its 749 value is too large, the server MUST return a tagged NO response with 750 a "[METADATA TOOBIG]" response code. 752 If the server is unable to set a new annotation because the maximum 753 number of allowed annotations has already been reached, the server 754 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 755 code. 757 If the server is unable to set a new annotation because it does not 758 support private annotations on one of the specified mailboxes, the 759 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 760 response code. 762 If the server is unable to set the annotations for one or more 763 mailboxes matching the mailbox-name pattern, then the SETMETADATA 764 command MUST fail and there MUST NOT be any changes to any of the 765 matching mailboxes, even those for which annotations could have been 766 changed successfully. 768 Example: 770 C: a SETMETADATA INBOX /comment 771 (value.priv "My new comment") 772 S: a OK SETMETADATA complete 774 In the above example, the entry "/comment" for the mailbox "INBOX" 775 is created (if not already present) and the private attribute 776 "value" with data set to "My new comment" is created if not 777 already present, or replaced if it previously exists. 779 Example: 781 C: a SETMETADATA INBOX /comment (value.priv NIL) 782 S: a OK SETMETADATA complete 784 In the above example, the private "value" attribute of the entry 785 "/comment" is removed from the mailbox "INBOX". 787 Annotations on multiple mailboxes can be set in a single SETMETADATA 788 command by using a wildcard specification for the mailbox name. 790 Example: 792 C: a SETMETADATA INBOX.% /comment 793 (value.priv "My new comment") 794 S: a OK SETMETADATA complete 796 In the above example, the entry "/comment" for all mailboxes at 797 the top-level of the "INBOX" hierarchy are created (if not already 798 present) and the private attribute "value" are created 799 respectively for each entry if not already present, or replaced if 800 they previously existed. 802 Multiple entries can be set in a single SETMETADATA command by 803 listing entry-attribute-value pairs in the list. 805 Example: 807 C: a SETMETADATA INBOX (/comment 808 (value.priv "My new comment") 809 /thread 810 (value.priv "REFERENCES ALL")) 811 S: a OK SETMETADATA complete 813 In the above example, the entries "/comment" and "/thread" for the 814 mailbox "INBOX" are created (if not already present) and the 815 "value.priv" attributes are created respectively for each entry if 816 not already present, or replaced if they previously existed. 818 Multiple attributes can be set in a single SETMETADATA command by 819 listing multiple attribute-value pairs in the entry list. 821 Example: 823 C: a SETMETADATA INBOX /comment 824 (value.priv "My new comment" 825 value.shared "foo's bar") 826 S: a OK SETMETADATA complete 828 In the above example, the entry "/comment" for the mailbox "INBOX" 829 is created (if not already present) and the attributes 830 "value.priv" and "value.shared" are created if not already 831 present, or replaced if they previously existed. 833 Example: 835 C: a SETMETADATA INBOX /comment 836 (value.priv "My new comment") 837 S: a NO [METADATA TOOMANY] SETMETADATA failed 839 In the above example, the server is unable to set the requested 840 (new) annotation as it has reached the limit on the number of 841 annotations it can support on the specified mailbox. 843 4.5. METADATA Response 845 The METADATA response displays results of a GETMETADATA command, or 846 can be returned as an unsolicited response at anytime by the server 847 in response to a change in a server annotation. 849 Servers SHOULD send unsolicited METADATA responses if server 850 annotations are changed by a third-party, allowing servers to keep 851 clients updated with changes. 853 Unsolicited METADATA responses MUST only contain entry names, not the 854 attributes and values. If the client wants to update any cached 855 values it must explicitly retrieve those using a GETMETADATA command. 857 The METADATA response can contain multiple entries in a single 858 response, but the server is free to return multiple responses for 859 each entry or group of entries if it desires. 861 This response is only available in authenticated or selected state 862 [RFC3501]. 864 4.5.1. METADATA response with attributes and values 866 The response consists of a list of entries each of which has a list 867 of attribute-value pairs. 869 Example: 871 C: a GETMETADATA /comment value.priv 872 S: * METADATA /comment (value.priv "My comment") 873 S: a OK GETMETADATA complete 875 In the above example, a single entry with a single attribute-value 876 pair is returned by the server. 878 Example: 880 C: a GETMETADATA (/comment /motd) value.priv 881 S: * METADATA /comment (value.priv "My comment") 882 /motd (value.priv "Its sunny outside!") 884 S: a OK GETMETADATA complete 886 In the above example, two entries each with a single attribute- 887 value pair is returned by the server. 889 Example: 891 C: a GETMETADATA (/comment /motd) value.priv 892 S: * METADATA /comment (value.priv "My comment") 893 S: * METADATA /motd (value.priv "Its sunny outside!") 894 S: a OK GETMETADATA complete 896 In the above example, the server returns two separate responses 897 for each of the two entries requested. 899 Example: 901 C: a GETMETADATA /comment (value.priv size.priv) 902 S: * METADATA /comment (value.priv "My comment" 903 size.priv "10") 904 S: a OK GETMETADATA complete 906 In the above example, a single entry with two attribute-value 907 pairs is returned by the server. 909 4.5.2. Unsolicited METADATA response without attributes and values 911 The response consists of a parenthesised list of entries, each of 912 which have changed on the server. 914 Example: 916 C: a NOOP 917 S: * METADATA (/comment) 918 S: a OK NOOP complete 920 In the above example, the server indicates that the "/comment" 921 server entry has been changed. 923 Example: 925 C: a NOOP 926 S: * METADATA (/comment /motd) 927 S: a OK NOOP complete 929 In the above example, the server indicates a change to two server 930 entries. 932 5. Formal Syntax 934 The following syntax specification uses the Augmented Backus-Naur 935 Form (ABNF) notation as specified in [RFC2234]. 937 Non-terminals referenced but not defined below are as defined by 938 [RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf] 939 superseding those in [RFC3501]. 941 Except as noted otherwise, all alphabetic characters are case- 942 insensitive. The use of upper or lower case characters to define 943 token strings is for editorial clarity only. Implementations MUST 944 accept these strings in a case-insensitive fashion. 946 annotate-data = "METADATA" SP entry-list 948 att-select = "value" / "value.priv" / "value.shared" 949 ; the only attributes that can be selected 951 att-value = attrib SP value 953 attrib = astring 954 ; dot-separated attribute name 955 ; MUST NOT contain "*" or "%" 957 attribs = attrib / "(" attrib *(SP attrib) ")" 958 ; one or more attribute specifiers 960 capability =/ "METADATA" 961 ; defines the capability for this extension 963 command-auth =/ setmetadata / getmetadata 964 ; adds to original IMAP command 966 entries = entry-match / 967 "(" entry-match *(SP entry-match) ")" 968 ; entry specifiers that can include wildcards 970 entry = astring 971 ; slash-separated path to entry 972 ; MUST NOT contain "*" or "%" 974 entry-att = entry SP "(" att-value *(SP att-value) ")" 976 entry-list = entry-att *(SP entry-att) / 977 "(" entry *(SP entry) ")" 978 ; entry attribute-value pairs list for 979 ; GETMETADATA response, or 980 ; parenthesised entry list for unsolicited 981 ; notification of annotation changes 983 entry-match = list-mailbox 984 ; slash-separated path to entry 985 ; MAY contain "*" or "%" for use as wildcards 987 getmetadata = "GETMETADATA" SP entries SP attribs 989 list-select-base-opt =/ "METADATA" SP 990 "(" list-select-metadata 991 *(SP list-select-metadata) ")" 992 ; adds a new selection option type to 993 ; LISTEXT. When evaluating multiple entry, 994 ; attribute, value combinations, a match to 995 ; a mailbox must occur when all items match. 997 list-select-metadata = entry-match SP att-select SP value 998 ; value set to the empty string means match 999 ; if that entry and attribute exist. 1000 ; value set to NIL means match if that entry 1001 ; and attribute do not exist. 1003 response-payload =/ annotate-data 1004 ; adds to original IMAP data responses 1006 resp-text-code =/ "METADATA" SP ("TOOBIG" / "TOOMANY" / 1007 "NOPRIVATE") 1008 ; new response codes for SETMETADATA 1009 ; failures 1011 setmetadata = "SETMETADATA" SP list-mailbox 1012 SP setentryatt 1013 ; empty string for list-mailbox implies 1014 ; server annotation. 1016 setentryatt = entry-att / "(" entry-att *(SP entry-att) ")" 1018 value = nstring / literal8 1020 6. IANA Considerations 1022 Entry names MUST be specified in a standards track or IESG approved 1023 experimental RFC, or fall under the vendor namespace. Attribute 1024 names MUST be specified in a standards track or IESG approved 1025 experimental RFC. 1027 Each entry registration MUST include a content-type that is used to 1028 indicate the nature of the annotation value. Where applicable a 1029 charset parameter MUST be included with the content-type. 1031 6.1. Entry and Attribute Registration Template 1033 To: iana@iana.org 1034 Subject: IMAP METADATA Registration 1036 Please register the following IMAP METADATA item: 1038 [ ] Entry [ ] Attribute 1040 [ ] Mailbox [ ] Server 1042 Name: ______________________________ 1044 Description: _______________________ 1046 ____________________________________ 1048 ____________________________________ 1050 Content-type: ____________________ 1052 Contact person: ____________________ 1054 email: ____________________ 1056 6.2. Server Entry Registrations 1058 The following templates specify the IANA registrations of annotation 1059 entries specified in this document. 1061 6.2.1. /comment 1063 To: iana@iana.org 1064 Subject: IMAP METADATA Registration 1066 Please register the following IMAP METADATA item: 1068 [x] Entry [ ] Attribute 1070 [ ] Mailbox [x] Server 1072 Name: /comment 1074 Description: Defined in IMAP METADATA extension document. 1076 Content-type: text/plain; charset=utf-8 1078 Contact person: Cyrus Daboo 1080 email: cyrus@daboo.name 1082 6.2.2. /motd 1084 To: iana@iana.org 1085 Subject: IMAP METADATA Registration 1087 Please register the following IMAP METADATA item: 1089 [x] Entry [ ] Attribute 1091 [ ] Mailbox [x] Server 1093 Name: /motd 1095 Description: Defined in IMAP METADATA extension document. 1097 Content-type: text/plain; charset=utf-8 1099 Contact person: Cyrus Daboo 1101 email: cyrus@daboo.name 1103 6.2.3. /admin 1105 To: iana@iana.org 1106 Subject: IMAP METADATA Registration 1108 Please register the following IMAP METADATA item: 1110 [x] Entry [ ] Attribute 1112 [ ] Mailbox [x] Server 1114 Name: /admin 1116 Description: Defined in IMAP METADATA extension document. 1118 Content-type: text/plain; charset=utf-8 1120 Contact person: Cyrus Daboo 1122 email: cyrus@daboo.name 1124 6.3. Mailbox Entry Registrations 1126 The following templates specify the IANA registrations of annotation 1127 entries specified in this document. 1129 6.3.1. /comment 1131 To: iana@iana.org 1132 Subject: IMAP METADATA Registration 1134 Please register the following IMAP METADATA item: 1136 [x] Entry [ ] Attribute 1138 [x] Mailbox [ ] Server 1140 Name: /comment 1142 Description: Defined in IMAP METADATA extension document. 1144 Content-type: text/plain; charset=utf-8 1146 Contact person: Cyrus Daboo 1148 email: cyrus@daboo.name 1150 6.3.2. /sort 1152 To: iana@iana.org 1153 Subject: IMAP METADATA Registration 1155 Please register the following IMAP METADATA item: 1157 [x] Entry [ ] Attribute 1159 [x] Mailbox [ ] Server 1161 Name: /sort 1163 Description: Defined in IMAP METADATA extension document. 1165 Content-type: text/plain; charset=utf-8 1167 Contact person: Cyrus Daboo 1169 email: cyrus@daboo.name 1171 6.3.3. /thread 1173 To: iana@iana.org 1174 Subject: IMAP METADATA Registration 1176 Please register the following IMAP METADATA item: 1178 [x] Entry [ ] Attribute 1180 [x] Mailbox [ ] Server 1182 Name: /thread 1184 Description: Defined in IMAP METADATA extension document. 1186 Content-type: text/plain; charset=utf-8 1188 Contact person: Cyrus Daboo 1190 email: cyrus@daboo.name 1192 6.3.4. /check 1194 To: iana@iana.org 1195 Subject: IMAP METADATA Registration 1197 Please register the following IMAP METADATA item: 1199 [x] Entry [ ] Attribute 1201 [x] Mailbox [ ] Server 1203 Name: /check 1205 Description: Defined in IMAP METADATA extension document. 1207 Content-type: text/plain; charset=utf-8 1209 Contact person: Cyrus Daboo 1211 email: cyrus@daboo.name 1213 6.3.5. /checkperiod 1215 To: iana@iana.org 1216 Subject: IMAP METADATA Registration 1218 Please register the following IMAP METADATA item: 1220 [x] Entry [ ] Attribute 1222 [x] Mailbox [ ] Server 1224 Name: /checkperiod 1226 Description: Defined in IMAP METADATA extension document. 1228 Content-type: text/plain; charset=utf-8 1230 Contact person: Cyrus Daboo 1232 email: cyrus@daboo.name 1234 6.4. Attribute Registrations 1236 The following templates specify the IANA registrations of annotation 1237 attributes specified in this document. 1239 6.4.1. value 1241 To: iana@iana.org 1242 Subject: IMAP METADATA Registration 1244 Please register the following IMAP METADATA item: 1246 [ ] Entry [x] Attribute 1248 [ ] Mailbox [ ] Server 1250 Name: value 1252 Description: Defined in IMAP METADATA extension document. 1254 Content-type: - 1256 Contact person: Cyrus Daboo 1258 email: cyrus@daboo.name 1260 6.4.2. size 1262 To: iana@iana.org 1263 Subject: IMAP METADATA Registration 1265 Please register the following IMAP METADATA item: 1267 [ ] Entry [x] Attribute 1269 [ ] Mailbox [ ] Server 1271 Name: size 1273 Description: Defined in IMAP METADATA extension document. 1275 Content-type: - 1277 Contact person: Cyrus Daboo 1279 email: cyrus@daboo.name 1281 7. Security Considerations 1283 Annotations whose values are intended to remain private MUST use 1284 .priv values, and not .shared values which may be accessible to other 1285 users. 1287 Excluding the above issues the METADATA extension does not raise any 1288 security considerations that are not present in the base IMAP 1289 protocol, and these issues are discussed in [RFC3501]. 1291 8. References 1293 8.1. Normative References 1295 [I-D.ietf-imapext-i18n] 1296 Newman, C., "Internet Message Access Protocol 1297 Internationalization", draft-ietf-imapext-i18n-06 (work in 1298 progress), March 2006. 1300 [I-D.ietf-imapext-list-extensions] 1301 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 1302 Extensions", draft-ietf-imapext-list-extensions-16 (work 1303 in progress), March 2006. 1305 [I-D.ietf-imapext-sort] 1306 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1307 PROTOCOL - SORT AND THREAD EXTENSION", 1308 draft-ietf-imapext-sort-17 (work in progress), May 2004. 1310 [I-D.melnikov-imap-ext-abnf] 1311 Daboo, C. and A. Melnikov, "Collected extensions to IMAP4 1312 ABNF", draft-melnikov-imap-ext-abnf-08 (work in progress), 1313 January 2006. 1315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1316 Requirement Levels", BCP 14, RFC 2119, March 1997. 1318 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1319 Specifications: ABNF", RFC 2234, November 1997. 1321 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1322 Configuration Access Protocol", RFC 2244, November 1997. 1324 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1325 4rev1", RFC 3501, March 2003. 1327 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1328 10646", STD 63, RFC 3629, November 2003. 1330 8.2. Informative References 1332 [I-D.ietf-imapext-annotate] 1333 Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", 1334 draft-ietf-imapext-annotate-15 (work in progress), 1335 March 2006. 1337 Appendix A. Acknowledgments 1339 The ideas expressed in this document are based on the message 1340 annotation document that was co-authored by Randall Gellens. The 1341 participants of the IMAPext working group made significant 1342 contributions to this work. 1344 Author's Address 1346 Cyrus Daboo 1348 Email: cyrus@daboo.name 1350 Intellectual Property Statement 1352 The IETF takes no position regarding the validity or scope of any 1353 Intellectual Property Rights or other rights that might be claimed to 1354 pertain to the implementation or use of the technology described in 1355 this document or the extent to which any license under such rights 1356 might or might not be available; nor does it represent that it has 1357 made any independent effort to identify any such rights. Information 1358 on the procedures with respect to rights in RFC documents can be 1359 found in BCP 78 and BCP 79. 1361 Copies of IPR disclosures made to the IETF Secretariat and any 1362 assurances of licenses to be made available, or the result of an 1363 attempt made to obtain a general license or permission for the use of 1364 such proprietary rights by implementers or users of this 1365 specification can be obtained from the IETF on-line IPR repository at 1366 http://www.ietf.org/ipr. 1368 The IETF invites any interested party to bring to its attention any 1369 copyrights, patents or patent applications, or other proprietary 1370 rights that may cover technology that may be required to implement 1371 this standard. Please address the information to the IETF at 1372 ietf-ipr@ietf.org. 1374 Disclaimer of Validity 1376 This document and the information contained herein are provided on an 1377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1384 Copyright Statement 1386 Copyright (C) The Internet Society (2006). This document is subject 1387 to the rights, licenses and restrictions contained in BCP 78, and 1388 except as set forth therein, the authors retain all their rights. 1390 Acknowledgment 1392 Funding for the RFC Editor function is currently provided by the 1393 Internet Society.