Re: Continuation References vs. Referrals

>>> Hallvard B Furuseth <[email protected]> 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