idnits 2.17.1 draft-daboo-imapext-annotate-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 2000) is 8780 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: 'ACAP' is mentioned on line 89, but not defined == Missing Reference: 'MIME' is mentioned on line 233, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) -- Possible downref: Non-RFC (?) normative reference: ref. 'SORT-EXT' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group C. Daboo 2 Internet Draft: IMAP ANNOTATE Extension R. Gellens 3 Document: draft-daboo-imapext-annotate-00.txt March 2000 5 IMAP ANNOTATE Extension 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 22 Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Copyright Notice 27 Copyright (C) The Internet Society 2000. All Rights Reserved. 29 Table of Contents 30 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 31 2 Conventions Used in This Document . . . . . . . . . . . . . 2 32 3 Introduction and Overview . . . . . . . . . . . . . . . . . . 2 33 4 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 34 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 35 4.2 Namespace of entries and attributes . . . . . . . . . . 3 36 4.2.1 Entry Names . . . . . . . . . . . . . . . . . . . . . 4 37 4.2.2 Attribute Names . . . . . . . . . . . . . . . . . . 5 38 5 IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 39 5.1 ANNOTATION message data item in FETCH Command . . . . . 6 40 5.2 ANNOTATION message data item in FETCH Response . . . . . 7 41 5.3 ANNOTATION message data item in STORE . . . . . . . . . 8 42 5.4 ANNOTATION criterion in SEARCH . . . . . . . . . . . . . 9 43 5.5 ANNOTATION key in SORT . . . . . . . . . . . . . . . . . 10 44 6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 45 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 46 7.1 Entry and Attribute Registration Template . . . . . . . . 12 47 8 Security Considerations . . . . . . . . . . . . . . . . . . 13 48 9 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 49 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 51 1 Abstract 53 The ANNOTATE extension to the Internet Message Access Protocol 54 [IMAP4] permits clients and servers to maintain "metadata" for 55 messages stored in an IMAP4 mailbox. 57 2 Conventions Used in This Document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 63 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 65 In examples, "C:" and "S:" indicate lines sent by the client and 66 server respectively. 68 3 Introduction and Overview 70 The ANNOTATE extension is present in any IMAP4 implementation which 71 returns "ANNOTATE" as one of the supported capabilities in the 72 CAPABILITY command response. 74 The ANNOTATE extension adds a new message data item to the FETCH and 75 STORE commands, as well as adding SEARCH and SORT keys. 77 This extension makes the following changes to the IMAP4 protocol: 79 a) adds a new ANNOTATION message data item for use in the FETCH 80 command 81 b) adds a new ANNOTATION message data item for use in the STORE 82 command 83 c) adds a new ANNOTATION search criterion for use in the SEARCH 84 command 85 d) adds a new ANNOTATION sort key for use in the SORT command 86 extension 88 The data model used for the storage of annotations is based on that 89 of the Application Configuration Access Protocol [ACAP], with the 90 exception of inheritence which is not deemed necessary here. 92 The rest of this document describes the data model and protocol 93 changes more rigorously. 95 4 Data Model 97 4.1 Overview 99 The data model used in ANNOTATE is one of a uniquely named entry 100 with a set of uniquely named attributes, each of which has a value. 101 A message annotation can contain multiple named entries. For 102 example, a general comment being added to a message may have an 103 entry name of "/message/comment". This entry could include named 104 attributes such as "value", "modifiedsince", "acl" etc to represent 105 properties and data associated with the entry. 107 The protocol changes to IMAP described below allow a client to 108 access or change the values of any attributes in any entries in a 109 message annotation, assuming it has sufficient access rights to do 110 so. 112 4.2 Namespace of entries and attributes 114 Each message annotation is made up of a set of entries. Each entry 115 has a hierarchical name in UTF-8, with each component of the name 116 separated by a slash ("/"). 118 Each entry is made up of a set of attributes. Each attribute has a 119 hierarchical name in UTF-8, with each component of the name 120 separated by a period ("."). 122 The value of an attribute is NIL (has no value), or a string of zero 123 or more octets. 125 Entry and attribute names are not permitted to contain asterisk 126 ("*") or percent ("%") characters and MUST be valid UTF-8 strings 127 which do not contain NUL. Invalid entry or attribute names result 128 in a BAD response in any IMAP commands where they are used. 130 Use of non-visible UTF-8 characters in entry and attribute names is 131 discouraged. 133 This specification defines an initial set of entry and attribute 134 names available for use in message annotations. In addition an 135 extension mechanism is described to allow additional names to be 136 added for extensibility. 138 4.2.1 Entry Names 140 Entry names MUST be specified in a standards track or IESG approved 141 experimental RFC, or fall under the vendor namespace. See section 142 7.1 for the registration template. 144 /message 145 Defines the top-level of entries associated with an entire 146 message. This entry itself does not have any associated 147 attributes. 149 /message/comment 150 Defines a comment or note associated with an entire message. 152 /message/flags 153 Defines the top-level of entries for client-use flags associated 154 with an entire message. All sub-entries are maintained entirely 155 by the client. There is no implicit change to any flag by the 156 server. 158 /message/flags/redirected 159 /message/flags/forwarded 160 /message/flags/queued 161 Defines client-use flags for an entire message. The "value" 162 attribute of these entries must be either "1", "0" or NIL. The 163 "queued" flag MUST only be set for messages which have the DRAFT 164 flag set. The "queued" flag indicates that a message is 165 eligible to be sent (submitted into the mail system for 166 delivery) by any client at any time. The "queued" flag SHOULD 167 be reset while a client is attempting to submit the message. 169 /message/smtp-envelope 170 Defines the SMTP envelope used in delivery of the message. The 171 client SHOULD NOT modify the /message/smtp-envelope entry or its 172 attributes, except in messages which have the DRAFT flag set. 174 /message/subject 175 Contains text supplied by the message recipient, to be used by 176 the client instead of the original message Subject. 178 /message/vendor/ 179 Defines the top-level of entries associated with an entire 180 message as created by a particular product of some vendor. This 181 entry can be used by vendors to provide client specific 182 attributes. The vendor-token MUST be registered with IANA. 184 /body/ 185 Defines the top-level of entries associated with a specific body 186 part of a message. This entry itself does not have any 187 associated attributes. The part-specifier uses the same part 188 specifier syntax as the BODY message data item in the FETCH 189 command [IMAP4]. 191 /body//comment 192 Defines a comment or note associated with a specific body part 193 of a message. 195 /body//flags 196 Defines the top-level of entries associated with flag state for 197 a specific body part of a message. All sub-entries are 198 maintained entirely by the client. There is no implicit change 199 to any flag by the server. 201 /body//flags/seen 202 /body//flags/answered 203 /body//flags/flagged 204 Defines flags for a specific body part of a message. The 205 "value" attribute of these entries must be either "1", "0" or 206 NIL. 208 /body//vendor/ 209 Defines the top-level of entries associated with a specific body 210 part of a message as created by a particular product of some 211 vendor. This entry can be used by vendors to provide client 212 specific attributes. The vendor-token MUST be registered with 213 IANA. 215 4.2.2 Attribute Names 217 Attribute names MUST be specified in a standards track or IESG 218 approved experimental RFC, or fall under the vendor namespace. See 219 section 7.1 for the registration template. 221 value 222 The data value of the attribute. 224 modifiedsince 225 An opaque value set by the server when this entry is modified. 226 It can be used by the client to request notification of which 227 entries have changed since a particular point in time and is 228 useful for disconnected/synchronisation operations. (The value 229 is intended to be used only for comparisons within a server, not 230 as an accurate timestamp.) 232 content-type 233 A MIME [MIME] content type and subtype that describes the nature 234 of the content of the "value" attribute. 236 vendor. 237 Defines an attribute associated with a particular product of 238 some vendor. This attribute can be used by vendors to provide 239 client specific attributes. The vendor-token MUST be registered 240 with IANA. 242 5 IMAP Protocol Changes 244 5.1 ANNOTATION message data item in FETCH Command 246 This extension adds an ANNOTATION message data item to the FETCH 247 command. This allows clients to retrieve annotations for a range of 248 messages in the currently selected mailbox. 250 ANNOTATION 251 The ANNOTATION message data item, when used by the client in the 252 FETCH command, takes an entry specifier and an attribute 253 specifier. 255 Example: 257 C: a FETCH 1 (ANNOTATION ("/message/comment" "value")) 258 S: * 1 FETCH (ANNOTATION ("/message/comment" (("value" "My comment")))) 259 S: a OK Fetch complete 261 In the above example, the contents of the "value" attribute 262 for the "/message/comment" entry is requested by the client 263 and returned by the server. 265 "*" and "%" wildcard characters can be used in either specifier to 266 match match one or more characters at that position, with the 267 exception that "%" does not match the hierarchy delimiter for the 268 specifier it appears in (that is, "/" for an entry specifier or "." 269 for an attribute specifer). Thus an entry specifier of "/message/%" 270 matches entries such as "/message/comment" and "/message/subject", 271 but not "/message/comment/note". 273 Examples: 275 C: a FETCH 1 (ANNOTATION ("/message/*" "value")) 276 S: * 1 FETCH (ANNOTATION 277 (("/message/comment" ("value" "My comment")) 278 ("/message/version" ("value" "1.1")) 279 ("/message/version/last" ("value" "1.0.1")))) 280 S: a OK Fetch complete 282 In the above example, the contents of the "value" attributes 283 for any entries in the "/message" hierarchy are requested by 284 the client and returned by the server. 286 C: a FETCH 1 (ANNOTATION ("/message/%" "value")) 287 S: * 1 FETCH (ANNOTATION 288 (("/message/comment" ("value" "My comment")) 289 ("/message/version" ("value" "1.1")))) 290 S: a OK Fetch complete 292 In the above example, the contents of the "value" attributes 293 for entries at the top level of the "/message" hierarchy 294 only, are requested by the client and returned by the 295 server. 297 Entry and attribute specifiers can be lists of atomic specifiers, so 298 that multiple items of each type may be returned in a single FETCH 299 command. 301 Examples: 303 C: a FETCH 1 (ANNOTATION 304 (("/message/comment" "/message/version") "value")) 305 S: * 1 FETCH (ANNOTATION 306 (("/message/comment" ("value" "My comment")) 307 ("/message/version" ("value" "1.1")))) S: a OK Fetch complete 309 In the above example, the contents of the "value" attributes 310 for the two entries "/message/comment" and 311 "/message/version" are requested by the client and returned 312 by the server. 314 C: a FETCH 1 (ANNOTATION 315 ("/message/comment" ("value" "modifiedsince"))) 316 S: * 1 FETCH (ANNOTATION 317 (("/message/comment" 318 ("value" "My comment" 319 "modifiedsince" "19990203205432")))) 320 S: a OK Fetch complete 322 In the above example, the contents of the "value" and 323 "modifiedsince" attributes for the "/message/comment" entry 324 are requested by the client and returned by the server. 326 5.2 ANNOTATION message data item in FETCH Response 328 The ANNOTATION message data item in the FETCH response displays 329 information about annotations in a message. 331 ANNOTATION parenthesised list 332 The response consists of a list of entries each of which has a 333 list of attribute-value pairs. 335 Examples: 337 C: a FETCH 1 (ANNOTATION ("/message/comment" "value")) 338 S: * 1 FETCH (ANNOTATION ("/message/comment" (("value" "My comment")))) 339 S: a OK Fetch complete 341 In the above example, a single entry with a single 342 attribute-value pair is returned by the server. 344 C: a FETCH 1 (ANNOTATION 345 (("/message/comment" "/message/version") "value")) 346 S: * 1 FETCH (ANNOTATION 347 (("/message/comment" ("value" "My comment")) 348 ("/message/version" ("value" "1.1")))) 349 S: a OK Fetch complete 351 In the above example, two entries each with a single 352 attribute-value pair are returned by the server. 354 C: a FETCH 1 (ANNOTATION 355 ("/message/comment" ("value" "modifiedsince"))) 356 S: * 1 FETCH (ANNOTATION 357 (("/message/comment" 358 ("value" "My comment" 359 "modifiedsince" "19990203205432")))) 360 S: a OK Fetch complete 362 In the above example, a single entry with two 363 attribute-value pairs is returned by the server. 365 Servers SHOULD send ANNOTATION message data items in unsolicted 366 FETCH responses if the annotation is changed by a third-party, 367 allowing servers to keep clients updated with changes to annotations 368 by other clients. 370 5.3 ANNOTATION message data item in STORE 372 ANNOTATION 373 Sets the specified list of entries by adding or replacing the 374 specified attributes with the values provided. Clients can use 375 NIL for values of attributes it wants to remove from entries. 377 The ANNOTATION message data item used with the STORE command has an 378 implicit ".SILENT" behaviour. This means the server does not 379 generate an untagged FETCH in response to the STORE command and 380 assumes that the client updates its own cache if the command 381 succeeds. 383 Examples: 385 C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My new comment")) 386 S: a OK Store complete 388 In the above example, the entry "/message/comment" is 389 created (if not already present) and the attribute "value" 390 with data set to "My new comment" is created if not already 391 present, or replaced if it previously exists. 393 C: a STORE 1 ANNOTATION ("/message/comment" ("value" NIL)) 394 S: a OK Store complete 396 In the above example, the "value" attribute of the entry 397 "/message/comment" is removed. 399 Multiple entries can be set in a single STORE command by listing 400 entry-attribute-value pairs in the list. 402 Example: 403 C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My new comment") 404 "/message/version" ("value" "1.1")) 405 S: a OK Store complete 407 In the above example, the entries "/message/comment" and 408 "/message/version" are created (if not already present) and 409 the attribute "value" is created for each entry if not 410 already present, or replaced if they previously exist. 412 Multiple attributes can be set in a single STORE command by listing 413 multiple attribute-value pairs in the entry list. 415 Example: 416 C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My new comment" 417 "vendor.foobar" "foo's bar")) 418 S: a OK Store complete 420 In the above example, the entry "/message/comment" is 421 created (if not already present) and the attributes "value" 422 and "vendor.foobar" are created if not already present, or 423 replaced if they previously exist. 425 5.4 ANNOTATION criterion in SEARCH 427 The ANNOTATION criterion for the SEARCH command allows a client to 428 search for the specified string in the value of an annotation in a 429 message. 431 ANNOTATION 432 Messages that have annotations with entries matching 433 and attributes matching and 434 the specified string in their values are returned in 435 the SEARCH results. The "*" character can be used in the 436 entry or attribute name fields to match any content in those 437 items. The "%" character can be used in the entry or 438 attribute name fields to match a single level of hierarchy 439 only. 441 Examples: 442 C: a SEARCH ANNOTATION "/message/comment" "value" "IMAP4" 443 S: * SEARCH 2 3 5 7 11 13 17 19 23 444 S: a OK Search complete 446 In the above example, the message numbers of any messages 447 containing the string "IMAP4" in the "value" attribute of 448 the "/message/comment" entry are returned in the search 449 results. 451 C: a SEARCH ANNOTATION "*" "*" "IMAP4" 452 S: * SEARCH 1 2 3 5 8 13 21 34 453 S: a OK Search complete 455 In the above example, the message numbers of any messages 456 containing the string "IMAP4" in any attribute of any entry 457 are returned in the search results. 459 A special case exists when the "modifiedsince" attribute is used as 460 the parameter in the ANNOTATION search criterion. 461 In this case the server matches messages when the corresponding 462 "modifiedsince" value is greater than the value supplied in the 463 ANNOTATION criterion. This allows a client, for example, to find 464 out which messages contain annotations that have changed since the 465 last time it updated its disconnected cache. 467 Example: 468 C: a SEARCH ANNOTATION "*" "modifiedsince" "1999101713283412" 469 S: * SEARCH 1 3 6 10 15 21 28 36 45 55 470 S: a OK Search complete 472 In the above example, the message numbers of any messages 473 whose "modifiedsince" attribute of any entry 'exceeds' the 474 value "1999101713283412" are returned in the search results. 476 5.5 ANNOTATION key in SORT 478 The ANNOTATION criterion for the SORT command [SORT-EXT] instructs 479 the server to return the message numbers or UIDs of a mailbox, 480 sorted using the values of the specified annotations. 482 ANNOTATION 483 Messages are sorted using the values of the 484 attributes in the entries. (The charset 485 argument determines sort order, as specified in the SORT 486 extension description.) 488 Examples: 489 C: a SORT (ANNOTATION "/message/subject" "value") UTF-8 ALL 490 S: * SORT 2 3 4 5 1 11 10 6 7 9 8 491 S: a OK Sort complete 493 In the above example, the message numbers of all messages 494 are returned, sorted according to the "value" attribute of 495 the "/message/subject" entry. 497 Note that the ANNOTATION sort key must include a fully specified 498 entry and attribute -- wildcards are not allowed. 500 6 Formal Syntax 502 The following syntax specification uses the Augmented Backus-Naur 503 Form (ABNF) notation as specified in [ABNF]. 505 Non-terminals referenced but not defined below are as defined by 506 [IMAP4]. 508 Except as noted otherwise, all alphabetic characters are case- 509 insensitive. The use of upper or lower case characters to define 510 token strings is for editorial clarity only. Implementations MUST 511 accept these strings in a case-insensitive fashion. 513 fetch-att =/ fetch-annotate 514 ; modifies original IMAP4 fetch-att 516 fetch-annotate = "ANNOTATION" SP "(" entries SP attribs ")" 517 fetch-ann-resp = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")" 519 store-att-flags =/ store-att-annotate 520 ; modifies original IMAP4 STORE command 522 store-att-annotate = "(" entry-att *(SP entry-att) ")" 524 search-key =/ search-annotate 525 ; modifies original IMAP4 search-key 527 search-annotate = "ANNOTATION" SP entry-match SP attrib-match 528 SP value 530 sort-key =/ sort-annotate 531 ; modifies original 532 ; draft-crispin-imapext-sort-xx.txt sort-key 534 sort_annotate = "ANNOTATION" SP entry SP attrib 535 entries = entry-match / 536 "(" entry-match *(SP entry-match) ")" 537 attribs = attrib-match / 538 "(" attrib-match *(SP attrib-match) ")" 539 entry-att = entry SP "(" att-value *(SP att-value) ") 540 att-value = attrib SP value 542 atom-slash = any ATOM_CHAR except "/" 543 atom-dot = any ATOM_CHAR except "." 545 entry = DQUOTE 1*atom-slash *("/" 1*atom-slash) DQUOTE 546 entry-match = DQUOTE 1*entry-match-atom 547 *("/" 1*entry-match-atom) DQUOTE 548 entry-match-atom = 1*(list-wildcards / atom-slash) 549 *(list-wildcards / atom-slash) 551 attrib = DQUOTE 1*atom-dot *("/" 1*atom-dot) DQUOTE 552 attrib-match = DQUOTE 1*attrib-match-atom 553 *("/" 1*attrib-match-atom) DQUOTE 554 attrib-match-atom = 1*(list-wildcards / atom-dot) 555 *(list-wildcards / atom-dot) 557 value = nstring 559 7 IANA Considerations 561 Both entry names and attribute names MUST be specified in a 562 standards track or IESG approved experimental RFC, or fall under the 563 vendor namespace. Vendor names MUST be registered. 565 7.1 Entry and Attribute Registration Template 567 To: iana@iana.org 568 Subject: IMAP Annotate Registration 570 Please register the following IMAP Annotate item: 572 [] Entry [] Attribute 573 [] Vendor [] Open: RFC _______ 575 Name: ______________________________ 577 Description: _______________________ 579 ____________________________________ 581 ____________________________________ 583 Contact person: ____________________ 585 email: ____________________ 587 8 Security Considerations 589 There are no known security issues with this extension. 591 9 References 593 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 594 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 595 November 1997. 597 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 598 4rev1", RFC 2060, University of Washington, December 1996. 600 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 601 Requirement Levels", RFC 2119, Harvard University, March 1997. 603 [SORT-EXT] Crispin, M., "Internet Message Access Protocol -- SORT 604 Extension", work in progress. 605 607 Cyrus Daboo 608 Cyrusoft International, Inc. 609 Suite 780, 5001 Baum Blvd. 610 Pittsburgh, PA 15213 611 U.S.A. 613 Phone: +1 412 605 0499 614 Email: daboo@cyrusoft.com 616 Randall Gellens 617 QUALCOMM Incorporated 618 5775 Morehouse Dr. 619 San Diego, CA 92121-2779 620 U.S.A. 622 Phone: +1 858 651 5115 623 Email: randy@qualcomm.com 625 10 Full Copyright Statement 627 Copyright (C) The Internet Society 2000. All Rights Reserved. 629 This document and translations of it may be copied and furnished to 630 others, and derivative works that comment on or otherwise explain it 631 or assist in its implementation may be prepared, copied, published 632 and distributed, in whole or in part, without restriction of any 633 kind, provided that the above copyright notice and this paragraph 634 are included on all such copies and derivative works. However, this 635 document itself may not be modified in any way, such as by removing 636 the copyright notice or references to the Internet Society or other 637 Internet organizations, except as needed for the purpose of 638 developing Internet standards in which case the procedures for 639 copyrights defined in the Internet Standards process must be 640 followed, or as required to translate it into languages other than 641 English. 643 The limited permissions granted above are perpetual and will not be 644 revoked by the Internet Society or its successors or assigns. 646 This document and the information contained herein is provided on an 647 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 648 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 649 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 650 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 651 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.