idnits 2.17.1 draft-ietf-ldapext-ldapv3-vlv-05.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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 163 has weird spacing: '...mate of the ...' == Line 165 has weird spacing: '...browses the ...' == Line 166 has weird spacing: '...because the c...' == Line 168 has weird spacing: '...rver as ratio...' == Line 190 has weird spacing: '... client sendi...' == (6 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8198 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) -- Looks like a reference, but probably isn't: '0' on line 244 -- Looks like a reference, but probably isn't: '1' on line 247 ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 2696 (ref. 'SPaged') Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Boreham, Bozeman Pass 2 LDAPext Working Group J. Sermersheim, Novell 3 Category: Standards Track A. Anantha, Microsoft 4 M. Armijo, Microsoft 5 Expires: May 2002 A. Kashi, Microsoft 6 November 2001 8 LDAP Extensions for Scrolling View Browsing of Search Results 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is intended to be submitted, after review and 32 revision, as a Standards Track document. Distribution of this memo 33 is unlimited. It is filed as , and expires May, 2002. 36 Please send comments to the authors. 38 2. Abstract 40 This document describes a Virtual List View control extension for 41 the Lightweight Directory Access Protocol (LDAP) Search operation. 42 This control is designed to allow the "virtual list box" feature, 43 common in existing commercial e-mail address book applications, to 44 be supported efficiently by LDAP servers. LDAP servers' inability to 45 support this client feature is a significant impediment to LDAP 46 replacing proprietary protocols in commercial e-mail systems. 48 LDAP Extensions for Scrolling View November 2001 49 Browsing of Search Results 51 The control allows a client to specify that the server return, for a 52 given LDAP search with associated sort keys, a contiguous subset of 53 the search result set. This subset is specified in terms of offsets 54 into the ordered list, or in terms of a greater than or equal 55 comparison value. 57 3. Conventions used in this document 58 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', 59 ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and 60 ``MAY'' in this document are to be interpreted as described in RFC 61 2119 [Bradner97]. 63 4. Background 65 A Virtual List is a graphical user interface technique employed 66 where ordered lists containing a large number of entries need to be 67 displayed. A window containing a small number of visible list 68 entries is drawn. The visible portion of the list may be relocated 69 to different points within the list by means of user input. This 70 input can be to a scroll bar slider; from cursor keys; from page 71 up/down keys; from alphanumeric keys for "typedown". The user is 72 given the impression that they may browse the complete list at will, 73 even though it may contain millions of entries. It is the fact that 74 the complete list contents are never required at any one time that 75 characterizes Virtual List View. Rather than fetch the complete 76 list from wherever it is stored (typically from disk or a remote 77 server), only that information which is required to display the part 78 of the list currently in view is fetched. The subject of this 79 document is the interaction between client and server required to 80 implement this functionality in the context of the results from a 81 sorted LDAP search request. 83 For example, suppose an e-mail address book application displays a 84 list view onto the list containing the names of all the holders of 85 e-mail accounts at a large university. The list is sorted 86 alphabetically. While there may be tens of thousands of entries in 87 this list, the address book list view displays only 20 such accounts 88 at any one time. The list has an accompanying scroll bar and text 89 input window for type-down. When first displayed, the list view 90 shows the first 20 entries in the list, and the scroll bar slider is 91 positioned at the top of its range. Should the user drag the slider 92 to the bottom of its range, the displayed contents of the list view 93 should be updated to show the last 20 entries in the list. 94 Similarly, if the slider is positioned somewhere in the middle of 95 its travel, the displayed contents of the list view should be 96 updated to contain the 20 entries located at that relative position 97 within the complete list. Starting from any display point, if the 98 user uses the cursor keys or clicks on the scroll bar to request 99 that the list be scrolled up or down by one entry, the displayed 100 contents should be updated to reflect this. Similarly the list 101 should be displayed correctly when the user requests a page scroll 102 LDAP Extensions for Scrolling View November 2001 103 Browsing of Search Results 105 up or down. Finally, when the user types characters in the type- 106 down window, the displayed contents of the list should "jump" or 107 "seek" to the appropriate point within the list. For example, if 108 the user types "B", the displayed list could center around the first 109 user with a name beginning with the letter "B". When this happens, 110 the scroll bar slider should also be updated to reflect the new 111 relative location within the list. 113 This document defines a request control which extends the LDAP 114 search operation. Always used in conjunction with the server side 115 sorting control [SSS], this allows a client to retrieve selected 116 portions of large search result set in a fashion suitable for the 117 implementation of a virtual list view. 119 5. Client-Server Interaction 121 The Virtual List View control extends a regular LDAP Search 122 operation which must also include a server-side sorting control 123 [SSS]. Rather than returning the complete set of appropriate 124 SearchResultEntry messages, the server is instructed to return a 125 contiguous subset of those entries, taken from the sorted result 126 set, centered around a particular target entry. Henceforth, in the 127 interests of brevity, the sorted search result set will be referred 128 to as "the list". 130 The sort control MAY contain any sort specification valid for the 131 server. The attributeType field in the first SortKeyList sequence 132 element has special significance for "typedown". 134 The desired target entry and the number of entries to be returned, 135 both before and after that target entry in the list, are determined 136 by the client's VirtualListViewRequest control. 138 When the server returns the set of entries to the client, it 139 attaches a VirtualListViewResponse control to the SearchResultDone 140 message. The server returns in this control: its current estimate 141 for the list content count, the location within the list 142 corresponding to the target entry, and any error codes. 144 The target entry is specified in the VirtualListViewRequest control 145 by one of two methods. The first method is for the client to 146 indicate the target entry's offset within the list. The second way 147 is for the client to supply an attribute assertion value. The value 148 is compared against the values of the attribute specified as the 149 primary sort key in the sort control attached to the search 150 operation. The first sort key in the SortKeyList is the primary 151 sort key. The target entry is the first entry in the list with 152 value greater than or equal to (in the primary sort order), the 153 presented value. The order is determined by rules defined in [SSS]. 154 Selection of the target entry by this means is designed to implement 155 "typedown". Note that it is possible that no entry satisfies these 156 LDAP Extensions for Scrolling View November 2001 157 Browsing of Search Results 159 conditions, in which case there is no target entry. This condition 160 is indicated by the server returning the special value contentCount 161 + 1 in the target position field. 163 Because the server may not have an accurate estimate of the number 164 of entries in the list, and to take account of cases where the list 165 size is changing during the time the user browses the list, and 166 because the client needs a way to indicate specific list 167 targets "beginning" and "end", offsets within the list are 168 transmitted between client and server as ratios---offset to 169 content count. The server sends its latest estimate as to the number 170 of entries in the list (content count) to the client in every 171 response control. The client sends its assumed value for the 172 content count in every request control. The server examines the 173 content count and offsets presented by the client and computes the 174 corresponding offsets within the list, based on its own idea of the 175 content count. 177 Si = Sc * (Ci / Cc) 179 Where: 180 Si is the actual list offset used by the server 181 Sc is the server's estimate for content count 182 Ci is the client's submitted offset 183 Cc is the client's submitted content count 184 The result is rounded to the nearest integer. 186 If the content count is stable, and the client returns to the server 187 the content count most recently received, Cc = Sc and the offsets 188 transmitted become the actual server list offsets. 190 The following special cases are allowed: a client sending a 191 content count of zero (Cc = 0) means "client has no idea what the 192 content count is, server MUST use its own content count estimate 193 in place of the client's". An offset value of one (Ci = 1) 194 always means that the target is the first entry in the list. Client 195 specifying an offset which equals the content count specified in the 196 same request control (Ci = Cc) means that the target is the last 197 entry in the list. Ci may only equal zero when Cc is also zero. 198 This signifies the last entry in the list. 200 Because the server always returns contentCount and targetPosition, 201 the client can always determine which of the returned entries is the 202 target entry. Where the number of entries returned is the same as 203 the number requested, the client is able to identify the target by 204 simple arithmetic. Where the number of entries returned is not the 205 same as the number requested (because the requested range crosses 206 the beginning or end of the list, or both), the client must use the 207 target position and content count values returned by the server to 208 identify the target entry. For example, suppose that 10 entries 209 before and 10 after the target were requested, but the server 210 returns 13 entries, a content count of 100 and a target position of 211 LDAP Extensions for Scrolling View November 2001 212 Browsing of Search Results 214 3. The client can determine that the first entry must be entry 215 number 1 in the list, therefore the 13 entries returned are the 216 first 13 entries in the list, and the target is the third one. 218 A server-generated context identifier MAY be returned to clients. A 219 client receiving a context identifier SHOULD return it unchanged in 220 a subsequent request which relates to the same list. The purpose of 221 this interaction is to enhance the performance and effectiveness of 222 servers which employ approximate positioning. 224 6. The Controls 226 Support for the virtual list view control extension is indicated by 227 the presence of the OID "2.16.840.1.113730.3.4.9" in the 228 supportedControl attribute of a server's root DSE. 230 6.1. Request Control 232 This control is included in the SearchRequest message as part of the 233 controls field of the LDAPMessage, as defined in Section 4.1.12 of 234 [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The 235 criticality SHOULD be set to TRUE. If this control is included in a 236 SearchRequest message, a Server Side Sorting request control [SSS] 237 MUST also be present in the message. The controlValue is an OCTET 238 STRING whose value is the BER-encoding of the following SEQUENCE: 240 VirtualListViewRequest ::= SEQUENCE { 241 beforeCount INTEGER (0..maxInt), 242 afterCount INTEGER (0..maxInt), 243 CHOICE { 244 byoffset [0] SEQUENCE { 245 offset INTEGER (0 .. maxInt), 246 contentCount INTEGER (0 .. maxInt) }, 247 greaterThanOrEqual [1] AssertionValue }, 248 contextID OCTET STRING OPTIONAL } 250 beforeCount indicates how many entries before the target entry the 251 client wants the server to send. afterCount indicates the number of 252 entries after the target entry the client wants the server to send. 253 offset and contentCount identify the target entry as detailed in 254 section 4. greaterThanOrEqual is an attribute assertion value 255 defined in [LDAPv3]. If present, the value supplied in 256 greaterThanOrEqual is used to determine the target entry by 257 comparison with the values of the attribute specified as the primary 258 sort key. The first list entry who's value is no less than (less 259 than or equal to when the sort order is reversed) the supplied value 260 is the target entry. If present, the contextID field contains the 261 value of the most recently received contextID field from a 262 VirtualListViewResponse control. The type AssertionValue and value 263 maxInt are defined in [LDAPv3]. contextID values have no validity 264 outwith the connection on which they were received. That is, a 265 LDAP Extensions for Scrolling View November 2001 266 Browsing of Search Results 268 client should not submit a contextID which it received from another 269 connection, a connection now closed, or a different server. 271 6.2. Response Control 273 This control is included in the SearchResultDone message as part of 274 the controls field of the LDAPMessage, as defined in Section 4.1.12 275 of [LDAPv3]. 277 The controlType is set to "2.16.840.1.113730.3.4.10". The 278 criticality is FALSE (MAY be absent). The controlValue is an OCTET 279 STRING, whose value is the BER encoding of a value of the following 280 SEQUENCE: 282 VirtualListViewResponse ::= SEQUENCE { 283 targetPosition INTEGER (0 .. maxInt), 284 contentCount INTEGER (0 .. maxInt), 285 virtualListViewResult ENUMERATED { 286 success (0), 287 operationsError (1), 288 unwillingToPerform (53), 289 insufficientAccessRights (50), 290 busy (51), 291 timeLimitExceeded (3), 292 adminLimitExceeded (11), 293 sortControlMissing (60), 294 offsetRangeError (61), 295 other (80) }, 296 contextID OCTET STRING OPTIONAL } 298 targetPosition gives the list offset for the target entry. 299 contentCount gives the server's estimate of the current number of 300 entries in the list. Together these give sufficient information for 301 the client to update a list box slider position to match the newly 302 retrieved entries and identify the target entry. The contentCount 303 value returned SHOULD be used in a subsequent VirtualListViewRequest 304 control. contextID is a server-defined octet string. If present, 305 the contents of the contextID field SHOULD be returned to the server 306 by a client in a subsequent VirtualListViewRequest control. 308 The virtualListViewResult codes which are common to the LDAP 309 searchResponse (adminLimitExceeded, timeLimitExceeded, busy, 310 operationsError, unwillingToPerform, insufficientAccessRights) have 311 the same meanings as defined in [LDAPv3], but they pertain 312 specifically to the VLV operation. For example, the server could 313 exceed an administration limit processing a SearchRequest with a 314 VirtualListViewRequest control. However, the same administration 315 limit would not be exceeded should the same SearchRequest be 316 submitted by the client without the VirtualListViewRequest control. 317 In this case, the client can determine that an administration limit 318 has been exceeded in servicing the VLV request, and can if it 319 LDAP Extensions for Scrolling View November 2001 320 Browsing of Search Results 322 chooses resubmit the SearchRequest without the 323 VirtualListViewRequest control. 325 insufficientAccessRights means that the server denied the client 326 permission to perform the VLV operation. 328 If the server determines that the results of the search presented 329 exceed the range provided by the 32-bit offset values, it MUST 330 return offsetRangeError. 332 If the server returns any code other then success (0) for 333 virtualListViewResult, then the server MUST return controlError (76) 334 as the resultCode of the SearchResultDone message. [ctrlErr] 336 7. Protocol Example 338 Here we walk through the client-server interaction for a specific 339 virtual list view example: The task is to display a list of all 340 78564 people in the US company "Ace Industry". This will be done by 341 creating a graphical user interface object to display the list 342 contents, and by repeatedly sending different versions of the same 343 virtual list view search request to the server. The list view 344 displays 20 entries on the screen at a time. 346 We form a search with baseDN "o=Ace Industry, c=us"; search scope 347 subtree; filter "objectClass=inetOrgPerson". We attach a server sort 348 order control to the search, specifying ascending sort on attribute 349 "cn". To this base search, we attach a virtual list view request 350 control with contents determined by the user activity and send the 351 search to the server. We display the results from each search in 352 the list window and update the slider position. 354 When the list view is first displayed, we want to initialize the 355 contents showing the beginning of the list. Therefore, we set 356 beforeCount = 0, afterCount = 19, contentCount = 0, offset = 1 and 357 send the request to the server. The server duly returns the first 358 20 entries in the list, plus the content count = 78564 and 359 targetPosition = 1. We therefore leave the scroll bar slider at its 360 current location (the top of its range). 362 Say that next the user drags the scroll bar slider down to the 363 bottom of its range. We now wish to display the last 20 entries in 364 the list, so we set beforeCount = 19, afterCount = 0, contentCount = 365 78564, offset = 78564 and send the request to the server. The server 366 returns the last 20 entries in the list, plus the content count = 367 78564 and targetPosition = 78564. 369 Next the user presses a page up key. Our page size is 20, so we 370 set beforeCount = 0, afterCount = 19, contentCount = 78564, 371 offset = 78564-19-20 and send the request to the server. The server 372 LDAP Extensions for Scrolling View November 2001 373 Browsing of Search Results 375 returns the preceding 20 entries in the list, plus the content count 376 = 78564 and targetPosition = 78525. 378 Now the user grabs the scroll bar slider and drags it to 68% of the 379 way down its travel. 68% of 78564 is 53424 so we set beforeCount = 380 9, afterCount = 10, contentCount = 78564, offset = 53424 and send 381 the request to the server. The server returns the preceding 20 382 entries in the list, plus the content count = 78564 and 383 targetPosition = 53424. 385 Lastly, the user types the letter "B". We set beforeCount = 9, 386 afterCount = 10 and greaterThanOrEqual = "B". The server finds the 387 first entry in the list not less than "B", let's say "Babs Jensen", 388 and returns the nine preceding entries, the target entry, and the 389 proceeding 10 entries. The server returns content count = 78564 and 390 targetPosition = 5234 and so the client updates its scroll bar 391 slider to 6.7% of full scale. 393 8. Notes for Implementers 395 While the feature is expected to be generally useful for arbitrary 396 search and sort specifications, it is specifically designed for 397 those cases where the result set is very large. The intention is 398 that this feature be implemented efficiently by means of pre- 399 computed indices pertaining to a set of specific cases. For 400 example, an offset relating to "all the employees in the local 401 organization, sorted by surname" would be a common case. 403 The intention for client software is that the feature should fit 404 easily with the host platform's graphical user interface facilities 405 for the display of scrolling lists. Thus the task of the client 406 implementers should be one of reformatting up the requests for 407 information received from the list view code to match the format of 408 the virtual list view request and response controls. 410 Client implementers should note that any offset value returned by 411 the server may be approximate. Do not design clients > which only 412 operate correctly when offsets are exact. 414 Server implementers using indexing technology which features 415 approximate positioning should consider returning context 416 identifiers to clients. The use of a context identifier will allow 417 the server to distinguish between client requests which relate to 418 different displayed lists on the client. Consequently the server can 419 decide more intelligently whether to reposition an existing database 420 cursor accurately to within a short distance of its current 421 position, or to reposition to an approximate position. Thus the 422 client will see precise offsets for "short" repositioning (e.g. 423 paging up or down), but approximate offsets for a "long" reposition 424 (e.g. a slider movement). 426 LDAP Extensions for Scrolling View November 2001 427 Browsing of Search Results 429 Server implementers are free to return status code 430 unwillingToPerform should their server be unable to service any 431 particular VLV search. This might be because the resolution of the 432 search is computationally infeasible, or because excessive server 433 resources would be required to service the search. 435 Client implementers should note that this control is only defined on 436 a client interaction with a single server. If a server returns 437 referrals as a part of its response to the search request, the 438 client is responsible for deciding when and how to apply this 439 control to the referred-to servers, and how to collate the results 440 from multiple servers. 442 9. Relationship to "Simple Paged Results" 444 These controls are designed to support the virtual list view, which 445 has proved hard to implement with the Simple Paged Results mechanism 446 [SPaged]. However, the controls described here support any operation 447 possible with the Simple Paged Results mechanism. The two mechanisms 448 are not complementary; rather one has a superset of the other's 449 features. One area where the mechanism presented here is not a 450 strict superset of the Simple Paged Results scheme is that here we 451 require a sort order to be specified. No such requirement is made 452 for paged results. 454 10. Security Considerations 456 Server implementers may wish to consider whether clients are able to 457 consume excessive server resources in requesting virtual list 458 operations. Access control to the feature itself; configuration 459 options limiting the feature�s use to certain predetermined search 460 base DNs and filters; throttling mechanisms designed to limit the 461 ability for one client to soak up server resources, may be 462 appropriate. 464 Consideration should be given as to whether a client will be able to 465 retrieve the complete contents, or a significant subset of the 466 complete contents of the directory using this feature. This may be 467 undesirable in some circumstances and consequently it may be 468 necessary to enforce some access control. 470 Clients can, using this control, determine how many entries are 471 contained within a portion of the DIT. This may constitute a 472 security hazard. Again, access controls may be appropriate. 474 Server implementers SHOULD exercise caution concerning the content 475 of the contextID. Should the contextID contain internal server 476 state, it may be possible for a malicious client to use that 477 information to gain unauthorized access to information. 479 LDAP Extensions for Scrolling View November 2001 480 Browsing of Search Results 482 11. Acknowledgements 484 Chris Weider of Microsoft co-authored a previous version of this 485 document. 487 12. References 489 [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 490 Access Protocol (v3)", Internet Standard, RFC 2251, 491 December, 1997. 493 [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP 494 Control Extension for Simple Paged Results 495 Manipulation", RFC2696, September 1999. 497 [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control 498 Extension for Server Side Sorting of Search Results", 499 RFC 2891, August, 2000. 501 [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [ctrlErr] Armijo, M. and A. Kashi, �Result Code for LDAP 505 Controls�, Internet-Draft, September, 2001. 506 Work in progress published as: 507 509 13. Authors' Addresses 511 David Boreham 512 Bozeman Pass, Inc 513 +1 406 222 7093 514 david@bozemanpass.com 516 Jim Sermersheim 517 Novell 518 122 East 1700 South 519 Provo, Utah 84606, USA 520 jimse@novell.com 522 Anoop Anantha 523 Microsoft Corporation 524 1 Microsoft Way 525 Redmond, WA 98052, USA 526 +1 425 882-8080 527 anoopa@microsoft.com 529 Michael Armijo 530 LDAP Extensions for Scrolling View November 2001 531 Browsing of Search Results 533 Microsoft Corporation 534 1 Microsoft Way 535 Redmond, WA 98052, USA 536 +1 425 882-8080 537 micharm@microsoft.com 539 Asaf Kashi 540 Microsoft Corporation 541 1 Microsoft Way 542 Redmond, WA 98052, USA 543 +1 425 882-8080 544 asafk@microsoft.com 546 14. Full Copyright Statement 548 Copyright (C) The Internet Society (2001). All Rights Reserved. 549 This document and translations of it may be copied and furnished to 550 others, and derivative works that comment on or otherwise explain it 551 or assist in its implementation may be prepared, copied, published 552 and distributed, in whole or in part, without restriction of any 553 kind, provided that the above copyright notice and this paragraph 554 are included on all such copies and derivative works. However, this 555 document itself may not be modified in any way, such as by removing 556 the copyright notice or references to the Internet Society or other 557 Internet organizations, except as needed for the purpose of 558 developing Internet standards in which case the procedures for 559 copyrights defined in the Internet Standards process must be 560 followed, or as required to translate it into languages other than 561 English. The limited permissions granted above are perpetual and 562 will not be revoked by the Internet Society or its successors or 563 assigns. This document and the information contained herein is 564 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 565 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 566 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 567 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."