idnits 2.17.1 draft-ietf-ldapext-ldapv3-vlv-07.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 is 1 instance 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.) 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 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 (Jun 2002) is 7980 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 242 -- Looks like a reference, but probably isn't: '1' on line 245 ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 5 errors (**), 0 flaws (~~), 3 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 Intended Category: Standards Track A. Kashi, Microsoft 4 5 Expires: Nov Dec 2002 May Jun 2002 7 LDAP Extensions for Scrolling View Browsing of Search Results 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is intended to be submitted, after review and revision, 30 as a Standards Track document. Distribution of this memo is 31 unlimited. 32 Please send comments to the authors. 34 2. Abstract 36 This document describes a Virtual List View control extension for the 37 Lightweight Directory Access Protocol (LDAP) Search operation. This 38 control is designed to allow the "virtual list box" feature, common 39 in existing commercial e-mail address book applications, to be 40 supported efficiently by LDAP servers. LDAP servers' inability to 41 support this client feature is a significant impediment to LDAP 42 replacing proprietary protocols in commercial e-mail systems. 44 The control allows a client to specify that the server return, for a 45 given LDAP search with associated sort keys, a contiguous subset of 46 the search result set. This subset is specified in terms of offsets 47 into the ordered list, or in terms of a greater than or equal 48 comparison value. 50 Boreham et al Internet-Draft 1 51 Browsing of Search Results 53 3. Conventions used in this document 54 The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this 55 document are to be interpreted as described in RFC 2119 [Bradner97]. 57 Protocol elements are described using ASN.1 [X.680]. The term "BER- 58 encoded" means the element is to be encoded using the Basic Encoding 59 Rules [X.690] under the restrictions detailed in Section 5.1 of 60 [LDAPv3]. 62 4. Background 64 A Virtual List is a graphical user interface technique employed where 65 ordered lists containing a large number of entries need to be 66 displayed. A window containing a small number of visible list entries 67 is drawn. The visible portion of the list may be relocated to 68 different points within the list by means of user input. This input 69 can be to a scroll bar slider; from cursor keys; from page up/down 70 keys; from alphanumeric keys for "typedown". The user is given the 71 impression that they may browse the complete list at will, even 72 though it may contain millions of entries. It is the fact that the 73 complete list contents are never required at any one time that 74 characterizes Virtual List View. Rather than fetch the complete list 75 from wherever it is stored (typically from disk or a remote server), 76 only that information which is required to display the part of the 77 list currently in view is fetched. The subject of this document is 78 the interaction between client and server required to implement this 79 functionality in the context of the results from a sorted [SSS] 80 Lightweight Directory Access Protocol (LDAP) [LDAPv3] search request. 82 For example, suppose an e-mail address book application displays a 83 list view onto the list containing the names of all the holders of e- 84 mail accounts at a large university. The list is sorted 85 alphabetically. While there may be tens of thousands of entries in 86 this list, the address book list view displays only 20 such accounts 87 at any one time. The list has an accompanying scroll bar and text 88 input window for type-down. When first displayed, the list view shows 89 the first 20 entries in the list, and the scroll bar slider is 90 positioned at the top of its range. Should the user drag the slider 91 to the bottom of its range, the displayed contents of the list view 92 should be updated to show the last 20 entries in the list. Similarly, 93 if the slider is positioned somewhere in the middle of its travel, 94 the displayed contents of the list view should be updated to contain 95 the 20 entries located at that relative position within the complete 96 list. Starting from any display point, if the user uses the cursor 97 keys or clicks on the scroll bar to request that the list be scrolled 98 up or down by one entry, the displayed contents should be updated to 99 reflect this. Similarly the list should be displayed correctly when 100 the user requests a page scroll up or down. Finally, when the user 101 types characters in the type-down window, the displayed contents of 102 the list should "jump" or "seek" to the appropriate point within the 104 Boreham et al Internet-Draft 2 105 Browsing of Search Results 107 list. For example, if the user types "B", the displayed list could 108 center around the first user with a name beginning with the letter 109 "B". When this happens, the scroll bar slider should also be updated 110 to reflect the new relative location within the list. 112 This document defines a request control which extends the LDAP search 113 operation. Always used in conjunction with the server side sorting 114 control [SSS], this allows a client to retrieve selected portions of 115 large search result set in a fashion suitable for the implementation 116 of a virtual list view. 118 5. Client-Server Interaction 120 The Virtual List View control extends a regular LDAP Search operation 121 which MUSTmust also include a server-side sorting control [SSS]. 122 Rather than returning the complete set of appropriate 123 SearchResultEntry messages, the server is instructed to return a 124 contiguous subset of those entries, taken from the sorted result set, 125 centered around a particular target entry. Henceforth, in the 126 interests of brevity, the sorted search result set will be referred 127 to as "the list". 129 The sort control may contain any sort specification valid for the 130 server. The attributeType field in the first SortKeyList sequence 131 element has special significance for "typedown". 133 The desired target entry and the number of entries to be returned, 134 both before and after that target entry in the list, are determined 135 by the client's VirtualListViewRequest control. 137 When the server returns the set of entries to the client, it attaches 138 a VirtualListViewResponse control to the SearchResultDone message. 139 The server returns in this control: its current estimate for the list 140 content count, the location within the list corresponding to the 141 target entry, any error codes, and optionally a context identifier. 143 The target entry is specified in the VirtualListViewRequest control 144 by one of two methods. The first method is for the client to indicate 145 the target entry's offset within the list. The second way is for the 146 client to supply an attribute assertion value. The value is compared 147 against the values of the attribute specified as the primary sort key 148 in the sort control attached to the search operation. The first sort 149 key in the SortKeyList is the primary sort key. The target entry is 150 the first entry in the list with value greater than or equal to (in 151 the primary sort order), the presented value. The order is determined 152 by rules defined in [SSS]. Selection of the target entry by this 153 means is designed to implement "typedown". Note that it is possible 154 that no entry satisfies these conditions, in which case there is no 155 target entry. This condition is indicated by the server returning the 156 special value contentCount + 1 in the target position field. 158 Boreham et al Internet-Draft 3 159 Browsing of Search Results 161 Because the server may not have an accurate estimate of the number of 162 entries in the list, and to take account of cases where the list size 163 is changing during the time the user browses the list, and because 164 the client needs a way to indicate specific list targets "beginning" 165 and "end", offsets within the list are transmitted between client and 166 server as ratios---offset to content count. The server sends its 167 latest estimate as to the number of entries in the list (content 168 count) to the client in every response control. The client sends its 169 assumed value for the content count in every request control. The 170 server examines the content count and offsets presented by the client 171 and computes the corresponding offsets within the list, based on its 172 own idea of the content count. 174 Si = Sc * (Ci / Cc) 176 Where: 177 Si is the actual list offset used by the server 178 Sc is the server's estimate for content count 179 Ci is the client's submitted offset 180 Cc is the client's submitted content count 181 The result is rounded to the nearest integer. 183 If the content count is stable, and the client returns to the server 184 the content count most recently received, Cc = Sc and the offsets 185 transmitted become the actual server list offsets. 187 The following special cases exist when the client is specifying the 188 offset and content count: 189 - an offset of one and a content count of non-one (Ci = 1, Cc != 1) 190 indicates that the target is the first entry in the list. 191 - equivalent values (Ci = Cc) indicate that the target is the last 192 entry in the list. 193 - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0) 194 means the client has no idea what the content count is, the server 195 MUST use its own content count estimate in place of the client's. 197 Because the server always returns contentCount and targetPosition, 198 the client can always determine which of the returned entries is the 199 target entry. Where the number of entries returned is the same as the 200 number requested, the client is able to identify the target by simple 201 arithmetic. Where the number of entries returned is not the same as 202 the number requested (because the requested range crosses the 203 beginning or end of the list, or both), the client MUSTmust use the 204 target position and content count values returned by the server to 205 identify the target entry. For example, suppose that 10 entries 206 before and 10 after the target were requested, but the server returns 207 13 entries, a content count of 100 and a target position of 3. The 208 client can determine that the first entry must be entry number 1 in 209 the list, therefore the 13 entries returned are the first 13 entries 210 in the list, and the target is the third one. 212 Boreham et al Internet-Draft 4 213 Browsing of Search Results 215 A server-generated context identifier MAY be returned to clients. A 216 client receiving a context identifier MUST return it unchanged, or 217 not return it at all in a subsequent request which relates to the 218 same list. The purpose of this interaction is to enhance the 219 performance and effectiveness of servers which employ approximate 220 positioning. 222 6. The Controls 224 Support for the virtual list view control extension is indicated by 225 the presence of the OID "2.16.840.1.113730.3.4.9" in the 226 supportedControl attribute of a server's root DSE. 228 6.1. Request Control 230 This control is included in the SearchRequest message as part of the 231 controls field of the LDAPMessage, as defined in Section 4.1.12 of 232 [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". If 233 this control is included in a SearchRequest message, a Server Side 234 Sorting request control [SSS] MUST also be present in the message. 235 The controlValue, an OCTET STRING, is the BER-encoding of the 236 following SEQUENCE: 238 VirtualListViewRequest ::= SEQUENCE { 239 beforeCount INTEGER (0..maxInt), 240 afterCount INTEGER (0..maxInt), 241 CHOICE { 242 byoffset [0] SEQUENCE { 243 offset INTEGER (0 .. maxInt), 244 contentCount INTEGER (0 .. maxInt) }, 245 greaterThanOrEqual [1] AssertionValue }, 246 contextID OCTET STRING OPTIONAL } 248 beforeCount indicates how many entries before the target entry the 249 client wants the server to send. afterCount indicates the number of 250 entries after the target entry the client wants the server to send. 251 offset and contentCount identify the target entry as detailed in 252 section 4. greaterThanOrEqual is an attribute assertion value defined 253 in [LDAPv3].The assertion value is encoded according to the 254 attributeDescription in thesort control [SSS]. If present, the value 255 supplied in greaterThanOrEqual is used to determine the target entry 256 by comparison with the values of the attribute specified as the 257 primary sort key. The first list entry who's value is no less than 258 (less than or equal to when the sort order is reversed) the supplied 259 value is the target entry. If present, the contextID field contains 260 the value of the most recently received contextID field from a 261 VirtualListViewResponse control. The type AssertionValue and value 262 maxInt are defined in [LDAPv3]. contextID values have no validity 263 outside the connection on which they were received. That is, a client 265 Boreham et al Internet-Draft 5 266 Browsing of Search Results 268 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 If the request control is serviced, this response control is included 274 in the SearchResultDone message as part of the controls field of the 275 LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. 277 The controlType is set to "2.16.840.1.113730.3.4.10". The criticality 278 is FALSE (MAY be absent). The controlValue, an OCTET STRING, is the 279 BER-encoding of the following SEQUENCE: 281 VirtualListViewResponse ::= SEQUENCE { 282 targetPosition INTEGER (0 .. maxInt), 283 contentCount INTEGER (0 .. maxInt), 284 virtualListViewResult ENUMERATED { 285 success (0), 286 operationsError (1), 287 unwillingToPerform (53), 288 insufficientAccessRights (50), 289 busy (51), 290 timeLimitExceeded (3), 291 adminLimitExceeded (11), 292 sortControlMissing (60), 293 offsetRangeError (61), 294 other(80), 295 ... }, 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, the 305 contents of the contextID field SHOULD be returned to the server by a 306 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, 311 success, other) have the same meanings as defined in [LDAPv3], but 312 they pertain specifically to the VLV operation. For example, the 313 server could exceed an administration limit processing a 314 SearchRequest with a VirtualListViewRequest control. However, the 315 same administration limit would not be exceeded should the same 316 SearchRequest be submitted by the client without the 317 VirtualListViewRequest control. In this case, the client can 319 Boreham et al Internet-Draft 6 320 Browsing of Search Results 322 determine that an administration limit has been exceeded in servicing 323 the VLV request, and can if it chooses resubmit the SearchRequest 324 without the VirtualListViewRequest control. 326 insufficientAccessRights means that the server denied the client 327 permission to perform the VLV operation. 329 If the server determines that the results of the search presented 330 exceed the range specified in INTEGER values, it MUST return 331 offsetRangeError. 333 6.2.1 virtualListViewError 335 A new LDAP error is introduced called virtualListViewError. Its value 336 is 76. 338 If the server returns any code other than success (0) for 339 virtualListViewResult, then the server SHOULD return 340 virtualListViewError as the resultCode of the SearchResultDone 341 message. 343 [Note to the IESG/IANA/RFC Editor: 344 It is requested that IANA register the LDAP result code 345 virtualListViewError (76) upon Standards Action by the IESG. The 346 value 76 has been suggested by experts, had expert review, and is 347 currently being used by some implementations. The following 348 registration template is suggested: 350 Subject: LDAP Result Code Registration 351 Person & email address to contact for further information: Jim 352 Sermersheim 353 Result Code Name: virtualListViewError 354 Specification: RFCXXXX 355 Author/Change Controller: IESG 356 Comments: request LDAP result codes be assigned 357 ] 359 7. Protocol Example 361 Here we walk through the client-server interaction for a specific 362 virtual list view example: The task is to display a list of all 78564 363 people in the US company "Ace Industry". This will be done by 364 creating a graphical user interface object to display the list 365 contents, and by repeatedly sending different versions of the same 366 virtual list view search request to the server. The list view 367 displays 20 entries on the screen at a time. 369 We form a search with baseDN "o=Ace Industry,c=us"; search scope 370 subtree; filter "(objectClass=inetOrgPerson)". We attach a server 371 sort order control to the search, specifying ascending sort on 372 attribute "cn". To this search, we attach a virtual list view request 374 Boreham et al Internet-Draft 7 375 Browsing of Search Results 377 control with contents determined by the user activity and send the 378 search to the server. We display the results from each search in the 379 list window and update the slider position. 381 When the list view is first displayed, we want to initialize the 382 contents showing the beginning of the list. Therefore, we set 383 beforeCount to 0, afterCount to 19, contentCount to 0, offset to 1 384 and send the request to the server. The server duly returns the first 385 20 entries in the list, plus the content count = 78564 and 386 targetPosition = 1. We therefore leave the scroll bar slider at its 387 current location (the top of its range). 389 Say that next the user drags the scroll bar slider down to the bottom 390 of its range. We now wish to display the last 20 entries in the list, 391 so we set beforeCount = 19, afterCount = 0, contentCount = 78564, 392 offset = 78564 and send the request to the server. The server returns 393 the last 20 entries in the list, plus the content count = 78564 and 394 targetPosition = 78564. 396 Next the user presses a page up key. Our page size is 20, so we set 397 beforeCount = 0, afterCount = 19, contentCount = 78564, offset = 398 78564-19-20 and send the request to the server. The server returns 399 the preceding 20 entries in the list, plus the content count = 78564 400 and targetPosition = 78525. 402 Now the user grabs the scroll bar slider and drags it to 68% of the 403 way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9, 404 afterCount = 10, contentCount = 78564, offset = 53424 and send the 405 request to the server. The server returns the preceding 20 entries in 406 the list, plus the content count = 78564 and targetPosition = 53424. 408 Lastly, the user types the letter "B". We set beforeCount = 9, 409 afterCount = 10 and greaterThanOrEqual = "B". The server finds the 410 first entry in the list not less than "B", let's say "Babs Jensen", 411 and returns the nine preceding entries, the target entry, and the 412 proceeding 10 entries. The server returns content count = 78564 and 413 targetPosition = 5234 and so the client updates its scroll bar slider 414 to 6.7% of full scale. 416 8. Notes for Implementers 418 While the feature is expected to be generally useful for arbitrary 419 search and sort specifications, it is specifically designed for those 420 cases where the result set is very large. The intention is that this 421 feature be implemented efficiently by means of pre-computed indices 422 pertaining to a set of specific cases. For example, an offset 423 relating to "all the employees in the local organization, sorted by 424 surname" would be a common case. 426 Boreham et al Internet-Draft 8 427 Browsing of Search Results 429 The intention for client software is that the feature should fit 430 easily with the host platform's graphical user interface facilities 431 for the display of scrolling lists. Thus the task of the client 432 implementers should be one of reformatting up the requests for 433 information received from the list view code to match the format of 434 the virtual list view request and response controls. 436 Client implementers MUST be aware that any offset value returned by 437 the server might be approximate. Do not design clients that only 438 operate correctly when offsets are exact. 440 Server implementers using indexing technology which features 441 approximate positioning should consider returning context identifiers 442 to clients. The use of a context identifier will allow the server to 443 distinguish between client requests which relate to different 444 displayed lists on the client. Consequently the server can decide 445 more intelligently whether to reposition an existing database cursor 446 accurately to within a short distance of its current position, or to 447 reposition to an approximate position. Thus the client will see 448 precise offsets for "short" repositioning (e.g. paging up or down), 449 but approximate offsets for a "long" reposition (e.g. a slider 450 movement). 452 Server implementers are free to return an ldap result code of 453 virtualListViewError and a virtualListViewResult of 454 unwillingToPerform should their server be unable to service any 455 particular VLV search. This might be because the resolution of the 456 search is computationally infeasible, or because excessive server 457 resources would be required to service the search. 459 Client implementers should note that this control is only defined on 460 a client interaction with a single server. If a search scope spans 461 multiple naming contexts that are not held locally, search result 462 references will be returned, and may occur at any point in the search 463 operation. The client is responsible for deciding when and how to 464 apply this control to the referred-to servers, and how to collate the 465 results from multiple servers. 467 9. Relationship to "Simple Paged Results" 469 These controls are designed to support the virtual list view, which 470 has proved hard to implement with the Simple Paged Results mechanism 471 [SPaged]. However, the controls described here support any operation 472 possible with the Simple Paged Results mechanism. The two mechanisms 473 are not complementary; rather one has a superset of the other's 474 features. One area where the mechanism presented here is not a strict 475 superset of the Simple Paged Results scheme is that here we require a 476 sort order to be specified. No such requirement is made for paged 477 results. 479 Boreham et al Internet-Draft 9 480 Browsing of Search Results 482 10. Security Considerations 484 Server implementers may wish to consider whether clients are able to 485 consume excessive server resources in requesting virtual list 486 operations. Access control to the feature itself; configuration 487 options limiting the feature�s use to certain predetermined search 488 base DNs and filters; throttling mechanisms designed to limit the 489 ability for one client to soak up server resources, may be 490 appropriate. 492 Consideration should be given as to whether a client will be able to 493 retrieve the complete contents, or a significant subset of the 494 complete contents of the directory using this feature. This may be 495 undesirable in some circumstances and consequently it may be 496 necessary to enforce some access control. 498 Clients can, using this control, determine how many entries are 499 contained within a portion of the DIT. This may constitute a security 500 hazard. Again, access controls may be appropriate. 502 Server implementers should exercise caution concerning the content of 503 the contextID. Should the contextID contain internal server state, it 504 may be possible for a malicious client to use that information to 505 gain unauthorized access to information. 507 11. Acknowledgements 509 Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co- 510 authored previous versions of this document. 512 12. Normative References 514 [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - 515 Specification of Basic Notation", 1994. 517 [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: 518 Basic, Canonical, and Distinguished Encoding Rules", 519 1994. 521 [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 522 Access Protocol (v3)", Internet Standard, RFC 2251, 523 December, 1997. 525 [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control 526 Extension for Server Side Sorting of Search Results", 527 RFC 2891, August, 2000. 529 Boreham et al Internet-Draft 10 530 Browsing of Search Results 532 [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 13. Informative References 537 [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP 538 Control Extension for Simple Paged Results Manipulation", 539 RFC2696, September 1999. 541 14. Authors' Addresses 543 David Boreham 544 Bozeman Pass, Inc 545 +1 406 222 7093 546 david@bozemanpass.com 548 Jim Sermersheim 549 Novell 550 1800 South Novell Place 551 Provo, Utah 84606, USA 552 jimse@novell.com 554 Asaf Kashi 555 Microsoft Corporation 556 1 Microsoft Way 557 Redmond, WA 98052, USA 558 +1 425 882-8080 559 asafk@microsoft.com 561 154. Full Copyright Statement 563 Copyright (C) The Internet Society (2002). All Rights Reserved. 564 This document and translations of it may be copied and furnished to 565 others, and derivative works that comment on or otherwise explain it 566 or assist in its implementation may be prepared, copied, published 567 and distributed, in whole or in part, without restriction of any 568 kind, provided that the above copyright notice and this paragraph are 569 included on all such copies and derivative works. However, this 570 document itself may not be modified in any way, such as by removing 571 the copyright notice or references to the Internet Society or other 572 Internet organizations, except as needed for the purpose of 573 developing Internet standards in which case the procedures for 574 copyrights defined in the Internet Standards process must be 575 followed, or as required to translate it into languages other than 576 English. The limited permissions granted above are perpetual and will 577 not be revoked by the Internet Society or its successors or assigns. 578 This document and the information contained herein is provided on an 579 "AS IS" basis and THE INTERNET SOCIETY AND THE 580 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 582 Boreham et al Internet-Draft 11 583 Browsing of Search Results 585 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 589 Boreham et al Internet-Draft 12