1 2Internet-Draft D. Boreham, Bozeman Pass 3LDAPext Working Group J. Sermersheim, Novell 4Intended Category: Standards Track A. Kashi, Microsoft 5<draft-ietf-ldapext-ldapv3-vlv-09.txt> 6Expires: Jun 2003 Nov 2002 7 8 9 LDAP Extensions for Scrolling View Browsing of Search Results 10 11 121. Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 16 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 32 This document is intended to be submitted, after review and revision, 33 as a Standards Track document. Distribution of this memo is 34 unlimited. 35 Please send comments to the authors. 36 37 382. Abstract 39 40 This document describes a Virtual List View extension for the 41 Lightweight Directory Access Protocol (LDAP) Search operation. This 42 extension is designed to allow the "virtual list box" feature, common 43 in existing commercial e-mail address book applications, to be 44 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. 47 48 The extension allows a client to specify that the server return, for 49 a given LDAP search with associated sort keys, a contiguous subset of 50 the search result set. This subset is specified in terms of offsets 51 into the ordered list, or in terms of a greater than or equal 52 comparison value. 53 54 55 Boreham et al Internet-Draft 1 56 57 LDAP Extensions for Scrolling View Nov 2002 58 Browsing of Search Results 59 603. Conventions used in this document 61 The key words "MUST", "SHALL", "SHOULD", "SHOULD NOT", and "MAY" in 62 this document are to be interpreted as described in RFC 2119 63 [Bradner97]. 64 65 Protocol elements are described using ASN.1 [X.680]. The term "BER- 66 encoded" means the element is to be encoded using the Basic Encoding 67 Rules [X.690] under the restrictions detailed in Section 5.1 of 68 [LDAPPROT]. 69 70 The phrase "subsequent virtual list request" is used in this document 71 to describe a search request accompanied by a VirtualListViewRequest 72 control, where the search base, scope, and filter are the same as a 73 previous search request also accompanied by a VirtualListViewRequest 74 control, and where the contextID of the subsequent 75 VirtualListViewRequest control, is set to that of the contextID in 76 the VirtualListViewResponse control that accompanied the previous 77 search response. 78 79 The phrase "contiguous virtual list request" is used to describe a 80 subsequent virtual list request which is requesting search results 81 adjoining or overlapping the result returned from the prior virtual 82 list request. 83 84 854. Background 86 87 A Virtual List is a graphical user interface technique employed where 88 ordered lists containing a large number of entries need to be 89 displayed. A window containing a small number of visible list entries 90 is drawn. The visible portion of the list may be relocated to 91 different points within the list by means of user input. This input 92 can be to a scroll bar slider; from cursor keys; from page up/down 93 keys; from alphanumeric keys for "typedown". The user is given the 94 impression that they may browse the complete list at will, even 95 though it may contain millions of entries. It is the fact that the 96 complete list contents are never required at any one time that 97 characterizes Virtual List View. Rather than fetch the complete list 98 from wherever it is stored (typically from disk or a remote server), 99 only that information which is required to display the part of the 100 list currently in view is fetched. The subject of this document is 101 the interaction between client and server required to implement this 102 functionality in the context of the results from an ordered [SSS] 103 Lightweight Directory Access Protocol (LDAP) search operation 104 [LDAPPROT]. 105 106 For example, suppose an e-mail address book application displays a 107 list view onto the list containing the names of all the holders of e- 108 mail accounts at a large university. The list is ordered 109 alphabetically. While there may be tens of thousands of entries in 110 this list, the address book list view displays only 20 such accounts 111 112 Boreham et al Internet-Draft 2 113 114 LDAP Extensions for Scrolling View Nov 2002 115 Browsing of Search Results 116 117 at any one time. The list has an accompanying scroll bar and text 118 input window for type-down. When first displayed, the list view shows 119 the first 20 entries in the list, and the scroll bar slider is 120 positioned at the top of its range. Should the user drag the slider 121 to the bottom of its range, the displayed contents of the list view 122 should be updated to show the last 20 entries in the list. Similarly, 123 if the slider is positioned somewhere in the middle of its travel, 124 the displayed contents of the list view should be updated to contain 125 the 20 entries located at that relative position within the complete 126 list. Starting from any display point, if the user uses the cursor 127 keys or clicks on the scroll bar to request that the list be scrolled 128 up or down by one entry, the displayed contents should be updated to 129 reflect this. Similarly the list should be displayed correctly when 130 the user requests a page scroll up or down. Finally, when the user 131 types characters in the type-down window, the displayed contents of 132 the list should "jump" or "seek" to the appropriate point within the 133 list. For example, if the user types "B", the displayed list could 134 center around the first user with a name beginning with the letter 135 "B". When this happens, the scroll bar slider should also be updated 136 to reflect the new relative location within the list. 137 138 This document defines a request control which extends the LDAP search 139 operation. Always used in conjunction with the server side sorting 140 control [SSS], this allows a client to retrieve selected portions of 141 large search result set in a fashion suitable for the implementation 142 of a virtual list view. 143 144 1455. Client-Server Interaction 146 147 The Virtual List View control extends a regular LDAP Search operation 148 which MUST also include a server-side sorting control [SSS]. Rather 149 than returning the complete set of appropriate SearchResultEntry 150 messages, the server is instructed to return a contiguous subset of 151 those entries, taken from the ordered result set, centered around a 152 particular target entry. Henceforth, in the interests of brevity, the 153 ordered search result set will be referred to as "the list". 154 155 The sort control may contain any sort specification valid for the 156 server. The attributeType field in the first SortKeyList sequence 157 element has special significance for "typedown". The Virtual List 158 View control acts upon a set of ordered entries and this order must 159 be repeatable for all subsequent virtual list requests. The server- 160 side sorting control is intended to aid in this ordering, but other 161 mechanisms may need to be employed to produce a repeatable order-- 162 especially for entries that don't have a value of the sort key. 163 164 The desired target entry and the number of entries to be returned, 165 both before and after that target entry in the list, are determined 166 by the client's VirtualListViewRequest control. 167 168 169 Boreham et al Internet-Draft 3 170 171 LDAP Extensions for Scrolling View Nov 2002 172 Browsing of Search Results 173 174 When the server returns the set of entries to the client, it attaches 175 a VirtualListViewResponse control to the SearchResultDone message. 176 The server returns in this control: its current estimate for the list 177 content count, the location within the list corresponding to the 178 target entry, any error codes, and optionally a context identifier. 179 180 The target entry is specified in the VirtualListViewRequest control 181 by one of two methods. The first method is for the client to indicate 182 the target entry's offset within the list. The second way is for the 183 client to supply an attribute assertion value. The value is compared 184 against the values of the attribute specified as the primary sort key 185 in the sort control attached to the search operation. The first sort 186 key in the SortKeyList is the primary sort key. The target entry is 187 the first entry in the list with value greater than or equal to (in 188 the primary sort order), the presented value. The order is determined 189 by rules defined in [SSS]. Selection of the target entry by this 190 means is designed to implement "typedown". Note that it is possible 191 that no entry satisfies these conditions, in which case there is no 192 target entry. This condition is indicated by the server returning the 193 special value contentCount + 1 in the target position field. 194 195 Because the server may not have an accurate estimate of the number of 196 entries in the list, and to take account of cases where the list size 197 is changing during the time the user browses the list, and because 198 the client needs a way to indicate specific list targets "beginning" 199 and "end", offsets within the list are transmitted between client and 200 server as ratios---offset to content count. The server sends its 201 latest estimate as to the number of entries in the list (content 202 count) to the client in every response control. The client sends its 203 assumed value for the content count in every request control. The 204 server examines the content count and offsets presented by the client 205 and computes the corresponding offsets within the list, based on its 206 own idea of the content count. 207 208 Si = Sc * (Ci / Cc) 209 210 Where: 211 Si is the actual list offset used by the server 212 Sc is the server's estimate for content count 213 Ci is the client's submitted offset 214 Cc is the client's submitted content count 215 The result is rounded to the nearest integer. 216 217 If the content count is stable, and the client returns to the server 218 the content count most recently received, Cc = Sc and the offsets 219 transmitted become the actual server list offsets. 220 221 The following special cases exist when the client is specifying the 222 offset and content count: 223 - an offset of one and a content count of non-one (Ci = 1, Cc != 1) 224 indicates that the target is the first entry in the list. 225 226 Boreham et al Internet-Draft 4 227 228 LDAP Extensions for Scrolling View Nov 2002 229 Browsing of Search Results 230 231 - equivalent values (Ci = Cc) indicate that the target is the last 232 entry in the list. 233 - a content count of zero (Cc = 0, Ci != 0) means the client has no 234 idea what the content count is, the server MUST use its own 235 content count estimate in place of the client's. 236 237 Because the server always returns contentCount and targetPosition, 238 the client can always determine which of the returned entries is the 239 target entry. Where the number of entries returned is the same as the 240 number requested, the client is able to identify the target by simple 241 arithmetic. Where the number of entries returned is not the same as 242 the number requested (because the requested range crosses the 243 beginning or end of the list, or both), the client MUST use the 244 target position and content count values returned by the server to 245 identify the target entry. For example, suppose that 10 entries 246 before and 10 after the target were requested, but the server returns 247 13 entries, a content count of 100 and a target position of 3. The 248 client can determine that the first entry must be entry number 1 in 249 the list, therefore the 13 entries returned are the first 13 entries 250 in the list, and the target is the third one. 251 252 A server-generated contextID MAY be returned to clients. A client 253 receiving a contextID MUST return it unchanged or not return it at 254 all, in a subsequent request which relates to the same list. The 255 purpose of this interaction is to maintain state information between 256 the client and server. 257 258 2596. The Controls 260 261 Support for the virtual list view control extension is indicated by 262 the presence of the OID "2.16.840.1.113730.3.4.9" in the 263 supportedControl attribute of a server's root DSE. 264 2656.1. Request Control 266 267 This control is included in the SearchRequest message as part of the 268 controls field of the LDAPMessage, as defined in Section 4.1.12 of 269 [LDAPPROT]. The controlType is set to "2.16.840.1.113730.3.4.9". If 270 this control is included in a SearchRequest message, a Server Side 271 Sorting request control [SSS] MUST also be present in the message. 272 The controlValue, an OCTET STRING, is the BER-encoding of the 273 following SEQUENCE: 274 275 VirtualListViewRequest ::= SEQUENCE { 276 beforeCount INTEGER (0..maxInt), 277 afterCount INTEGER (0..maxInt), 278 target CHOICE { 279 byOffset [0] SEQUENCE { 280 offset INTEGER (1 .. maxInt), 281 contentCount INTEGER (0 .. maxInt) }, 282 283 Boreham et al Internet-Draft 5 284 285 LDAP Extensions for Scrolling View Nov 2002 286 Browsing of Search Results 287 288 greaterThanOrEqual [1] AssertionValue }, 289 contextID OCTET STRING OPTIONAL } 290 291 beforeCount indicates how many entries before the target entry the 292 client wants the server to send. 293 294 afterCount indicates the number of entries after the target entry the 295 client wants the server to send. 296 297 offset and contentCount identify the target entry as detailed in 298 section 5. 299 300 greaterThanOrEqual is a matching rule assertion value defined in 301 [LDAPPROT]. The assertion value is encoded according to the ORDERING 302 matching rule for the attributeDescription in the sort control [SSS]. 303 If present, the value supplied in greaterThanOrEqual is used to 304 determine the target entry by comparison with the values of the 305 attribute specified as the primary sort key. The first list entry 306 who's value is no less than (less than or equal to when the sort 307 order is reversed) the supplied value is the target entry. 308 309 If present, the contextID field contains the value of the most 310 recently received contextID field from a VirtualListViewResponse 311 control for the same list view. If the contextID is not known because 312 no contextID has been sent by the server in a VirtualListViewResponse 313 control, it SHALL be omitted. If the server receives a contextID that 314 is invalid, it SHALL fail the search operation and indicate the 315 failure with a protocolError (3) value in the virtualListViewResult 316 field of the VirtualListViewResponse. The contextID provides state 317 information between the client and server. This state information is 318 used by the server to ensure continuity contiguous virtual list 319 requests. When a server receives a VirtualListViewRequest control 320 that includes a contextID, it SHALL determine whether the client has 321 sent a contiguous virtual list request and SHALL provide contiguous 322 entries if possible. If a valid contextID is sent, and the server is 323 unable to determine whether contiguous data is requested, or is 324 unable to provide requested contiguous data, it SHALL fail the search 325 operation and indicate the failure with an unwillingToPerform (53) 326 value in the virtualListViewResult field of the 327 VirtualListViewResponse. contextID values have no validity outside 328 the connection and query with which they were received. A client MUST 329 NOT submit a contextID which it received from a different connection, 330 a different query, or a different server. 331 332 The type AssertionValue and value maxInt are defined in [LDAPPROT]. 333 334 3356.2. Response Control 336 337 338 339 340 Boreham et al Internet-Draft 6 341 342 LDAP Extensions for Scrolling View Nov 2002 343 Browsing of Search Results 344 345 If the request control is serviced, this response control is included 346 in the SearchResultDone message as part of the controls field of the 347 LDAPMessage, as defined in Section 4.1.12 of [LDAPPROT]. 348 349 The controlType is set to "2.16.840.1.113730.3.4.10". The 350 controlValue, an OCTET STRING, is the BER-encoding of the following 351 SEQUENCE: 352 353 VirtualListViewResponse ::= SEQUENCE { 354 targetPosition INTEGER (0 .. maxInt), 355 contentCount INTEGER (0 .. maxInt), 356 virtualListViewResult ENUMERATED { 357 success (0), 358 operationsError (1), 359 protocolError (3), 360 unwillingToPerform (53), 361 insufficientAccessRights (50), 362 timeLimitExceeded (3), 363 adminLimitExceeded (11), 364 innapropriateMatching (18), 365 sortControlMissing (60), 366 offsetRangeError (61), 367 other(80), 368 ... }, 369 contextID OCTET STRING OPTIONAL } 370 371 targetPosition gives the list offset for the target entry. 372 373 contentCount gives the server's estimate of the current number of 374 entries in the list. Together these give sufficient information for 375 the client to update a list box slider position to match the newly 376 retrieved entries and identify the target entry. The contentCount 377 value returned SHOULD be used in a subsequent VirtualListViewRequest 378 control. 379 380 contextID is a server-defined octet string. If present, the contents 381 of the contextID field SHOULD be returned to the server by a client 382 in a subsequent virtual list request. The presence of a contextID 383 here indicates that the server is willing to return contiguous data 384 from a subsequent search request which uses the same search criteria, 385 accompanied by a VirtualListViewRequest which indicates that the 386 client wishes to receive an adjoining page of data. 387 388 The virtualListViewResult codes which are common to the LDAP 389 searchResultDone (adminLimitExceeded, timeLimitExceeded, 390 operationsError, unwillingToPerform, insufficientAccessRights, 391 success, other) have the same meanings as defined in [LDAPPROT], but 392 they pertain specifically to the VLV operation. For example, the 393 server could exceed a VLV-specific administrative limit while 394 processing a SearchRequest with a VirtualListViewRequest control. 395 Obviously, the same administrative limit would not be exceeded should 396 397 Boreham et al Internet-Draft 7 398 399 LDAP Extensions for Scrolling View Nov 2002 400 Browsing of Search Results 401 402 the same SearchRequest be submitted by the client without the 403 VirtualListViewRequest control. In this case, the client can 404 determine that the administrative limit has been exceeded in 405 servicing the VLV request, and can if it chooses resubmit the 406 SearchRequest without the VirtualListViewRequest control, or with 407 different parameters. 408 409 insufficientAccessRights means that the server denied the client 410 permission to perform the VLV operation. 411 412 If the server determines that the results of the search presented 413 exceed the range specified in INTEGER values, or if the client 414 specifies an invalid offset or contentCount, the server MUST set the 415 virtualListViewResult value to offsetRangeError. 416 4176.2.1 virtualListViewError 418 419 A new LDAP error is introduced called virtualListViewError. Its value 420 is 76. This error indicates that the search operation failed due to 421 the inclusion of the VirtualListViewRequest control. 422 423 If the resultCode in the SearchResultDone message is set to 424 virtualListViewError (76), then the virtualListViewResult value MUST 425 NOT be success (as virtualListViewResult indicates the specific error 426 condition). If resultCode in the SearchResultDone message is not set 427 to virtualListViewError (76), then the virtualListViewResult value 428 SHOULD be success (0) and its value MUST be ignored. 429 4307. Protocol Example 431 432 Here we walk through the client-server interaction for a specific 433 virtual list view example: The task is to display a list of all 78564 434 persons in the US company "Ace Industry". This will be done by 435 creating a graphical user interface object to display the list 436 contents, and by repeatedly sending different versions of the same 437 virtual list view search request to the server. The list view 438 displays 20 entries on the screen at a time. 439 440 We form a search with baseObject of "o=Ace Industry,c=us"; scope of 441 wholeSubtree; and filter of "(objectClass=person)". We attach a 442 server-side sort control [SSS] to the search request, specifying 443 ascending sort on attribute "cn". To this search request, we attach a 444 virtual list view request control with contents determined by the 445 user activity and send the search request to the server. We display 446 the results from each search result entry in the list window and 447 update the slider position. 448 449 When the list view is first displayed, we want to initialize the 450 contents showing the beginning of the list. Therefore, we set 451 beforeCount to 0, afterCount to 19, contentCount to 0, offset to 1 452 and send the request to the server. The server duly returns the first 453 454 Boreham et al Internet-Draft 8 455 456 LDAP Extensions for Scrolling View Nov 2002 457 Browsing of Search Results 458 459 20 entries in the list, plus a content count of 78564 and 460 targetPosition of 1. We therefore leave the scroll bar slider at its 461 current location (the top of its range). 462 463 Say that next the user drags the scroll bar slider down to the bottom 464 of its range. We now wish to display the last 20 entries in the list, 465 so we set beforeCount to 19, afterCount to 0, contentCount to 78564, 466 offset to 78564 and send the request to the server. The server 467 returns the last 20 entries in the list, plus a content count of 468 78564 and a targetPosition of 78564. 469 470 Next the user presses a page up key. Our page size is 20, so we set 471 beforeCount to 0, afterCount to 19, contentCount to 78564, offset to 472 78564-19-20 and send the request to the server. The server returns 473 the preceding 20 entries in the list, plus a content count of 78564 474 and a targetPosition of 78525. 475 476 Now the user grabs the scroll bar slider and drags it to 68% of the 477 way down its travel. 68% of 78564 is 53424 so we set beforeCount to 478 9, afterCount to 10, contentCount to 78564, offset to 53424 and send 479 the request to the server. The server returns the preceding 20 480 entries in the list, plus a content count of 78564 and a 481 targetPosition of 53424. 482 483 Lastly, the user types the letter "B". We set beforeCount to 9, 484 afterCount to 10 and greaterThanOrEqual to "B". The server finds the 485 first entry in the list not less than "B", let's say "Babs Jensen", 486 and returns the nine preceding entries, the target entry, and the 487 proceeding 10 entries. The server returns a content count of 78564 488 and a targetPosition of 5234 and so the client updates its scroll bar 489 slider to 6.7% of full scale. 490 491 4928. Notes for Implementers 493 494 While the feature is expected to be generally useful for arbitrary 495 search and sort specifications, it is specifically designed for those 496 cases where the result set is very large. The intention is that this 497 feature be implemented efficiently by means of pre-computed indices 498 pertaining to a set of specific cases. For example, an offset 499 relating to "all the employees in the local organization, sorted by 500 surname" would be a common case. 501 502 The intention for client software is that the feature should fit 503 easily with the host platform's graphical user interface facilities 504 for the display of scrolling lists. Thus the task of the client 505 implementers should be one of reformatting up the requests for 506 information received from the list view code to match the format of 507 the virtual list view request and response controls. 508 509 510 511 Boreham et al Internet-Draft 9 512 513 LDAP Extensions for Scrolling View Nov 2002 514 Browsing of Search Results 515 516 Client implementers MUST be aware that any offset value returned by 517 the server might be approximate. Do not design clients that only 518 operate correctly when offsets are exact. However, if contextIDs are 519 used, and adjoining pages of information are requested, the server 520 will return contiguous data. 521 522 Server implementers using indexing technology which features 523 approximate positioning should consider returning contextIDs to 524 clients. The use of a contextID will allow the server to distinguish 525 between client requests which relate to different displayed lists on 526 the client. Consequently the server can decide more intelligently 527 whether to reposition an existing database cursor accurately to 528 within a short distance of its current position, or to reposition to 529 an approximate position. Thus the client will see precise offsets for 530 "short" repositioning (e.g. paging up or down), but approximate 531 offsets for a "long" reposition (e.g. a slider movement). 532 533 Server implementers are free to return an LDAP result code of 534 virtualListViewError and a virtualListViewResult of 535 unwillingToPerform should their server be unable to service any 536 particular VLV search. This might be because the resolution of the 537 search is computationally infeasible, or because excessive server 538 resources would be required to service the search. 539 540 Client implementers should note that this control is only defined on 541 a client interaction with a single server. If a search scope spans 542 multiple naming contexts that are not held locally, search result 543 references will be returned, and may occur at any point in the search 544 operation. The client is responsible for deciding when and how to 545 apply this control to the referred-to servers, and how to collate the 546 results from multiple servers. 547 548 5499. Relationship to "Simple Paged Results" 550 551 These controls are designed to support the virtual list view, which 552 has proved hard to implement with the Simple Paged Results mechanism 553 [SPaged]. However, the controls described here support any operation 554 possible with the Simple Paged Results mechanism. The two mechanisms 555 are not complementary; rather one has a superset of the other's 556 features. One area where the mechanism presented here is not a strict 557 superset of the Simple Paged Results scheme is that here we require a 558 sort order to be specified. No such requirement is made for paged 559 results. 560 561 56210. Security Considerations 563 564 Server implementers may wish to consider whether clients are able to 565 consume excessive server resources in requesting virtual list 566 operations. Access control to the feature itself; configuration 567 568 Boreham et al Internet-Draft 10 569 570 LDAP Extensions for Scrolling View Nov 2002 571 Browsing of Search Results 572 573 options limiting the feature's use to certain predetermined search 574 base DNs and filters; throttling mechanisms designed to limit the 575 ability for one client to soak up server resources, may be 576 appropriate. 577 578 Consideration should be given as to whether a client will be able to 579 retrieve the complete contents, or a significant subset of the 580 complete contents of the directory using this feature. This may be 581 undesirable in some circumstances and consequently it may be 582 necessary to enforce some access control or administrative limit. 583 584 Clients can, using this control, determine how many entries match a 585 particular filter, before the entries are returned to the client. 586 This may require special processing in servers which perform access 587 control checks on entries to determine whether the existence of the 588 entry can be disclosed to the client. 589 590 Server implementers should exercise caution concerning the content of 591 the contextID. Should the contextID contain internal server state, it 592 may be possible for a malicious client to use that information to 593 gain unauthorized access to information. 594 59511. IANA Considerations 596 59711.1 Request for LDAP Result Code 598 599 In accordance with section 3.6 of [LDAPIANA], it is requested that 600 IANA register the LDAP result code virtualListViewError (76) upon 601 Standards Action by the IESG. The value 76 has been suggested by 602 experts, had expert review, and is currently being used by some 603 implementations. If 76 is unavailable on not chosen, the value in the 604 paragraphs in Section 6.2.1 will need to be updated. The following 605 registration template is suggested: 606 607 Subject: LDAP Result Code Registration 608 Person & email address to contact for further information: Jim 609 Sermersheim 610 Result Code Name: virtualListViewError 611 Specification: RFCXXXX 612 Author/Change Controller: IESG 613 Comments: request LDAP result codes be assigned 614 615 616 61712. Acknowledgements 618 619 Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co- 620 authored previous versions of this document. 621 622 623 624 625 Boreham et al Internet-Draft 11 626 627 LDAP Extensions for Scrolling View Nov 2002 628 Browsing of Search Results 629 63013. Normative References 631 632 633 [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - 634 Specification of Basic Notation", 1994. 635 636 [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: 637 Basic, Canonical, and Distinguished Encoding Rules", 638 1994. 639 640 [LDAPPROT] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 641 Access Protocol (v3)", Internet Standard, RFC 2251, 642 December, 1997. 643 644 [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control 645 Extension for Server Side Sorting of Search Results", 646 RFC 2891, August, 2000. 647 648 [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 651 [LDAPIANA] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 652 Considerations for the Lightweight Directory Access 653 Protocol (LDAP)", RFC 3383, September 2002. 654 65514. Informative References 656 657 [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP 658 Control Extension for Simple Paged Results Manipulation", 659 RFC2696, September 1999. 660 661 66215. Authors' Addresses 663 664 David Boreham 665 Bozeman Pass, Inc 666 +1 406 222 7093 667 david@bozemanpass.com 668 669 Jim Sermersheim 670 Novell 671 1800 South Novell Place 672 Provo, Utah 84606, USA 673 jimse@novell.com 674 675 Asaf Kashi 676 Microsoft Corporation 677 1 Microsoft Way 678 Redmond, WA 98052, USA 679 +1 425 882-8080 680 asafk@microsoft.com 681 682 Boreham et al Internet-Draft 12 683 684 LDAP Extensions for Scrolling View Nov 2002 685 Browsing of Search Results 686 687 688 68916. Full Copyright Statement 690 691 Copyright (C) The Internet Society (2002). All Rights Reserved. 692 This document and translations of it may be copied and furnished to 693 others, and derivative works that comment on or otherwise explain it 694 or assist in its implementation may be prepared, copied, published 695 and distributed, in whole or in part, without restriction of any 696 kind, provided that the above copyright notice and this paragraph are 697 included on all such copies and derivative works. However, this 698 document itself may not be modified in any way, such as by removing 699 the copyright notice or references to the Internet Society or other 700 Internet organizations, except as needed for the purpose of 701 developing Internet standards in which case the procedures for 702 copyrights defined in the Internet Standards process must be 703 followed, or as required to translate it into languages other than 704 English. The limited permissions granted above are perpetual and will 705 not be revoked by the Internet Society or its successors or assigns. 706 This document and the information contained herein is provided on an 707 "AS IS" basis and THE INTERNET SOCIETY AND THE 708 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 709 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 710 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 711 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 Boreham et al Internet-Draft 13 740