]> git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt
Merge remote-tracking branch 'origin/mdb.RE/0.9' into OPENLDAP_REL_ENG_2_4
[openldap] / doc / drafts / draft-ietf-ldapext-ldapv3-vlv-xx.txt
1
2 Internet-Draft                                 D. Boreham, Bozeman Pass 
3 LDAPext Working Group                            J. Sermersheim, Novell 
4 Intended Category: Standards Track                  A. Kashi, Microsoft 
5 <draft-ietf-ldapext-ldapv3-vlv-09.txt>                                  
6 Expires: Jun 2003                                              Nov 2002 
7     
8     
9        LDAP Extensions for Scrolling View Browsing of Search Results 
10     
11     
12 1. 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     
38 2. 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     \f
57                  LDAP Extensions for Scrolling View            Nov 2002 
58                      Browsing of Search Results 
59     
60 3. 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     
85 4. 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     \f
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     
145 5. 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     \f
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     \f
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     
259 6. 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     
265 6.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     \f
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     
335 6.2. Response Control 
336     
337
338
339     
340    Boreham et al           Internet-Draft                             6 
341     \f
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     \f
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     
417 6.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     
430 7. 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     \f
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     
492 8. 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     \f
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     
549 9. 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     
562 10. 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     \f
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     
595 11. IANA Considerations 
596     
597 11.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     
617 12. 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     \f
627                  LDAP Extensions for Scrolling View            Nov 2002 
628                      Browsing of Search Results 
629     
630 13. 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                 
655 14. 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     
662 15. 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     \f
684                  LDAP Extensions for Scrolling View            Nov 2002 
685                      Browsing of Search Results 
686     
687          
688     
689 16. 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