Continuation References vs. Referrals

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> 4.5.3. Continuation References in the Search Result 

>      UTF-8 encoded characters appearing in the string 
>      representation of a DN or search filter may not be legal for URLs 
>      (e.g. spaces) and MUST be escaped using the % method in [URI].  

s/URLs/URIs/ or "URIs or URLs"?  I have no time to check the URL/URI
drafts now; will do so later if nobody beats me to it.
The same applies to Referral.


We've forgotten to reflect a number of edits to Referrals in
Continuation References:

For the above text:
Move it below the list: It's misplaced in the <dn> item.
s/DN or search filter/DN, search filter, or other fields/ to match
Referrals.

>    If the server was able to locate the entry referred to by the 
>    baseObject but was unable to search one or more non-local entries, 

Replace "unable to" with "unable or unwilling to", or rewrite the
sentence to use "cannot or will not" as in Referral.

>    A URI for a server implementing LDAP and accessible via [TCP]/[IP] 
>    (v4 or v6) is written as an LDAP URL according to [LDAPURL].  

Nitpick: Move this to just above "SearchResultReference values which are
LDAP URLs follow these rules:".

>    In order to complete the Search, the client issues a new Search 

Maybe
     If the client wishes to progress the Search, it issues...
to indicate that the client is not required to complete the operation?

>    operation for each SearchResultReference that is returned.

This text from Referral is missing:

     If multiple URIs are
     present, the client assumes that any supported URI may be used to
     progress the operation.

>    Clients that follow search continuation references MUST ensure that 
>    they do not loop between servers.

s/Clients/Protocol peers/?
(I don't know why the Referral text says that instead of "clients".)

>    They MUST NOT repeatedly contact 
>    the same server for the same request with the same target entry name, 
>    scope and filter.

s/target entry name, scope and filter/parameters/.
For consistency with referral to server with base object, and in case
extensions were changed.  And for non-LDAP URIs that no longer include
these items, come to think of it.

>    Some clients use a counter that is incremented each 
>    time search result reference handling occurs for an operation, and 
>    these kinds of clients MUST be able to handle at least ten nested 
>    search result references between the root and a leaf entry. 

s/clients/implementations/, or do the reverse with Referrals.

BTW, "between the root and a leaf entry" is another text in Referrals
which does not fit non-Search operations, but I don't have a good
suggestion to fix it - and I don't expect it to be misunderstood either.

>    - The <dn> part of the URL MUST be present, with the new target 
>      object name. The client MUST use this name when following the 
>      reference.

s/MUST use/uses/.

>    - If the <filter> part of the URL is present, the client MUST use 
>      this filter in its next request to progress this Search, and if it 
>      is not present the client MUST use the same filter as it used for 
>      that Search.  

s/URL/LDAP URL/.
s/MUST use/uses/.

-- 
Hallvard