idnits 2.17.1 draft-ietf-lemonade-vfolder-01.txt: -(423): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(424): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(425): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. ** 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC3501]), 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The DELETE Command (RFC 3501 section 6.3.4) offers a special problem if a mailbox is deleted while there are vfolders onto that mailbox. Servers MUST NOT show messages in deleted mailboxes to clients. If a DELETE command deletes a mailbox, existing vfolders which reference the mailbox should be deleted and not appear in future LIST commands. If a client has a vfolder currently SELECTed, the server MUST not show any messages. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: SETACL can be used to set access control lists on vfolders, just like on mailboxes. The i right (COPY/APPEND) MAY or MAY NOT be granted on a view. -- 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 (May 2006) is 6550 days in the past. Is this intentional? 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: 'RFC2119' is mentioned on line 52, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 357, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'P-IMAP' is mentioned on line 422, but not defined == Unused Reference: 'ACL' is defined on line 368, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 393, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-melnikov-imap-ext-abnf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNFEXTEND' -- Possible downref: Normative reference to a draft: ref. 'CREATEPARAM' ** Downref: Normative reference to an Informational draft: draft-melnikov-imap-disc (ref. 'IMAP-DISC') -- No information found for draft-ietf-imapext-list-extensions-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LISTEXT' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- No information found for draft-maes-lemonade-search-within - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'WITHIN' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Lemonade 2 Internet Draft: VFOLDER S. H. Maes 3 Document: draft-ietf-lemonade-vfolder-01 R. Cromwell 4 A. Srivastava 5 A. Gulbrandsen 6 Eds. 8 Expires: November 2006 May 2006 10 Persistent Virtual Folder extension to the IMAP Protocol 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 30, 2006. 37 Abstract 39 Persistent Extensions to the IMAP Protocol (LPSEARCH) defines 40 extension parameters to the [RFC3501] CREATE command to allow virtual 41 mailboxes to be created which are views of other mailboxes narrowed 42 by search criteria. 44 Conventions used in this document 46 In examples, "C:" and "S:" indicate lines sent by the client and 47 server respectively. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 An implementation is not compliant if it fails to satisfy one or more 54 of the MUST or REQUIRED level requirements for the protocol(s) it 55 implements. An implementation that satisfies all the MUST or REQUIRED 56 level and all the SHOULD level requirements for a protocol is said to 57 be "unconditionally compliant" to that protocol; one that satisfies 58 all the MUST level requirements but not all the SHOULD level 59 requirements is said to be "conditionally compliant." When 60 describing the general syntax, some definitions are omitted as they 61 are defined in [RFC3501]. 63 Table of Contents 65 Status of this Memo...............................................1 66 Abstract..........................................................1 67 Conventions used in this document.................................1 68 Table of Contents.................................................2 69 1. Introduction................................................2 70 2. VFOLDER semantics...........................................3 71 3. VFOLDER Capability..........................................4 72 4. CREATE Command Extension....................................4 73 5. Response Codes..............................................4 74 A.1. BADBACKING................................................4 75 A.2. BADSEARCH.................................................5 76 6. Formal Syntax...............................................5 77 7. Examples....................................................5 78 8. Message and Mailbox changes.................................6 79 9. List Extension..............................................7 80 10. ACL.........................................................7 81 A. Avoiding Duplicates (Informative)...........................8 82 Security Considerations...........................................8 83 Normative References..............................................8 84 Future Work.......................................................9 85 Version History...................................................9 86 Acknowledgments..................................................10 87 Authors Addresses................................................10 88 Intellectual Property Statement..................................11 89 Disclaimer of Validity...........................................11 90 Copyright Statement..............................................11 92 1. Introduction 93 The VFOLDER extension is present in any IMAP4 implementation which 94 returns "VFOLDER" as one of the supported capabilities in the 95 CAPABILITY command. 97 A virtual folder (vfolder) is an IMAP4 folder with attached search 98 criteria. A new CREATE parameter allows clients to specify a backing 99 mailbox and search criteria, such that messages in the backing 100 mailbox which satisfy the search criteria are shown in the vfolder. 101 Once created, operations applied to the virtual mailbox, such as 102 APPEND and STORE, may be applied to the backing mailbox. For all 103 intents and purposes, the virtual folder looks and behaves like a 104 real IMAP4 folder, except that it does not contain any messages 105 itself. 107 The intent of this extension is to provide efficient access to 108 potentially large or high velocity mailboxes, for all clients, 109 particularly resource restricted mobile clients. 111 VFOLDER also defines two new response codes and if [LISTEXT] is 112 supported, it defines 1 new selection option and 1 new return option. 114 2. VFOLDER semantics 116 When a change is made to the backing mailbox, such as the deposit of 117 a new message, or the mutation of a dynamic message attribute, the 118 change must pass the search criteria of the virtual folder before 119 being visible in it. 121 Changes made to dynamic attributes of messages in a vfolder are 122 propagated to the backing mailbox (e.g. STORE) APPEND/COPY to a 123 vfolder SHOULD be supported as well, but may not on some 124 implementations. 126 From the client's perspective, a vfolder should appear to function as 127 a regular mailbox. This includes the ability for a new virtual folder 128 to be created by using another virtual folder as a backing mailbox. 130 A VFOLDER search MUST NOT reference session dependent keys such as 131 MSN sequence sets, NEW, OLD, and RECENT. A VFOLDER implementation MAY 132 permit search on dynamic message attributes (e.g. flags) but clients 133 should not assume support without checking for BADSEARCH response 134 codes. 136 If a server does support search on dynamic attributes, the 137 possibility arises that a message may be included in a vfolder, 138 excluded, and then included again. When this happens, the server MUST 139 generate a new UID each time, and this implies that the order of 140 messages in a vfolder need not match the underlying order of the 141 backing mailbox. VFOLDER aware clients may wish to try and detect 142 this case and prevent duplicate downloads. 144 The VFOLDER extension makes a message appear in multiple 145 "mailboxes" at a time; one actual mailbox and zero or more views. 146 Messages can also disappear and reappear in views. This complicates 147 the semantics of the \Recent pseudoflag considerably. To simplify 148 implementation, the server MAY omit computing any \Recent pseudoflag 149 for view mailboxes. In that case, a message is only \Recent when 150 viewed in the underlying mailbox. If it does compute \Recent, it 151 should present the view exactly as an ordinary mailbox. 153 3. VFOLDER Capability 155 A server which supports LVFOLDER returns "VFOLDER" as one of the 156 responses of the CAPABILITY command. VFOLDER adheres to [CREATEPARAM] 157 and [ABNFEXTEND] syntax so a server MAY also wish to report 158 additional capabilities for extended CREATE. 160 4. CREATE Command Extension 162 Arguments: mailbox name 163 Optional "VFOLDER" backing mailbox name & 164 search criteria 166 Responses: optional NO responses BADSEARCH, BADBACKING 167 Result: OK created lpsearch completed 168 NO can't create mailbox with that name 169 BAD command unknown or arguments invalid 171 All of the semantics of CREATE as defined in 6.3.3 of [RFC3501] 172 must hold. Additionally, if the backing mailbox name doesn't exist, 173 the creation MUST fail with a NO result and BADBACKING response code. 175 If the search criteria are invalid because the search references 176 search keys which cannot be used (e.g. session dependent keys like 177 NEW, OLD, RECENT) or because the server deems a persistent search on 178 those keys too expensive or not implemented (e.g. mailbox flags), 179 BADSEARCH must be reported with a NO response, or if the SEARCH 180 contains an error in one of its argument values, a NO with a 181 BADSEARCH response is returned. The response SHOULD provide enough 182 explanation to allow a user to correct the search. 184 5. Response Codes 185 A.1. 186 BADBACKING 187 The mailbox name used for the backing mailbox doesn't exist. 189 A.2. 190 BADSEARCH 191 The search criteria violates the pre-conditions mentioned in 192 section 2, or some of the arguments of the search are invalid. 194 6. Formal Syntax 196 The following syntax specification uses the Augmented Backus-Naur 197 Form (ABNF) notation. Elements not defined here can be found in 198 the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. 200 The create ABNF grammar in [RFC3501] is hereby modified to the 201 grammar defined in [ABNFEXTEND]. An additional CREATE param "VFOLDER" 202 is introduced whose value is a list containing the backing store 203 mailbox and the search parameters. 205 create_param =/ "VFOLDER" SP "(" backing-mailbox psearch ")" 206 ;; conforms to generic "create-param" syntax as 207 defined in [ABNFEXTEND] 209 backing-mailbox = mailbox 211 psearch = search-program 212 ; defined in [ABNFEXTEND] 213 ; RECENT, NEW, and OLD should not be used. 215 option-extension =/ "VFOLDER" 216 ; option-extension is in [LISTEXT] 218 vfolder-extended-item = "VFOLDER" SP "(" mailbox SP nstring ")" 220 7. Examples 222 C: a1 CREATE lemonade (VFOLDER(INBOX HEADER "Sender" "lemonade- 223 bounces")) 224 S: a1 OK CREATE VFOLDER Completed 226 Create a persistent mailbox which shows only messages sent to 227 lemonade mailing list. 229 C: a2 CREATE mobile (VFOLDER(INBOX FROM "boss@mycompany.com")) 230 S: a2 OK CREATE VFOLDER Completed 232 Create a mailbox to be synchronized (not in scope of this 233 document) with a mobile device. 235 C: a2 CREATE mobile (VFOLDER (INBOX FROM "boss@mycompany.com" WITHIN 236 3)) 237 S: a2 OK CREATE LPSEARCH Completed 239 Create a mailbox that contains all messages from 240 boss@mycompany.com that were sent within the last 3 days according to 241 the time of the server, utilizing the [WITHIN] draft extension. 243 C: a3 CREATE foo (VFOLDER (IMBOX FROM "boss@mycompany.com")) 244 S: a3 NO [BADBACKING] CREATE failed. IMBOX is not a valid mailbox. 246 Attempt to create a mailbox with a non-existent backing mailbox 247 (fail) 249 C: a3 CREATE foo (VFOLDER (INBOX RECENT)) 250 S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to session 251 dependent properties. 253 Attempt to create a mailbox with a search based on session 254 dependent keys. 256 C: a3 CREATE foo (VFOLDER (INBOX UNSEEN)) 257 S: a3 NO [BADSEARCH] CREATE failed. SEARCH refers to message flags. 258 VFOLDER with dynamic attributes not implemented by this server. 260 8. Message and Mailbox changes 262 The DELETE Command (RFC 3501 section 6.3.4) offers a special problem 263 if a mailbox is deleted while there are vfolders onto that mailbox. 264 Servers MUST NOT show messages in deleted mailboxes to clients. If a 265 DELETE command deletes a mailbox, existing vfolders which reference 266 the mailbox should be deleted and not appear in future LIST commands. 267 If a client has a vfolder currently SELECTed, the server MUST not 268 show any messages. 270 The RENAME Command (RFC 3501 section 6.3.5) has a similar problem: 271 If a mailbox is renamed, what happens to views onto that mailbox? The 272 server MAY treat it in the same way as a DELETE command by removing 273 all vfolders attached to the old mailbox name, OR it MAY track the 274 new name and modify all dependent vfolders to use the new folder 275 name. 277 The APPEND Command (RFC 3501 section 6.3.11) and the COPY Command 278 (RFC 3501 section 6.4.7) MAY be used to append/copy messages to 279 vfolder, depending on the implementation. A NO response should be 280 generated if the server lacks APPEND/COPY support on VFOLDER. 282 The LIST Command (RFC 3501 section 6.3.8) MUST tag vfolders with the 283 new \Vfolder mailbox flag. (LIST is also described below.) 285 The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying 286 mailbox to be expunged when a view is expunged. Servers SHOULD 287 expunge only the messages visible in the view, or MAY expunge the 288 entire mailbox. The former is more desirable, if possible. 290 The IDLE command should treat vfolders the same as any normal 291 mailbox. When new messages arrive, or messages are expunged, an 292 untagged response MUST be sent to the client just as it would if the 293 backing mailbox was selected. 295 9. List Extension 297 If the server also supports [LISTEXT], a client can find existing 298 vfolders, and can read the search expression for an existing vfolder. 300 The selection option vfolder instructs the server to return LIST 301 responses only for vfolders. 303 The return option vfolders instructs the server to include the view's 304 search and underlying mailbox in a LIST response. 306 Some servers MAY elect to hide vfolders by default so that non- 307 vfolder aware clients cannot see them. In such cases, if a client 308 uses the vfolder selection option, the server MUST return responses 309 with vfolders. 311 10. ACL 313 SETACL can be used to set access control lists on vfolders, just like 314 on mailboxes. The i right (COPY/APPEND) MAY or MAY NOT be granted on 315 a view. 317 LISTRIGHTS acts as for mailboxes. 319 MYRIGHTS computes access as for mailboxes. However, it may or may 320 not consider the underlying mailbox ACL, depending on how a server 321 implements VFOLDER. 323 If it considers the underlying mailbox ACL, the ACL on a mailbox 324 controls all access to the messages stored there. From a security 325 perspective, this may be considered an advantage. 327 If it works independently of the underlying mailbox ACL, vfolders can 328 be used to selectively grant access to a few messages in a mailbox. 329 This can also be viewed as a security advantage, since it allows 330 more finegrained access control. 332 A. Avoiding Duplicates (Informative) 334 With the introduction of VFOLDER, two problems arise. First, a 335 message may appear in one or more vfolders as well as the backing 336 mailbox. Clients may wish to prevent the duplicate retrieval of such 337 messages. Secondly, it is possible for a message to appear, 338 disappear, and reappear in a VFOLDER, which causes the message to be 339 assigned a new UID by the server. This may result in unnecessary 340 duplication of message on a client, may confuse users, and may 341 interfere with notification mechanisms. 343 Clients wishing to check if a message is a duplicate at this point 344 may have to fetch message headers of new message and compare that 345 against the local client cache of messages. This may require some 346 reasonable persistence of deleted messages in the cache. See [IMAP- 347 DISC] section 4.2.2.1 for a discussion of a possible technique. 349 Future versions of VFOLDER may introduce a new server supported 350 mechanism for efficiently determining the original mailbox and UID of 351 a message 353 Security Considerations 355 The VFOLDER extension does not raise any security considerations 356 which are not present in the base protocol. Considerations are the 357 same as for IMAP [RFC 3501]. 359 Normative References 361 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 362 ABNF", RFC 4234, October 2005. 363 http://www.ietf.org/rfc/rfc4234 365 [ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to 366 IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 368 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) 369 Extension", RFC 4314, Isode Ltd., December 2005. 371 [CREATEPARAM] Melnikov, A., "IMAP CREATE/RENAME parameters", draft- 372 melnikov-imap-createparams-01.txt, September 2005. 374 [IMAP-DISC] Melnikov, A. " Synchronization operations for 375 disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, October 376 2004. 377 [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command 378 Extensions", work in progress, draft-ietf-imapext-list- 379 extensions-xx.txt. 381 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 382 Version 4 rev1", RFC 3501, March 2003. 383 http://www.ietf.org/rfc/rfc3501 385 [WITHIN] Maes, S.H., Cromwell, R., "WITHIN Search extension to the 386 IMAP Protocol", draft-maes-lemonade-search-within-02.txt, May 2006 388 Future Work 390 [1] Determine what, if any, of VIEW and VFOLDER's former restrictions 391 on search parameters must be restored. 392 [2] Better solution for the duplicate download problem 393 [3] Tighten semantics and defined behavior, promoting some MAY or 394 SHOULD to MUST. 396 Version History 398 Release 04 399 Overhauled since last IETF Plenary. Merged Arnt Gulbrandsen's VIEW 400 draft with VFOLDER 03 draft. Release 04 represents a superset, 401 with some of both VFOLDER and VIEW's restrictions removed. 402 Release 03 403 Separate SEARCH extension to separate draft 404 Release 02 405 Update to address comments from Alexey Melnikov, and a new 406 restricted model using immutable message properties 407 Release 01 408 Update to address comments from Alexey Melnikov to follow 409 appropriately the generic syntax provided in draft-melnikov-imap-ext- 410 abnf-05.txt. 411 Release 00 412 Initial release 414 Acknowledgments 416 We want to give a special thanks to A. Melnikov for his review and 417 suggestions, and to thank Arnt Gulbrandsen for his excellent VIEW 418 proposal, which has now been merged with VFOLDER. 420 The authors want to thank all who have contributed key insight and 421 extensively reviewed and discussed the concepts of LPSEARCH and its 422 early introduction P-IMAP [P-IMAP]. In particular, this includes the 423 authors of the P-IMAP draft: Rafiul Ahad � Oracle Corporation, Eugene 424 Chiu � Oracle Corporation, Ray Cromwell � Oracle Corporation, Jia-der 425 Day � Oracle Corporation, Vi Ha � Oracle Corporation, Wook-Hyun Jeong 426 � Samsung Electronics Co. LTF, Chang Kuang � Oracle Corporation, 427 Rodrigo Lima � Oracle Corporation, Stephane H. Maes � Oracle 428 Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini � Symbol 429 Technologies, Sung-Mu Son � LG Electronics, Fan Xiaohui - CHINA 430 MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE 431 COMMUNICATIONS CORPORATION (CMCC). 433 Authors Addresses 435 Stephane H. Maes 436 Oracle Corporation 437 500 Oracle Parkway 438 M/S 4op634 439 Redwood Shores, CA 94065 440 USA 441 Phone: +1-650-607-6296 442 Email: stephane.maes@oracle.com 444 Ray Cromwell 445 Oracle Corporation 446 500 Oracle Parkway 447 Redwood Shores, CA 94065 448 USA 450 Arnt Gulbrandsen 451 Oryx Mail Systems GmbH 452 Schweppermannstr. 8 453 D-81671 Muenchen 454 Germany 455 Anil Srivastava 456 Sun Microsystems 457 4150 Network Circle SCA15/201 458 Santa Clara, CA 94065 459 anil.srivastava@sun.com 461 Intellectual Property Statement 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at ietf- 483 ipr@ietf.org. 485 Disclaimer of Validity 487 This document and the information contained herein are provided on an 488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 490 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 491 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 492 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Copyright Statement 497 Copyright (C) The Internet Society (2006). This document is subject 498 to the rights, licenses and restrictions contained in BCP 78, and 499 except as set forth therein, the authors retain all their rights. 501 Acknowledgement 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.