[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] VLV: review notes
Attached are my review notes...
Kurt
draft-ietf-ldapext-ldapv3-vlv-08.txt:
>2. Abstract
>
> This document describes a Virtual List View control extension for the
> Lightweight Directory Access Protocol (LDAP) Search operation.
This document defines one extension which utilizes multiple controls.
So, I suggest the word control be dropped from the above sentence
and the word control replaced with extension in the following two
paragraphs.
> This control is designed to allow the "virtual list box" feature, common
> in existing commercial e-mail address book applications, to be
> supported efficiently by LDAP servers. LDAP servers' inability to
> support this client feature is a significant impediment to LDAP
> replacing proprietary protocols in commercial e-mail systems.
>
> The control allows a client to specify that the server return, for a
> given LDAP search with associated sort keys, a contiguous subset of
> the search result set. This subset is specified in terms of offsets
> into the ordered list, or in terms of a greater than or equal
> comparison value.
>3. Conventions used in this document
> The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
> document are to be interpreted as described in RFC 2119 [Bradner97].
>
> Protocol elements are described using ASN.1 [X.680]. The term "BER-
> encoded" means the element is to be encoded using the Basic Encoding
> Rules [X.690] under the restrictions detailed in Section 5.1 of
> [LDAPv3].
>
>
>4. Background
>
> A Virtual List is a graphical user interface technique employed where
> ordered lists containing a large number of entries need to be
> displayed. A window containing a small number of visible list entries
> is drawn. The visible portion of the list may be relocated to
> different points within the list by means of user input. This input
> can be to a scroll bar slider; from cursor keys; from page up/down
> keys; from alphanumeric keys for "typedown". The user is given the
> impression that they may browse the complete list at will, even
> though it may contain millions of entries. It is the fact that the
> complete list contents are never required at any one time that
> characterizes Virtual List View. Rather than fetch the complete list
> from wherever it is stored (typically from disk or a remote server),
> only that information which is required to display the part of the
> list currently in view is fetched. The subject of this document is
> the interaction between client and server required to implement this
> functionality in the context of the results from a sorted [SSS]
> Lightweight Directory Access Protocol (LDAP) [LDAPv3] search request.
The document should refer to RFC 3377 for LDAP and to RFC 2251
for the search operation. (note s/request/operation/)
> For example, suppose an e-mail address book application displays a
> list view onto the list containing the names of all the holders of e-
> mail accounts at a large university. The list is sorted
> alphabetically. While there may be tens of thousands of entries in
> this list, the address book list view displays only 20 such accounts
> at any one time. The list has an accompanying scroll bar and text
> input window for type-down. When first displayed, the list view shows
> the first 20 entries in the list, and the scroll bar slider is
> positioned at the top of its range. Should the user drag the slider
> to the bottom of its range, the displayed contents of the list view
> should be updated to show the last 20 entries in the list. Similarly,
> if the slider is positioned somewhere in the middle of its travel,
> the displayed contents of the list view should be updated to contain
> the 20 entries located at that relative position within the complete
> list. Starting from any display point, if the user uses the cursor
> keys or clicks on the scroll bar to request that the list be scrolled
> up or down by one entry, the displayed contents should be updated to
> reflect this. Similarly the list should be displayed correctly when
> the user requests a page scroll up or down. Finally, when the user
> types characters in the type-down window, the displayed contents of
> the list should "jump" or "seek" to the appropriate point within the
> list. For example, if the user types "B", the displayed list could
> center around the first user with a name beginning with the letter
> "B". When this happens, the scroll bar slider should also be updated
> to reflect the new relative location within the list.
>
> This document defines a request control which extends the LDAP search
> operation. Always used in conjunction with the server side sorting
> control [SSS], this allows a client to retrieve selected portions of
> large search result set in a fashion suitable for the implementation
> of a virtual list view.
I believe this control should also be usable without a sorting
control. Just as one can page through unsorted results using
[SPaged], one should be able to VLV through unsorted results.
>5. Client-Server Interaction
>
> The Virtual List View control extends a regular LDAP Search operation
> which MUST also include a server-side sorting control [SSS].
This MUST should be dropped. It should be acceptable for a VLV
implementation not to support [SSS], just as a [SPaged] implementation
need not support [SSS]. It should be possible to use VLV with other
ordering controls instead of [SSS].
All that is necessary is is to say that implementations must provide
unsorted results in some repeatable order. That is, the order must
be consistent for subsequent operations. It should be sufficient
to outline the ordering requirements and to state those requirements
are not provided, the VLV control cannot be used.
I believe VLV should offer all the capabilities of [SPaged]. In
fact, it's my opinion that VLV should obsolete [SPaged].
In making these changes, the term "sorted" should be replaced
with "ordered".
> Rather than returning the complete set of appropriate SearchResultEntry
> messages, the server is instructed to return a contiguous subset of
> those entries, taken from the sorted result set, centered around a
> particular target entry. Henceforth, in the interests of brevity, the
> sorted search result set will be referred to as "the list".
>
> The sort control may contain any sort specification valid for the
> server. The attributeType field in the first SortKeyList sequence
> element has special significance for "typedown".
>
> The desired target entry and the number of entries to be returned,
> both before and after that target entry in the list, are determined
> by the client's VirtualListViewRequest control.
>
> When the server returns the set of entries to the client, it attaches
> a VirtualListViewResponse control to the SearchResultDone message.
> The server returns in this control: its current estimate for the list
> content count, the location within the list corresponding to the
> target entry, any error codes, and optionally a context identifier.
>
> The target entry is specified in the VirtualListViewRequest control
> by one of two methods.
I note that there is no way to specify the target be a particular
entry. That is, by DN. Whether or not select by DN is particularly
useful is another matter.
> The first method is for the client to indicate
> the target entry's offset within the list. The second way is for the
> client to supply an attribute assertion value. The value is compared
> against the values of the attribute specified as the primary sort key
> in the sort control attached to the search operation. The first sort
> key in the SortKeyList is the primary sort key. The target entry is
> the first entry in the list with value greater than or equal to (in
> the primary sort order), the presented value. The order is determined
> by rules defined in [SSS]. Selection of the target entry by this
> means is designed to implement "typedown". Note that it is possible
> that no entry satisfies these conditions, in which case there is no
> target entry. This condition is indicated by the server returning the
> special value contentCount + 1 in the target position field.
>
> Because the server may not have an accurate estimate of the number of
> entries in the list, and to take account of cases where the list size
> is changing during the time the user browses the list, and because
> the client needs a way to indicate specific list targets "beginning"
> and "end", offsets within the list are transmitted between client and
> server as ratios---offset to content count. The server sends its
> latest estimate as to the number of entries in the list (content
> count) to the client in every response control. The client sends its
> assumed value for the content count in every request control. The
> server examines the content count and offsets presented by the client
> and computes the corresponding offsets within the list, based on its
> own idea of the content count.
>
> Si = Sc * (Ci / Cc)
>
> Where:
> Si is the actual list offset used by the server
> Sc is the server's estimate for content count
> Ci is the client's submitted offset
> Cc is the client's submitted content count
> The result is rounded to the nearest integer.
>
> If the content count is stable, and the client returns to the server
> the content count most recently received, Cc = Sc and the offsets
> transmitted become the actual server list offsets.
>
> The following special cases exist when the client is specifying the
> offset and content count:
> - an offset of one and a content count of non-one (Ci = 1, Cc != 1)
> indicates that the target is the first entry in the list.
> - equivalent values (Ci = Cc) indicate that the target is the last
> entry in the list.
> - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0)
> means the client has no idea what the content count is, the server
> MUST use its own content count estimate in place of the client's.
>
> Because the server always returns contentCount and targetPosition,
> the client can always determine which of the returned entries is the
> target entry. Where the number of entries returned is the same as the
> number requested, the client is able to identify the target by simple
> arithmetic. Where the number of entries returned is not the same as
> the number requested (because the requested range crosses the
> beginning or end of the list, or both), the client MUST use the
> target position and content count values returned by the server to
> identify the target entry. For example, suppose that 10 entries
> before and 10 after the target were requested, but the server returns
> 13 entries, a content count of 100 and a target position of 3. The
> client can determine that the first entry must be entry number 1 in
> the list, therefore the 13 entries returned are the first 13 entries
> in the list, and the target is the third one.
>
> A server-generated context identifier MAY be returned to clients. A
> client receiving a context identifier MUST return it unchanged, or
> not return it at all in a subsequent request which relates to the
> same list. The purpose of this interaction is to enhance the
> performance and effectiveness of servers which employ approximate
> positioning.
>
>
>6. The Controls
>
> Support for the virtual list view control extension is indicated by
> the presence of the OID "2.16.840.1.113730.3.4.9" in the
> supportedControl attribute of a server's root DSE.
>
>6.1. Request Control
>
> This control is included in the SearchRequest message as part of the
> controls field of the LDAPMessage, as defined in Section 4.1.12 of
> [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". If
> this control is included in a SearchRequest message, a Server Side
> Sorting request control [SSS] MUST also be present in the message.
> The controlValue, an OCTET STRING, is the BER-encoding of the
> following SEQUENCE:
>
> VirtualListViewRequest ::= SEQUENCE {
> beforeCount INTEGER (0..maxInt),
> afterCount INTEGER (0..maxInt),
> CHOICE {
> byoffset [0] SEQUENCE {
> offset INTEGER (0 .. maxInt),
> contentCount INTEGER (0 .. maxInt) },
> greaterThanOrEqual [1] AssertionValue },
> contextID OCTET STRING OPTIONAL }
I am surprised that negative offsets are not allowed, as allowed
in many GUI list controls. Possibly the designers intend that
reversing sorting be used instead. I note, however, that reverse
sorting may require the client to reverse the results to get the
desired behavior in the GUI. Adding negative offsets to this control
is likely straight forward.
It may be appropriate to allow the CHOICE to be extensible. That
is, there may be other appropriate ways of selecting the target
entry.
And doesn't the CHOICE need to be given a identifier?
> beforeCount indicates how many entries before the target entry the
> client wants the server to send. afterCount indicates the number of
> entries after the target entry the client wants the server to send.
> offset and contentCount identify the target entry as detailed in
> section 4. greaterThanOrEqual is an attribute assertion value defined
> in [LDAPv3].
s/attribute assertion value/matching rule assertion value/
> The assertion value is encoded according to the
> attributeDescription in the sort control [SSS].
This statement may confuse some folks into believing the
assertion value should conform to the attributeDescriptions
value syntax, the sort control's matching rule's assertion
syntax. It should be reworded.
> If present, the value
> supplied in greaterThanOrEqual is used to determine the target entry
> by comparison with the values of the attribute specified as the
> primary sort key. The first list entry who's value is no less than
> (less than or equal to when the sort order is reversed) the supplied
> value is the target entry. If present, the contextID field contains
> the value of the most recently received contextID field from a
> VirtualListViewResponse control.
What if the client has two different virtual lists? Should
the contextID be associated with a particular virtual list?
Also, is the client free to change any and all search/VLV
parameters associated with a virtual list and, hence, a
contextID?
> The type AssertionValue and value
> maxInt are defined in [LDAPv3]. contextID values have no validity
> outside the connection on which they were received. That is, a client
> SHOULD NOT submit a contextID which it received from another
> connection, a connection now closed, or a different server.
I think it would be sufficient to drop "a connection now closed".
The phrase might be viewed as qualifying "another connection".
As there is no way a contextID can be sent on a closed connection,
"another connection" should include "a now-closed connection".
Why is this a SHOULD NOT instead of a MUST NOT?
>6.2. Response Control
>
> If the request control is serviced, this response control is included
> in the SearchResultDone message as part of the controls field of the
> LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
>
> The controlType is set to "2.16.840.1.113730.3.4.10". The criticality
> is FALSE (MAY be absent).
If FALSE, the criticiality field SHALL be absent. See Section
5.1 of RFC 2251.
> The controlValue, an OCTET STRING, is the
> BER-encoding of the following SEQUENCE:
>
> VirtualListViewResponse ::= SEQUENCE {
> targetPosition INTEGER (0 .. maxInt),
> contentCount INTEGER (0 .. maxInt),
> virtualListViewResult ENUMERATED {
> success (0),
> operationsError (1),
> unwillingToPerform (53),
> insufficientAccessRights (50),
> busy (51),
> timeLimitExceeded (3),
> adminLimitExceeded (11),
> sortControlMissing (60),
> offsetRangeError (61),
> other(80),
> ... },
> contextID OCTET STRING OPTIONAL }
How does the server indicate that the assertion value sent
is invalid?
> targetPosition gives the list offset for the target entry.
> contentCount gives the server's estimate of the current number of
> entries in the list. Together these give sufficient information for
> the client to update a list box slider position to match the newly
> retrieved entries and identify the target entry. The contentCount
> value returned SHOULD be used in a subsequent VirtualListViewRequest
> control. contextID is a server-defined octet string. If present, the
> contents of the contextID field SHOULD be returned to the server by a
> client in a subsequent VirtualListViewRequest control.
> The virtualListViewResult codes which are common to the LDAP
> searchResponse (adminLimitExceeded, timeLimitExceeded, busy,
> operationsError, unwillingToPerform, insufficientAccessRights,
> success, other) have the same meanings as defined in [LDAPv3], but
> they pertain specifically to the VLV operation.
This says:
resultCode.busy and virtualListViewResult.busy mean the
same thing when returned in a VLV result done PDU.
That is:
resultCode.busy means the server is too busy to perform this
operation, the VLV operation.
virtualListViewResult.busy means the server is too busy to
peform this operation, the VLV operation.
also: s/searchResponse/searchResultDone/
> For example, the
> server could exceed an administration limit while processing a
> SearchRequest with a VirtualListViewRequest control. However, the
> same administration limit would not be exceeded should the same
> SearchRequest be submitted by the client without the
> VirtualListViewRequest control.
"same administrative limit"?
If you would have said "a VLV operation specific administrative
limit", I might have bought into a more-specifc code. That is, if
the server has an administrative limit on the number of VLV operations
a client can have outstanding, VirtualListViewRequest.adminLimitExceeded
may be returned instead of resultCode.adminLimitExceeded.
However, since you said "same", I find these codes problematic.
The current wording implies that the server, when it detects an
error condition with this operation, is to determine which code is
more appropriate based upon whether it believes a different operation
would fail due to same conditions.
Consider timeLimitExceeded. If timeLimit is exceeded, this specification
implies the server needs to determine whether it would have been
exceeded if the VLV control was not present. So, the server must
determine whether or not an operation without the control would
have failed if given the same amount of time. Yiks.
I cannot possible see why VirtualListViewRequest.operationsError
(indicating a problem due to sequencing of this operation with
other operations) is needed.
> In this case, the client can
> determine that an administration limit has been exceeded in servicing
> the VLV request, and can if it chooses resubmit the SearchRequest
> without the VirtualListViewRequest control.
Maybe the client should try the VLV operation again, but with
different search parameters.
> insufficientAccessRights means that the server denied the client
> permission to perform the VLV operation.
If the server has a general mechanism for controlling access to
controls, returning a control specific error code is a royal pain
and is quite problematic... if each control has a specific
insufficientAccessRights error code, then what code is be returned
when multiple controls are not allowed? When is a server to return
vlv.insufficientAccessRights over someother.insufficientAccessRights
over resultcode.insufficientAccessRights.
Additional codes should be restricted to those indicating more
specific conditions than existing codes. This document needs
to describe, for each new code, what the more specific condition
indicated associated with each new code is.
> If the server determines that the results of the search presented
> exceed the range specified in INTEGER values, it MUST return
> offsetRangeError.
>6.2.1 virtualListViewError
>
> A new LDAP error is introduced called virtualListViewError. Its value
> is 76.
Document should note that in the case where IANA were to
assign a different result code, it should replace 76.
> If the server returns any code other than success (0) for
> virtualListViewResult, then the server SHOULD return
> virtualListViewError as the resultCode of the SearchResultDone
> message.
s/SHOULD/MUST/, otherwise the client would not be given a clear
indication of THE error condition detected.
This text needs to be clarified to indicate that
if resultCode.virutualListViewError is returned, then
virtualListViewResult MUST NOT be success (as
virtualListViewResult indicates the specific error
condition).
and:
if resultCode.virtualListViewError is not returned, then
virtualListViewError SHOULD be success and its value
MUST be ignored (as the condition is indicated by
the result code).
The rest of this subsection should be moved to an "IANA Considerations"
section.
> [Note to the IESG/IANA/RFC Editor:
> It is requested that IANA register the LDAP result code
> virtualListViewError (76) upon Standards Action by the IESG. The
> value 76 has been suggested by experts, had expert review, and is
> currently being used by some implementations. The following
> registration template is suggested:
>
> Subject: LDAP Result Code Registration
> Person & email address to contact for further information: Jim
> Sermersheim
> Result Code Name: virtualListViewError
> Specification: RFCXXXX
> Author/Change Controller: IESG
> Comments: request LDAP result codes be assigned
> ]
The IANA Consideration section needs to request the registration
of the discoverable protocol mechanism as well. Additionally, this
section should detail the assignment of the OID used in this document.
See RFC 3383.
>
>7. Protocol Example
>
> Here we walk through the client-server interaction for a specific
> virtual list view example: The task is to display a list of all 78564
> people in the US company "Ace Industry".
s/people/persons/ and use (objectClass=person) below. This removes
ambiguity causes be people not represented by an inetOrgPerson object.
> This will be done by
> creating a graphical user interface object to display the list
> contents, and by repeatedly sending different versions of the same
> virtual list view search request to the server. The list view
> displays 20 entries on the screen at a time.
>
> We form a search with baseDN "o=Ace Industry,c=us"; search scope
> subtree; filter "(objectClass=inetOrgPerson)".
s/baseDN/baseObject
s/subtree/wholeSubtree/
> We attach a server
> sort order control to the search, specifying ascending sort on
s/search/search request/ (likewise below)
> attribute "cn". To this search, we attach a virtual list view request
> control with contents determined by the user activity and send the
> search to the server. We display the results from each search in the
> list window and update the slider position.
>
> When the list view is first displayed, we want to initialize the
> contents showing the beginning of the list. Therefore, we set
> beforeCount to 0, afterCount to 19, contentCount to 0, offset to 1
> and send the request to the server. The server duly returns the first
> 20 entries in the list, plus the content count = 78564 and
> targetPosition = 1.
s/=/of/ e.g., use English instead of a psuedo formal language.
likewise below
> We therefore leave the scroll bar slider at its
> current location (the top of its range).
>
> Say that next the user drags the scroll bar slider down to the bottom
> of its range. We now wish to display the last 20 entries in the list,
> so we set beforeCount = 19, afterCount = 0, contentCount = 78564,
> offset = 78564 and send the request to the server. The server returns
> the last 20 entries in the list, plus the content count = 78564 and
> targetPosition = 78564.
>
> Next the user presses a page up key. Our page size is 20, so we set
> beforeCount = 0, afterCount = 19, contentCount = 78564, offset =
> 78564-19-20 and send the request to the server. The server returns
> the preceding 20 entries in the list, plus the content count = 78564
> and targetPosition = 78525.
>
> Now the user grabs the scroll bar slider and drags it to 68% of the
> way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9,
> afterCount = 10, contentCount = 78564, offset = 53424 and send the
> request to the server. The server returns the preceding 20 entries in
> the list, plus the content count = 78564 and targetPosition = 53424.
>
> Lastly, the user types the letter "B". We set beforeCount = 9,
> afterCount = 10 and greaterThanOrEqual = "B". The server finds the
> first entry in the list not less than "B", let's say "Babs Jensen",
> and returns the nine preceding entries, the target entry, and the
> proceeding 10 entries. The server returns content count = 78564 and
> targetPosition = 5234 and so the client updates its scroll bar slider
> to 6.7% of full scale.
>
>
>8. Notes for Implementers
>
> While the feature is expected to be generally useful for arbitrary
> search and sort specifications, it is specifically designed for those
> cases where the result set is very large. The intention is that this
> feature be implemented efficiently by means of pre-computed indices
> pertaining to a set of specific cases. For example, an offset
> relating to "all the employees in the local organization, sorted by
> surname" would be a common case.
>
> The intention for client software is that the feature should fit
> easily with the host platform's graphical user interface facilities
> for the display of scrolling lists. Thus the task of the client
> implementers should be one of reformatting up the requests for
> information received from the list view code to match the format of
> the virtual list view request and response controls.
>
> Client implementers MUST be aware that any offset value returned by
> the server might be approximate. Do not design clients that only
> operate correctly when offsets are exact.
>
> Server implementers using indexing technology which features
> approximate positioning should consider returning context identifiers
> to clients. The use of a context identifier will allow the server to
> distinguish between client requests which relate to different
> displayed lists on the client. Consequently the server can decide
> more intelligently whether to reposition an existing database cursor
> accurately to within a short distance of its current position, or to
> reposition to an approximate position. Thus the client will see
> precise offsets for "short" repositioning (e.g. paging up or down),
> but approximate offsets for a "long" reposition (e.g. a slider
> movement).
>
> Server implementers are free to return an ldap result code of
> virtualListViewError and a virtualListViewResult of
> unwillingToPerform should their server be unable to service any
> particular VLV search. This might be because the resolution of the
> search is computationally infeasible, or because excessive server
> resources would be required to service the search.
>
> Client implementers should note that this control is only defined on
> a client interaction with a single server. If a search scope spans
> multiple naming contexts that are not held locally, search result
> references will be returned, and may occur at any point in the search
> operation. The client is responsible for deciding when and how to
> apply this control to the referred-to servers, and how to collate the
> results from multiple servers.
Are all continuations within scope fo the search returned for each
VLV request? If there are large number of continuations to return,
this would make VLV use excessive bandwidth. Some mechanism to
limit the return of continuations should be provided.
>9. Relationship to "Simple Paged Results"
>
> These controls are designed to support the virtual list view, which
> has proved hard to implement with the Simple Paged Results mechanism
> [SPaged]. However, the controls described here support any operation
> possible with the Simple Paged Results mechanism. The two mechanisms
> are not complementary; rather one has a superset of the other's
> features. One area where the mechanism presented here is not a strict
> superset of the Simple Paged Results scheme is that here we require a
> sort order to be specified. No such requirement is made for paged
> results.
Just like [SPaged], only some ordering is needed for the control
to be usable. If no sort control, the server is free to order the
results in any why it chooses... but it must order the results when
paging is used. Same approach works for VLV. The restriction
should be lifted as it is unnecessary.
>10. Security Considerations
>
> Server implementers may wish to consider whether clients are able to
> consume excessive server resources in requesting virtual list
> operations. Access control to the feature itself; configuration
> options limiting the featureÆs use to certain predetermined search
> base DNs and filters; throttling mechanisms designed to limit the
> ability for one client to soak up server resources, may be
> appropriate.
s/Æ/'/
> Consideration should be given as to whether a client will be able to
> retrieve the complete contents, or a significant subset of the
> complete contents of the directory using this feature. This may be
> undesirable in some circumstances and consequently it may be
> necessary to enforce some access control.
or administrative limit.
From [SPaged]:
Clients can, using this control, determine how many entries match a
particular filter, before the entries are returned to the client.
This may require special processing in servers which perform access
control checks on entries to determine whether the existence of the
entry can be disclosed to the client.
This applies to this control as well.
> Clients can, using this control, determine how many entries are
> contained within a portion of the DIT. This may constitute a security
> hazard. Again, access controls may be appropriate.
Spell DIT out on first use.
> Server implementers should exercise caution concerning the content of
> the contextID. Should the contextID contain internal server state, it
> may be possible for a malicious client to use that information to
> gain unauthorized access to information.
>
>
>11. Acknowledgements
>
> Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co-
> authored previous versions of this document.
>
>
>12. Normative References
>
> [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
> Specification of Basic Notation", 1994.
>
> [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules:
> Basic, Canonical, and Distinguished Encoding Rules",
> 1994.
>
> [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
> Access Protocol (v3)", Internet Standard, RFC 2251,
> December, 1997.
>
> [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control
> Extension for Server Side Sorting of Search Results",
> RFC 2891, August, 2000.
>
> [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
Need reference to RFC 3377.
>13. Informative References
>
> [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
> Control Extension for Simple Paged Results Manipulation",
> RFC2696, September 1999.
Need reference to RFC 3383.