|
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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
|