Subject: Re: Continuation References vs. Referrals

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 20 Jan 2005 14:45:48 -0700

>>> Hallvard B Furuseth <[email-masked]> 12/7/04 12:09:18 PM
>>>
>> 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.

Yes, when this was moved from the <dn> list item, I forgot to
genericize the language.

>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.

Yes.

>> 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.

ok.

>> 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:".

got it

>> 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?

ok

>> 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.

ok

>> 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".)

I changed the Referral text back to "Clients". It really doesn't
matter, and this way it's consistent.

>> 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.

right

>> 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.

got it

>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.

"within the search scope"? maybe better is "for a Search operation".

>> - 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/.

yes

>> - 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/.

right, same for other instances of URL in the "rules for LDAP URLs"

>-- 
>Hallvard

Thanks Hallvard,
 
Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Jan 2005 23:41:29 +0100

> "within the search scope"? maybe better is "for a Search operation".

No, the counter should also be used when a non-search gets a referal to
a server which returns another referral and so on.  Or with extensions
like Delete Subtree.

BTW, just for reference: The text in question is this sentence from
4.1.10 Referral:

   Some
   implementations use a counter that is incremented each time referral
   handling occurs for an operation, and these kinds of implementations
   MUST be able to handle at least ten nested referrals between the root
   and a leaf entry.

-- 
Hallvard