idnits 2.17.1 draft-daboo-imap-annotatemore-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1404. ** 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 issues found here. 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 (October 19, 2006) is 6391 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'METADATA TOOMANY' is mentioned on line 847, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-imapext-i18n-06 == 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 (~~), 5 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 Apple Computer 4 Intended status: Informational October 19, 2006 5 Expires: April 22, 2007 7 IMAP METADATA Extension 8 draft-daboo-imap-annotatemore-10 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 22, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The METADATA extension to the Internet Message Access Protocol 42 permits clients and servers to maintain "annotations" or "meta data" 43 on IMAP servers. It is possible to have annotations on a per-mailbox 44 basis or on the server as a whole. For example, this would allow 45 comments about the purpose of a particular mailbox to be "attached" 46 to that mailbox, or a "message of the day" containing server status 47 information to be made available to anyone logging in to the server. 49 Change History (to be removed prior to publication as an RFC) 51 Changes from -09 to -10: 52 1. Updated to rfc 4466 reference. 53 2. Reworded data model description. 54 3. Reworked LISTEXT so that responses have metadata items after the 55 mailbox info. 56 4. Various spelling fixes. 58 Changes from -08 to -09: 59 1. Remove content-language attribute and reference. 60 2. Changed capability and command names. 61 3. Revised abstract. 63 Changes from -07 to -08: 64 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' 65 for entry/attribute names. 66 2. Updated examples to match new astring syntax. 67 3. Changed CAPABILITY name due to incompatible syntax change. 68 4. Removed content-type attribute. 69 5. Added Content-type to IANA registration for entries. 70 6. Removed vendor attributes. 71 7. Fixed examples in section 3.3 for multi-mailbox and multi-entry 72 cases. 73 8. Removed wildcards for attributes. 74 9. Entry/attributes can now only be ASCII. 75 10. Tied up text wrt storing/fetching. 76 11. Added Conventions section 77 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or 78 '.'. 79 13. Changed to use IMAP ABNF extensions document for some formal 80 syntax items. 82 Changes from -06 to -07: 83 1. Reworded /checkperiod item. 84 2. Clarified unsolicited response behavior. 86 Changes from -05 to -06: 87 1. Removed 'modifiedsince' attribute as there is currently no use 88 for it. 89 2. Added content-language attribute. 90 3. Changed access to allow .priv and .shared on any mailbox returned 91 by LIST/LSUB. 92 4. Added IANA registrations for items defined in this document. 93 5. Added latest IPR statement. 94 6. Updated references. 96 Changes from -04 to -05: 98 1. Fix for valid IMAP state of commands. 99 2. Fix formatting, ID nits etc. 101 Changes from -03 to -04: 102 1. Allow retrieval of shared annotations for READ-ONLY mailbox. 103 2. Clarification of annotation loss on implicit removal of \Noselect 104 mailboxes. 105 3. Now requires roll-back of all changes to matching mailboxes if 106 there is a partial failure in SETANNOTATION. 108 Changes from -02 to -03: 109 1. Reworked entry naming scheme to split out mailbox name and use 110 empty string for server items. 112 Changes from -01 to -02: 113 1. SETANNOTATION lists use (..). 114 2. Explicitly state behavior of unsolicited responses. 115 3. Adding SHOULD behavior for rename/delete of mailboxes. 116 4. Added statement about supporting annotations on \Noselect 117 mailboxes. 118 5. Cleaned up formal syntax to use IMAP string type for entry and 119 attributes, with requirements on how the string is formatted. 120 6. Use of ACAP vendor subtree registry for vendor tokens. 122 Changes from -00 to -01: 123 1. Multiple entry-att responses are now simply delimited by spaces 124 in line with ANNOTATE spec. Adjusted examples to match. 125 2. Fixed entry-list formal syntax item to account for unsolicited 126 parenthesized list of entries. 127 3. Removed setentries formal syntax item for simplicity since its 128 only used once. 129 4. Removed reference to 'message annotation' in section 5.1. 130 5. Changed formal syntax to restrict top level entries to /server 131 and /mailbox/{...} only. Re-arranged entry names section to 132 account for this change. 133 6. Added comment and example for ANNOTATION response to allow 134 servers to return separate responses for each entry if desired. 136 Table of Contents 138 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 139 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 140 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 141 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 142 3.2. Namespace of entries and attributes . . . . . . . . . . . 6 143 3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 7 144 3.2.2. Attribute Names . . . . . . . . . . . . . . . . . . . 8 145 3.3. Private versus Shared and Access Control . . . . . . . . . 9 146 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 9 147 4.1. General Considerations . . . . . . . . . . . . . . . . . . 9 148 4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 10 149 4.3. Extended LIST Command Extensions . . . . . . . . . . . . . 12 150 4.3.1. Unsolicited LIST response . . . . . . . . . . . . . . 16 151 4.4. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 16 152 4.5. METADATA Response . . . . . . . . . . . . . . . . . . . . 19 153 4.5.1. METADATA response with attributes and values . . . . . 19 154 4.5.2. Unsolicited METADATA response without attributes 155 and values . . . . . . . . . . . . . . . . . . . . . . 20 156 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 157 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 158 6.1. Entry and Attribute Registration Template . . . . . . . . 23 159 6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 23 160 6.2.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 24 161 6.2.2. /motd . . . . . . . . . . . . . . . . . . . . . . . . 24 162 6.2.3. /admin . . . . . . . . . . . . . . . . . . . . . . . . 25 163 6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 25 164 6.3.1. /comment . . . . . . . . . . . . . . . . . . . . . . . 25 165 6.3.2. /sort . . . . . . . . . . . . . . . . . . . . . . . . 26 166 6.3.3. /thread . . . . . . . . . . . . . . . . . . . . . . . 26 167 6.3.4. /check . . . . . . . . . . . . . . . . . . . . . . . . 27 168 6.3.5. /checkperiod . . . . . . . . . . . . . . . . . . . . . 27 169 6.4. Attribute Registrations . . . . . . . . . . . . . . . . . 27 170 6.4.1. value . . . . . . . . . . . . . . . . . . . . . . . . 28 171 6.4.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 28 172 6.5. LISTEXT Registration . . . . . . . . . . . . . . . . . . . 28 173 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 174 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 175 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 176 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 177 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 178 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 179 Intellectual Property and Copyright Statements . . . . . . . . . . 31 181 1. Introduction and Overview 183 The METADATA extension is present in any IMAP [RFC3501] 184 implementation which returns "METADATA" as one of the supported 185 capabilities in the CAPABILITY command response. The "LISTEXT" 186 [I-D.ietf-imapext-list-extensions] extension MUST also be present. 188 The goal of METADATA is to provide a means for clients to set and 189 retrieve "annotations" or "meta data" on an IMAP server. The 190 annotations can be associated with specific mailboxes or the server 191 as a whole. 193 The METADATA extension adds two new commands and one new untagged 194 response to the IMAP base protocol. It adds one new LISTEXT 195 "selection" [I-D.ietf-imapext-list-extensions] option type and one 196 new LISTEXT "return" [I-D.ietf-imapext-list-extensions] option type. 198 This extension makes the following changes to the IMAP protocol: 200 o adds a new SETMETADATA command 201 o adds a new GETMETADATA command 202 o adds a new METADATA untagged response 203 o adds a new METADATA response code 204 o adds a new METADATA LISTEXT selection option type 205 o adds a new METADATA LISTEXT return option typer 207 The data model used in METADATA is exactly the same as that used in 208 the ANNOTATE [I-D.ietf-imapext-annotate] extension to IMAP. This is 209 modeled after that of the Application Configuration Access Protocol 210 [RFC2244] with the exception of inheritance which is not deemed 211 necessary here. 213 The rest of this document describes the data model and protocol 214 changes more rigorously. 216 2. Conventions Used in This Document 218 In examples, "C:" and "S:" indicate lines sent by the client and 219 server respectively. 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in [RFC2119]. 225 3. Data Model 227 3.1. Overview 229 Mailboxes or the server as a whole may have zero or more annotations 230 associated with them. An annotation contains a uniquely named entry 231 with a set of uniquely named attributes, each of which has a value. 232 Annotations can be added to mailboxes when a mailbox name is provided 233 as the first argument to the new commands, or to the server as a 234 whole when the empty string is provided as the first argument to the 235 new commands. 237 For example, a general comment being added to a mailbox may have an 238 entry name of "/comment". This entry could include named attributes 239 such as "value" and "size" etc to represent properties and data 240 associated with the entry. 242 The protocol changes to IMAP described below allow a client to access 243 or change the values of any attributes in any entries in an 244 annotation, assuming it has sufficient access rights to do so. 246 3.2. Namespace of entries and attributes 248 Each annotation has an entry that has a hierarchical name, with each 249 component of the name separated by a slash ("/"). An entry name MUST 250 NOT contain two consecutive "/" characters and MUST NOT end with a 251 "/" character. 253 Each entry is made up of a set of attributes. Each attribute has a 254 hierarchical name, with each component of the name separated by a 255 period ("."). An attribute name MUST NOT contain two consecutive "." 256 characters and MUST NOT end with a "." character. 258 The value of an attribute is NIL (has no value), or a string of zero 259 or more octets. 261 Entry and attribute names MUST NOT contain asterisk ("*") or percent 262 ("%") characters and MUST NOT contain non-ASCII characters or the 263 NULL octet. Invalid entry or attribute names result in a BAD 264 response in any IMAP commands where they are used. 266 Attribute names MUST NOT contain any hierarchical components with the 267 names "priv" or "shared" as those have special meaning (see 268 Section 3.3). 270 Entry and attribute names are case-sensitive. 272 Use of control or punctuation characters in entry and attribute names 273 is strongly discouraged. 275 This specification defines an initial set of entry and attribute 276 names available for use with mailbox and server annotations. In 277 addition an extension mechanism is described to allow additional 278 names to be added for extensibility. 280 3.2.1. Entry Names 282 Entry names MUST be specified in a standards track or IESG approved 283 experimental RFC, or fall under the vendor namespace. See 284 Section 6.1 for the registration template. 286 3.2.1.1. Server Entries 288 These entries are used when the mailbox name argument to the new 289 SETMATADATA command is the empty string or with the new GETMETADATA 290 command. 292 /comment 293 Defines a comment or note associated with the server. 295 /motd 296 Defines a "message of the day" for the server. This entry is 297 always read-only - clients cannot change it. 299 /admin 300 Indicates a method for contacting the server administrator. This 301 may be a URI (e.g. a mailto URL) or other contact information, 302 such as a telephone number. This entry is always read-only - 303 clients cannot change it. 305 /vendor/ 306 Defines the top-level of entries associated with the server as 307 created by a particular product of some vendor. This entry can be 308 used by vendors to provide server or client specific annotations. 309 The vendor-token MUST be registered with IANA, using the ACAP 310 [RFC2244] vendor subtree registry. 312 3.2.1.2. Mailbox Entries 314 These entries are used when the mailbox name argument to the new 315 SETMETADATA command is not the empty string, or with the new LISTEXT 316 selection option type. 318 /comment 319 Defines a comment or note associated with a mailbox. 321 /sort 322 Defines the default sort criteria [I-D.ietf-imapext-sort] to use 323 when first displaying the mailbox contents to the user, or NIL if 324 sorting is not required. 326 /thread 327 Defines the default thread criteria [I-D.ietf-imapext-sort] to use 328 when first displaying the mailbox contents to the user, or NIL if 329 threading is not required. If both sort and thread are not NIL, 330 then threading should take precedence over sorting. 332 /check 333 Boolean value "true" or "false" that indicates whether this 334 mailbox should be checked at regular intervals by the client. The 335 interval in minutes is specified by the /checkperiod entry. 337 /checkperiod 338 Numeric value indicating a period of minutes that the client uses 339 to determine the interval of regular 'new mail' checks for the 340 corresponding mailbox. 342 /vendor/ 343 Defines the top-level of entries associated with a specific 344 mailbox as created by a particular product of some vendor. This 345 entry can be used by vendors to provide client specific 346 annotations. The vendor-token MUST be registered with IANA, using 347 the ACAP [RFC2244] vendor subtree registry. 349 3.2.2. Attribute Names 351 Attribute names MUST be specified in a standards track or IESG 352 approved experimental RFC. See Section 6.1 for the registration 353 template. 355 All attribute names implicitly have a ".priv" and a ".shared" suffix 356 which maps to private and shared versions of the entry. Retrieving 357 an annotation without using either suffix includes both. The client 358 MUST specify either a ".priv" or ".shared" suffix when setting an 359 annotation. 361 value 362 A string or binary data representing the value of the annotation. 363 To delete an annotation, the client can store "NIL" into the 364 value. The content represented by the string is determined by the 365 Content-Type used to register the entry (see Section 6.1 for entry 366 registration templates). Where applicable, the registered 367 Content-Type MUST include a charset parameter. Text values SHOULD 368 use the utf-8 [RFC3629] character set. 369 Note that binary data (data which may contain the NULL octet) is 370 allowed (e.g. for storing images etc), and this extension uses the 371 "literal8" syntax element [RFC4466] to allow such data to be 372 written to or read from the server. 374 size 375 The size of the value, in octets. Set automatically by the 376 server, read-only to clients. 378 3.3. Private versus Shared and Access Control 380 As discussed in the ANNOTATE [I-D.ietf-imapext-annotate] extension 381 there is a need to support both private and shared annotations. This 382 document adopts the scheme used in [I-D.ietf-imapext-annotate] that 383 adds two standard suffixes for all attributes: ".shared" and ".priv". 384 A GETMETADATA or extended LIST command which specifies neither uses 385 both. SETMETADATA commands MUST explicitly use .priv or .shared 386 suffixes. 388 A user can only set and retrieve private or shared annotations on a 389 mailbox which is returned to them via a LIST or LSUB command, 390 irrespective of whether they have read or write access to the actual 391 message content of the mailbox. If the client attempts to set or 392 retrieve annotations on other mailboxes, the server MUST respond with 393 a NO response. 395 If the METADATA extension is present, support for shared annotations 396 is REQUIRED, whilst support for private annotations is OPTIONAL. 397 This recognizes the fact that support for private annotations may 398 introduce significantly more complexity to a server in terms of 399 tracking ownership of the annotations, how quota is determined for 400 users based on their own annotations etc. Clients that support the 401 METADATA extension MUST handle both shared and private annotations. 403 4. IMAP Protocol Changes 405 4.1. General Considerations 407 The new SETMETADATA command and the METADATA response each have a 408 mailbox name argument, indicating that the annotations being referred 409 to are attached to the specified mailbox. An empty string can be 410 used for the mailbox name to signify server annotations. 412 Both "*" and "%" list wildcard characters MAY be used in the mailbox 413 name argument in the SETMETADATA command to match all possible 414 occurrences of a mailbox name pattern. However, "*" or "%" by 415 themselves MUST NOT match the empty string (server) entries. Server 416 entries can only be accessed by explicitly using the empty string as 417 the mailbox name. 419 Servers SHOULD ensure that mailbox annotations are automatically 420 moved when the mailbox they refer to is renamed, i.e. the annotations 421 follow the mailbox. Servers SHOULD delete annotations for a mailbox 422 when the mailbox is deleted, so that a mailbox created with the same 423 name as a previously existing mailbox does not inherit the old 424 mailbox annotations. Servers SHOULD allow annotations on all 'types' 425 of mailbox, including ones reporting \Noselect for their LIST 426 response. Servers can implicitly remove \Noselect mailboxes when all 427 child mailboxes are removed, and as such any annotations associated 428 with the \Noselect mailbox SHOULD be removed. 430 The server is allowed to impose limitations on the size of any one 431 annotation or the total number of annotations for a single mailbox or 432 for the server as a whole. However, the server MUST accept a minimum 433 annotation data size of at least 1024 bytes, and a minimum annotation 434 count per server or mailbox of at least 10. 436 4.2. GETMETADATA Command 438 This extension adds the GETMETADATA command. This allows clients to 439 retrieve server annotations. Mailbox annotations are retrieved via 440 the extended LIST command described in the next section. 442 This command is only available in authenticated or selected state 443 [RFC3501]. 445 Arguments: entry-specifier 446 attribute-specifier 448 Responses: required METADATA response 450 Result: OK - command completed 451 NO - command failure: can't access annotations on 452 the server 453 BAD - command unknown or arguments invalid 455 Example: 457 C: a GETMETADATA /comment value.priv 458 S: * METADATA /comment (value.priv "My comment") 459 S: a OK GETMETADATA complete 461 In the above example, the contents of the "value.priv" attribute 462 for the "/comment" server entry is requested by the client and 463 returned by the server. 465 "*" and "%" wildcard characters can be used in the entry specifier to 466 match one or more characters at that position, with the exception 467 that "%" does not match the "/" hierarchy delimiter. Thus an entry 468 specifier of "/%" would match entries such as "/comment" and 469 "/version", but not "/comment/note". 471 Example: 473 C: a GETMETADATA /* value.priv 474 S: * METADATA /comment (value.priv "My comment") 475 /version (value.priv "1.1") 476 /motd/today (value.priv "Closed at 1 pm") 477 S: a OK GETMETADATA complete 479 In the above example, the contents of the "value.priv" attributes 480 for any server entries are requested by the client and returned by 481 the server. 483 Example: 485 C: a GETMETADATA /% value 486 S: * METADATA /comment (value.priv "My comment") 487 (value.shared "Your comment") 488 /motd (value.priv "Its sunny outside!" 489 (value.shared "Today is a Holiday") 490 S: a OK GETMETADATA complete 492 In the above example, the contents of the "value" attributes for 493 server entries at the top level of the entry hierarchy only, are 494 requested by the client and returned by the server. Both the 495 .priv and .shared values are returned, as neither were explicitly 496 requested. 498 Entry and attribute specifiers can be lists of atomic specifiers, so 499 that multiple items of each type may be returned in a single 500 GETMETADATA command. 502 Example: 504 C: a GETMETADATA (/comment /motd) value.priv 505 S: * METADATA /comment (value.priv "My comment") 506 /motd (value.priv "Its sunny outside!") 507 S: a OK GETMETADATA complete 509 In the above example, the contents of the "value.priv" attributes 510 for the two server entries "/comment" and "/motd" are requested by 511 the client and returned by the server. 513 Example: 515 C: a GETMETADATA /comment (value.priv 516 size.priv) 517 S: * METADATA /comment (value.priv "My comment" 518 size.priv "1234") 519 S: a OK GETMETADATA complete 521 In the above example, the contents of the "value.priv" and 522 "size.priv" attributes for the "/comment" server entry are 523 requested by the client and returned by the server. 525 4.3. Extended LIST Command Extensions 527 This extension adds the METADATA LIST command selection and return 528 option types, extending the LISTEXT extension. This allows clients 529 to retrieve mailbox annotations. 531 The LISTEXT "METADATA" selection option type is used to request that 532 the extended LIST command match mailboxes which have an annotation 533 with a specific entry and value. It can also be used to test for the 534 existence of a particular annotation entry on a mailbox. This 535 selection option takes one or more entry/attribute/value triples to 536 use as tests. A mailbox matches this criteria if it has an entry, 537 attribute and value matching the ones specified. In the case of 538 multiple criteria being specified, mailbox MUST only match when all 539 criteria match ("and" operation). To test for the existence of an 540 entry, a test for the attribute "value" with the empty string "" as 541 the value argument can be used. To test for the absence of an entry, 542 a test for the attribute "value" with NIL as the value argument can 543 be used. If the COMPARATOR [I-D.ietf-imapext-i18n] extension is 544 present, then the active comparator MUST be used when doing text 545 comparisons of the value. Clients SHOULD only use entries defined 546 with a "text" Content-Type in the selection option arguments. 548 The LISTEXT "METADATA" return option type is used to request that the 549 extended LIST command return specific annotation entries for each 550 mailbox returned in the LIST responses. A list of entries and 551 attributes to return can be specified in a manner similar to the 552 GETMETADATA command. 554 Example: 556 C: a LIST "" "INBOX" RETURN (METADATA /comment value.priv) 557 S: * LIST "/" "INBOX" 558 (METADATA /comment (value.priv "My comment")) 559 S: a OK LIST complete 561 In the above example, the contents of the "value.priv" attribute 562 for the "/comment" entry for the mailbox INBOX is requested by the 563 client and returned by the server. 565 "*" and "%" wildcard characters can be used in the entry specifier to 566 match one or more characters at that position, with the exception 567 that "%" does not match the "/" hierarchy delimiter. Thus an entry 568 specifier of "/%" would match entries such as "/comment" and 569 "/version", but not "/comment/note". 571 Example: 573 C: a LIST "" "INBOX" RETURN (METADATA /* value.priv) 574 S: * LIST "/" "INBOX" 575 (METADATA /comment (value.priv "My comment") 576 /version (value.priv "1.1") 577 /motd/today (value.priv "Closed at 1 pm")) 578 S: a OK LIST complete 580 In the above example, the contents of the "value.priv" attributes 581 for any entries for the mailbox INBOX are requested by the client 582 and returned by the server. 584 Example: 586 C: a LIST "" "INBOX" RETURN (METADATA /% value) 587 S: * LIST "/" "INBOX" 588 (METADATA /comment (value.priv "My comment") 589 (value.shared "Your comment") 590 /motd (value.priv "Its sunny outside!" 591 (value.shared "Today is a Holiday")) 592 S: a OK LIST complete 594 In the above example, the contents of the "value" attributes for 595 entries for the mailbox INBOX at the top level of the entry 596 hierarchy only, are requested by the client and returned by the 597 server. Both the .priv and .shared values are returned, as 598 neither were explicitly requested. 600 Entry and attribute specifiers can be lists of atomic specifiers, so 601 that multiple items of each type may be returned in a single LIST 602 command. 604 Example: 606 C: a LIST "" "INBOX" RETURN (METADATA (/comment /motd) 607 value.priv) 608 S: * LIST "/" "INBOX" 609 (METADATA /comment (value.priv "My comment") 610 /motd (value.priv "Its sunny outside!")) 611 S: a OK LIST complete 613 In the above example, the contents of the "value.priv" attributes 614 for the two entries "/comment" and "/motd" for the mailbox INBOX 615 are requested by the client and returned by the server. 617 Example: 619 C: a LIST "" "INBOX" RETURN (METADATA /comment 620 (value.priv size.priv)) 621 S: * LIST "/" "INBOX" 622 (METADATA /comment (value.priv "My comment" 623 size.priv "1234")) 624 S: a OK LIST complete 626 In the above example, the contents of the "value.priv" and 627 "size.priv" attributes for the "/comment" entry for the mailbox 628 INBOX are requested by the client and returned by the server. 630 Example: 632 C: a LIST "" ("INBOX" "FOOBOX" "BARBOX") RETURN 633 (METADATA /comment value.priv) 634 S: * LIST "/" "INBOX" 635 (METADATA /comment (value.priv "My comment")) 636 S: * LIST "/" "FOOBOX" 637 (METADATA /comment (value.priv "Another comment")) 638 S: * LIST "/" "BARBOX" 639 (METADATA /comment (value.priv NIL)) 640 S: a OK LIST complete 642 In the above example, the contents of the "value.priv" attribute 643 for the "/comment" entry for the mailboxes INBOX, FOOBOX and 644 BARBOX are requested by the client and returned by the server. 645 Note that the mailbox BARBOX does not contain the entry, hence NIL 646 is returned for the attribute value. 648 Example: 650 C: a LIST (METADATA ("/comment" "value" "comm") 651 "" "*" 652 S: * LIST () "/" "INBOX" 653 S: * LIST (\NoInferiors) "/" "FOOBOX" 654 S: a OK LIST complete 656 In the above example, the client requests that any mailbox in the 657 entire hierarchy containing the text "comm" in any "value" 658 attribute of the "/comment" entry be returned. Two mailboxes are 659 returned in separate responses. Note that the client did not ask 660 for annotations to be returned in the responses. 662 Example: 664 C: a LIST (METADATA ("/comment" "value" "") 665 "" "*" 666 S: * LIST () "/" "INBOX" 667 S: * LIST (\NoInferiors) "/" "FOOBOX" 668 S: a OK LIST complete 670 In the above example, the client requests that any mailbox in the 671 entire hierarchy containing the "/comment" entry be returned. Two 672 mailboxes are returned in separate responses. Note that the 673 client did not ask for annotations to be returned in the 674 responses. 676 Example: 678 C: a LIST (METADATA ("/comment" "value" NIL) 679 "" "*" 680 S: * LIST (\NoInferiors) "/" "BARBOX" 681 S: a OK LIST complete 683 In the above example, the client requests that any mailbox in the 684 entire hierarchy that does not have a "/comment" entry be 685 returned. One mailbox is returned in a response. Note that the 686 client did not ask for annotations to be returned in the 687 responses. 689 Example: 691 C: a LIST (METADATA ("/comment" "value" "comm") 692 "" "*" RETURN (METADATA /comment size.priv) 693 S: * LIST "/" "INBOX" 694 (METADATA /comment (size.priv "10")) 695 S: * LIST "/" "FOOBOX" 696 (METADATA /comment (size.priv "15")) 697 S: a OK LIST complete 699 In the above example, the client requests that any mailbox in the 700 entire hierarchy containing the text "comm" in any "value" 701 attribute of the "/comment" entry be returned. Two mailboxes are 702 returned in separate responses. The client also asked for 703 annotations to be returned in the responses. 705 4.3.1. Unsolicited LIST response 707 Servers SHOULD send unsolicited LIST responses if mailbox annotations 708 are changed by a third-party, allowing servers to keep clients 709 updated with changes. Unsolicited mailbox annotations MUST only be 710 returned for the currently selected mailbox. 712 Unsolicited LIST responses MUST only contain entry names, not the 713 attributes and values. If the client wants to update any cached 714 values it must explicitly retrieve those using a LIST command. 716 The LIST response can contain multiple entries in a single response, 717 but the server is free to return multiple responses for each entry or 718 group of entries if it desires. 720 Example: 722 C: a NOOP 723 S: * LIST "/" "INBOX" (METADATA /comment) 724 S: a OK NOOP complete 726 In the above example, the server sends an unsolicited LIST 727 response indicating that the "/comment" entry of the mailbox 728 "INBOX" has been changed. 730 4.4. SETMETADATA Command 732 This extension adds the SETMETADATA command. This allows clients to 733 set annotations. 735 This command is only available in authenticated or selected state 736 [RFC3501]. 738 Arguments: mailbox-name 739 entry 740 attribute-value 741 list of entry, attribute-values 743 Responses: no specific responses for this command 745 Result: OK - command completed 746 NO - command failure: can't set annotations, 747 or annotation too big or too many 748 BAD - command unknown or arguments invalid 750 This command sets the specified list of entries by adding or 751 replacing the specified attributes with the values provided. Clients 752 can use NIL for values of attributes it wants to remove from entries. 753 The server MAY return a METADATA response containing the updated 754 annotation data. Clients MUST NOT assume that a METADATA response 755 will be sent, and MUST assume that if the command succeeds then the 756 annotation has been changed. 758 If the server is unable to set an annotation because the size of its 759 value is too large, the server MUST return a tagged NO response with 760 a "[METADATA TOOBIG]" response code. 762 If the server is unable to set a new annotation because the maximum 763 number of allowed annotations has already been reached, the server 764 MUST return a tagged NO response with a "[METADATA TOOMANY]" response 765 code. 767 If the server is unable to set a new annotation because it does not 768 support private annotations on one of the specified mailboxes, the 769 server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" 770 response code. 772 If the server is unable to set the annotations for one or more 773 mailboxes matching the mailbox-name pattern, then the SETMETADATA 774 command MUST fail and there MUST NOT be any changes to any of the 775 matching mailboxes, even those for which annotations could have been 776 changed successfully. 778 Example: 780 C: a SETMETADATA INBOX /comment 781 (value.priv "My new comment") 782 S: a OK SETMETADATA complete 784 In the above example, the entry "/comment" for the mailbox "INBOX" 785 is created (if not already present) and the private attribute 786 "value" with data set to "My new comment" is created if not 787 already present, or replaced if it previously exists. 789 Example: 791 C: a SETMETADATA INBOX /comment (value.priv NIL) 792 S: a OK SETMETADATA complete 794 In the above example, the private "value" attribute of the entry 795 "/comment" is removed from the mailbox "INBOX". 797 Annotations on multiple mailboxes can be set in a single SETMETADATA 798 command by using a wildcard specification for the mailbox name. 800 Example: 802 C: a SETMETADATA INBOX.% /comment 803 (value.priv "My new comment") 804 S: a OK SETMETADATA complete 806 In the above example, the entry "/comment" for all mailboxes at 807 the top-level of the "INBOX" hierarchy are created (if not already 808 present) and the private attribute "value" are created 809 respectively for each entry if not already present, or replaced if 810 they previously existed. 812 Multiple entries can be set in a single SETMETADATA command by 813 listing entry-attribute-value pairs in the list. 815 Example: 817 C: a SETMETADATA INBOX (/comment 818 (value.priv "My new comment") 819 /thread 820 (value.priv "REFERENCES ALL")) 821 S: a OK SETMETADATA complete 823 In the above example, the entries "/comment" and "/thread" for the 824 mailbox "INBOX" are created (if not already present) and the 825 "value.priv" attributes are created respectively for each entry if 826 not already present, or replaced if they previously existed. 828 Multiple attributes can be set in a single SETMETADATA command by 829 listing multiple attribute-value pairs in the entry list. 831 Example: 833 C: a SETMETADATA INBOX /comment 834 (value.priv "My new comment" 835 value.shared "foo's bar") 836 S: a OK SETMETADATA complete 838 In the above example, the entry "/comment" for the mailbox "INBOX" 839 is created (if not already present) and the attributes 840 "value.priv" and "value.shared" are created if not already 841 present, or replaced if they previously existed. 843 Example: 845 C: a SETMETADATA INBOX /comment 846 (value.priv "My new comment") 847 S: a NO [METADATA TOOMANY] SETMETADATA failed 849 In the above example, the server is unable to set the requested 850 (new) annotation as it has reached the limit on the number of 851 annotations it can support on the specified mailbox. 853 4.5. METADATA Response 855 The METADATA response displays results of a GETMETADATA command, or 856 can be returned as an unsolicited response at anytime by the server 857 in response to a change in a server annotation. 859 Servers SHOULD send unsolicited METADATA responses if server 860 annotations are changed by a third-party, allowing servers to keep 861 clients updated with changes. 863 Unsolicited METADATA responses MUST only contain entry names, not the 864 attributes and values. If the client wants to update any cached 865 values it must explicitly retrieve those using a GETMETADATA command. 867 The METADATA response can contain multiple entries in a single 868 response, but the server is free to return multiple responses for 869 each entry or group of entries if it desires. 871 This response is only available in authenticated or selected state 872 [RFC3501]. 874 4.5.1. METADATA response with attributes and values 876 The response consists of a list of entries each of which has a list 877 of attribute-value pairs. 879 Example: 881 C: a GETMETADATA /comment value.priv 882 S: * METADATA /comment (value.priv "My comment") 883 S: a OK GETMETADATA complete 885 In the above example, a single entry with a single attribute-value 886 pair is returned by the server. 888 Example: 890 C: a GETMETADATA (/comment /motd) value.priv 891 S: * METADATA /comment (value.priv "My comment") 892 /motd (value.priv "Its sunny outside!") 893 S: a OK GETMETADATA complete 895 In the above example, two entries each with a single attribute- 896 value pair is returned by the server. 898 Example: 900 C: a GETMETADATA (/comment /motd) value.priv 901 S: * METADATA /comment (value.priv "My comment") 902 S: * METADATA /motd (value.priv "Its sunny outside!") 903 S: a OK GETMETADATA complete 905 In the above example, the server returns two separate responses 906 for each of the two entries requested. 908 Example: 910 C: a GETMETADATA /comment (value.priv size.priv) 911 S: * METADATA /comment (value.priv "My comment" 912 size.priv "10") 913 S: a OK GETMETADATA complete 915 In the above example, a single entry with two attribute-value 916 pairs is returned by the server. 918 4.5.2. Unsolicited METADATA response without attributes and values 920 The response consists of a parenthesized list of entries, each of 921 which have changed on the server. 923 Example: 925 C: a NOOP 926 S: * METADATA (/comment) 927 S: a OK NOOP complete 929 In the above example, the server indicates that the "/comment" 930 server entry has been changed. 932 Example: 934 C: a NOOP 935 S: * METADATA (/comment /motd) 936 S: a OK NOOP complete 938 In the above example, the server indicates a change to two server 939 entries. 941 5. Formal Syntax 943 The following syntax specification uses the Augmented Backus-Naur 944 Form (ABNF) notation as specified in [RFC2234]. 946 Non-terminals referenced but not defined below are as defined by 947 [RFC3501] with the new definitions in [RFC4466] superseding those in 948 [RFC3501]. 950 Except as noted otherwise, all alphabetic characters are case- 951 insensitive. The use of upper or lower case characters to define 952 token strings is for editorial clarity only. Implementations MUST 953 accept these strings in a case-insensitive fashion. 955 annotate-data = "METADATA" SP entry-list 957 att-select = "value" / "value.priv" / "value.shared" 958 ; the only attributes that can be selected 960 att-value = attrib SP value 962 attrib = astring 963 ; dot-separated attribute name 964 ; MUST NOT contain "*" or "%" 966 attribs = attrib / "(" attrib *(SP attrib) ")" 967 ; one or more attribute specifiers 969 capability =/ "METADATA" 970 ; defines the capability for this extension 972 command-auth =/ setmetadata / getmetadata 973 ; adds to original IMAP command 975 entries = entry-match / 976 "(" entry-match *(SP entry-match) ")" 977 ; entry specifiers that can include wildcards 979 entry = astring 980 ; slash-separated path to entry 981 ; MUST NOT contain "*" or "%" 983 entry-att = entry SP "(" att-value *(SP att-value) ")" 985 entry-list = entry-att *(SP entry-att) / 986 "(" entry *(SP entry) ")" 987 ; entry attribute-value pairs list for 988 ; GETMETADATA response, or 989 ; parenthesised entry list for unsolicited 990 ; notification of annotation changes 992 entry-match = list-mailbox 993 ; slash-separated path to entry 994 ; MAY contain "*" or "%" for use as wildcards 996 getmetadata = "GETMETADATA" SP entries SP attribs 998 list-select-base-opt =/ "METADATA" SP 999 "(" list-select-metadata 1000 *(SP list-select-metadata) ")" 1001 ; adds a new selection option type to 1002 ; LISTEXT. When evaluating multiple entry, 1003 ; attribute, value combinations, a match to 1004 ; a mailbox must occur when all items match. 1006 list-select-metadata = entry-match SP att-select SP value 1007 ; value set to the empty string means match 1008 ; if that entry and attribute exist. 1009 ; value set to NIL means match if that entry 1010 ; and attribute do not exist. 1012 response-payload =/ annotate-data 1013 ; adds to original IMAP data responses 1015 resp-text-code =/ "METADATA" SP ("TOOBIG" / "TOOMANY" / 1016 "NOPRIVATE") 1017 ; new response codes for SETMETADATA 1018 ; failures 1020 setmetadata = "SETMETADATA" SP list-mailbox 1021 SP setentryatt 1022 ; empty string for list-mailbox implies 1023 ; server annotation. 1025 setentryatt = entry-att / "(" entry-att *(SP entry-att) ")" 1027 value = nstring / literal8 1029 6. IANA Considerations 1031 Entry names MUST be specified in a standards track or IESG approved 1032 experimental RFC, or fall under the vendor namespace. Attribute 1033 names MUST be specified in a standards track or IESG approved 1034 experimental RFC. 1036 Each entry registration MUST include a content-type that is used to 1037 indicate the nature of the annotation value. Where applicable a 1038 charset parameter MUST be included with the content-type. 1040 6.1. Entry and Attribute Registration Template 1042 To: iana@iana.org 1043 Subject: IMAP METADATA Registration 1045 Please register the following IMAP METADATA item: 1047 [ ] Entry [ ] Attribute 1049 [ ] Mailbox [ ] Server 1051 Name: ______________________________ 1053 Description: _______________________ 1055 ____________________________________ 1057 ____________________________________ 1059 Content-type: ____________________ 1061 Contact person: ____________________ 1063 email: ____________________ 1065 6.2. Server Entry Registrations 1067 The following templates specify the IANA registrations of annotation 1068 entries specified in this document. 1070 6.2.1. /comment 1072 To: iana@iana.org 1073 Subject: IMAP METADATA Registration 1075 Please register the following IMAP METADATA item: 1077 [x] Entry [ ] Attribute 1079 [ ] Mailbox [x] Server 1081 Name: /comment 1083 Description: Defined in IMAP METADATA extension document. 1085 Content-type: text/plain; charset=utf-8 1087 Contact person: Cyrus Daboo 1089 email: cyrus@daboo.name 1091 6.2.2. /motd 1093 To: iana@iana.org 1094 Subject: IMAP METADATA Registration 1096 Please register the following IMAP METADATA item: 1098 [x] Entry [ ] Attribute 1100 [ ] Mailbox [x] Server 1102 Name: /motd 1104 Description: Defined in IMAP METADATA extension document. 1106 Content-type: text/plain; charset=utf-8 1108 Contact person: Cyrus Daboo 1110 email: cyrus@daboo.name 1112 6.2.3. /admin 1114 To: iana@iana.org 1115 Subject: IMAP METADATA Registration 1117 Please register the following IMAP METADATA item: 1119 [x] Entry [ ] Attribute 1121 [ ] Mailbox [x] Server 1123 Name: /admin 1125 Description: Defined in IMAP METADATA extension document. 1127 Content-type: text/plain; charset=utf-8 1129 Contact person: Cyrus Daboo 1131 email: cyrus@daboo.name 1133 6.3. Mailbox Entry Registrations 1135 The following templates specify the IANA registrations of annotation 1136 entries specified in this document. 1138 6.3.1. /comment 1140 To: iana@iana.org 1141 Subject: IMAP METADATA Registration 1143 Please register the following IMAP METADATA item: 1145 [x] Entry [ ] Attribute 1147 [x] Mailbox [ ] Server 1149 Name: /comment 1151 Description: Defined in IMAP METADATA extension document. 1153 Content-type: text/plain; charset=utf-8 1155 Contact person: Cyrus Daboo 1157 email: cyrus@daboo.name 1159 6.3.2. /sort 1161 To: iana@iana.org 1162 Subject: IMAP METADATA Registration 1164 Please register the following IMAP METADATA item: 1166 [x] Entry [ ] Attribute 1168 [x] Mailbox [ ] Server 1170 Name: /sort 1172 Description: Defined in IMAP METADATA extension document. 1174 Content-type: text/plain; charset=utf-8 1176 Contact person: Cyrus Daboo 1178 email: cyrus@daboo.name 1180 6.3.3. /thread 1182 To: iana@iana.org 1183 Subject: IMAP METADATA Registration 1185 Please register the following IMAP METADATA item: 1187 [x] Entry [ ] Attribute 1189 [x] Mailbox [ ] Server 1191 Name: /thread 1193 Description: Defined in IMAP METADATA extension document. 1195 Content-type: text/plain; charset=utf-8 1197 Contact person: Cyrus Daboo 1199 email: cyrus@daboo.name 1201 6.3.4. /check 1203 To: iana@iana.org 1204 Subject: IMAP METADATA Registration 1206 Please register the following IMAP METADATA item: 1208 [x] Entry [ ] Attribute 1210 [x] Mailbox [ ] Server 1212 Name: /check 1214 Description: Defined in IMAP METADATA extension document. 1216 Content-type: text/plain; charset=utf-8 1218 Contact person: Cyrus Daboo 1220 email: cyrus@daboo.name 1222 6.3.5. /checkperiod 1224 To: iana@iana.org 1225 Subject: IMAP METADATA Registration 1227 Please register the following IMAP METADATA item: 1229 [x] Entry [ ] Attribute 1231 [x] Mailbox [ ] Server 1233 Name: /checkperiod 1235 Description: Defined in IMAP METADATA extension document. 1237 Content-type: text/plain; charset=utf-8 1239 Contact person: Cyrus Daboo 1241 email: cyrus@daboo.name 1243 6.4. Attribute Registrations 1245 The following templates specify the IANA registrations of annotation 1246 attributes specified in this document. 1248 6.4.1. value 1250 To: iana@iana.org 1251 Subject: IMAP METADATA Registration 1253 Please register the following IMAP METADATA item: 1255 [ ] Entry [x] Attribute 1257 [ ] Mailbox [ ] Server 1259 Name: value 1261 Description: Defined in IMAP METADATA extension document. 1263 Content-type: - 1265 Contact person: Cyrus Daboo 1267 email: cyrus@daboo.name 1269 6.4.2. size 1271 To: iana@iana.org 1272 Subject: IMAP METADATA Registration 1274 Please register the following IMAP METADATA item: 1276 [ ] Entry [x] Attribute 1278 [ ] Mailbox [ ] Server 1280 Name: size 1282 Description: Defined in IMAP METADATA extension document. 1284 Content-type: - 1286 Contact person: Cyrus Daboo 1288 email: cyrus@daboo.name 1290 6.5. LISTEXT Registration 1292 TBD: registration for select and return options. 1294 7. Security Considerations 1296 Annotations whose values are intended to remain private MUST use 1297 .priv values, and not .shared values which may be accessible to other 1298 users. 1300 Excluding the above issues the METADATA extension does not raise any 1301 security considerations that are not present in the base IMAP 1302 protocol, and these issues are discussed in [RFC3501]. 1304 8. References 1306 8.1. Normative References 1308 [I-D.ietf-imapext-i18n] 1309 Newman, C., "Internet Message Access Protocol 1310 Internationalization", draft-ietf-imapext-i18n-06 (work in 1311 progress), March 2006. 1313 [I-D.ietf-imapext-list-extensions] 1314 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 1315 Extensions", draft-ietf-imapext-list-extensions-18 (work 1316 in progress), September 2006. 1318 [I-D.ietf-imapext-sort] 1319 Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1320 PROTOCOL - SORT AND THREAD EXTENSION", 1321 draft-ietf-imapext-sort-17 (work in progress), May 2004. 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, March 1997. 1326 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1327 Specifications: ABNF", RFC 2234, November 1997. 1329 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1330 Configuration Access Protocol", RFC 2244, November 1997. 1332 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1333 4rev1", RFC 3501, March 2003. 1335 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1336 10646", STD 63, RFC 3629, November 2003. 1338 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1339 ABNF", RFC 4466, April 2006. 1341 8.2. Informative References 1343 [I-D.ietf-imapext-annotate] 1344 Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", 1345 draft-ietf-imapext-annotate-15 (work in progress), 1346 March 2006. 1348 Appendix A. Acknowledgments 1350 The ideas expressed in this document are based on the message 1351 annotation document that was co-authored by Randall Gellens. The 1352 participants of the IMAPext working group made significant 1353 contributions to this work. 1355 Author's Address 1357 Cyrus Daboo 1358 Apple Computer, Inc. 1359 1 Infinite Loop 1360 Cupertino, CA 95014 1361 USA 1363 Email: cyrus@daboo.name 1364 URI: http://www.apple.com/ 1366 Full Copyright Statement 1368 Copyright (C) The Internet Society (2006). 1370 This document is subject to the rights, licenses and restrictions 1371 contained in BCP 78, and except as set forth therein, the authors 1372 retain all their rights. 1374 This document and the information contained herein are provided on an 1375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1377 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1378 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1379 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1382 Intellectual Property 1384 The IETF takes no position regarding the validity or scope of any 1385 Intellectual Property Rights or other rights that might be claimed to 1386 pertain to the implementation or use of the technology described in 1387 this document or the extent to which any license under such rights 1388 might or might not be available; nor does it represent that it has 1389 made any independent effort to identify any such rights. Information 1390 on the procedures with respect to rights in RFC documents can be 1391 found in BCP 78 and BCP 79. 1393 Copies of IPR disclosures made to the IETF Secretariat and any 1394 assurances of licenses to be made available, or the result of an 1395 attempt made to obtain a general license or permission for the use of 1396 such proprietary rights by implementers or users of this 1397 specification can be obtained from the IETF on-line IPR repository at 1398 http://www.ietf.org/ipr. 1400 The IETF invites any interested party to bring to its attention any 1401 copyrights, patents or patent applications, or other proprietary 1402 rights that may cover technology that may be required to implement 1403 this standard. Please address the information to the IETF at 1404 ietf-ipr@ietf.org. 1406 Acknowledgment 1408 Funding for the RFC Editor function is provided by the IETF 1409 Administrative Support Activity (IASA).