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