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

[Mark Smith <mcs@netscape.com>]

Rob Weltman wrote:
> 
> ...
> > If the type of operation requested is not a search and the URI contained
> > in the ref attribute of the requested target object is an LDAP URI
> > [RFC2255], the server should return a modified form of this URL. The
> > returned URL must have only the protocol, host, port, and trailing "/"
> > portion of the URL contained in the ref attribute. The server should
> > strip any dn, attributes, scope, and filter parts of the URL.
> >
> > Example:
> >
> > If the client issues a modify request for the target object of
> > "o=abc,c=us", server A will return
> >
> >         ModifyResponse "referral" {
> >          ldap://hostB/
> >          ldap://hostC/
> >         }
> >
> 
> 
> 
>   That complicates things for the client. Shouldn't the URI be
> rewritten to fully qualify the referred-to entry in this case? So:
>
> 
>         ModifyResponse "referral" {
>          ldap://hostB/o=abc,c=us
>          ldap://hostC/o=abc,c=us
>         }


Actually, I think the trailing slash needs to be stripped off for the
above to be correct (a trailing slash in an LDAP URL specifies the
zero-length DN).  Since LDAP clients need to reuse the original DN when
presented with a referral that does not include a DN, this seems like
the most efficient response:
         ModifyResponse "referral" {
            ldap://hostB
            ldap://hostC
         }

What you suggest is acceptable too Rob.

Also, I don't think the server should strip off the DN (or substitute
the client's) for all non-search operations; it should only do so if the
target DN in the operation is a descendent (i.e., is below) the referral
entry.  The referral entry might point to a different DN entirely and if
the target of the operation is the entry that contains the ref
attribute, the values should be returned intact.


> 
> > If a client requests an operation for which the base or target object is
> > not held by the server, but is subordinate to one or more objects with a
> > ref attribute held by the server, the server must return the referral
> > from the superior held object nearest to the requested base or target
> > object. Nearest superior object with a referral, in this document, means
> > an object superior to the base or target object with the DN that has the
> > most attribute values in common with the DN of the base or target object
> > and contains a ref attribute.
> >
> ...
> 
> > If the client issues an add request where the target object has a DN of
> > "cn=Chris Lukas,o=abc,c=us", server A will return
> >
> >         AddResponse "referral" {
> >          ldap://hostB/
> >          ldap://hostC/
> >         }
> >
>   Same thing here. Shouldn't the server return:
> 
>         AddResponse "referral" {
>          ldap://hostB/cn=Chris Lukas,o=abc,c=us
>          ldap://hostC/cn=Chris Lukas,o=abc,c=us
>         }

Yes, or leave the DN off entirely as I suggest above.  Well, technically
the space in the DN must be encoded as %20.

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