Re: I-D ACTION:draft-ietf-ldapext-namedref-00.txt

[Mark Smith <mcs@netscape.com>]

sanjay jain wrote:
> 
> ##########
> 5.1.1.3.  Search with one level scope
> 
> For search operations, once the base object has been found and deter-
> mined not to contain a ref attribute, the search may progress. Any
> entries matching the filter and scope of the search that do NOT
> contain
> a ref attribute are returned to the client normally as described in
> [RFC2251]. Any entries matching the filter and one level scope that do
> 
> contain a ref attribute must be returned as referrals as described
> here.
> ##########
> 
>      Normally referral entries will not match the given filter.
> Should the last
>      line be something else ?  And instead of 'returned as referrals'
> should it be
>      returned as 'continuation references ?
> 
>     Similar comment on '5.1.1.4.  Search with subtree scope'.

I think you are correct.


> ...
> Some other comments:
> 
> 1. I think this document does not describe how 'attributes' and
> 'filter' fields
>     in the LDAP URI should be handled, particularly in case of search
>     operations.

Section 4.1.11 of RFC 2251 does talk about how to handle filters but not
an attributes list.  Is that a bug in 2251 or should we add it to the
named referrals document?


> ...
> 2. If the DN part in the LDAP URI is different from the DN of the
> referral
>     object then the referral behaves like an alias too.  Is that
> good/OK ?

I think this is useful functionality.  We have customers who use it
today.


> ...
> 3. How about if 'ref' attribute only has LDAP host and port and in
> case
>     of onelevel and subtree search operations DN of the referral
> object
>     should be appended (and '??base' in case of onelevel search) by
> the
>     server ?  Do we lose lot of functionality with this simplification
> ?

I'd like to keep the ability to specify a new target DN at least.

-- 
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"