Re: Last call on 'Named Subordinate References in LDAP Directories'

[mcs@netscape.com (Mark C Smith)]

Roland Hedberg wrote:
> 
> The document in last call is:
> 
> http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-namedref-03.txt

I few last minute last call comments:

1) Section 4.1 (The referral Object Class):  I can't think of a good
reason for the 'ref' attribute type to be mandatory.  I would like to
see it changed to a MAY.


2) Section 6 (Named Subordinate References): Here and in other places in
the document it is noted that the server MAY omit the DN part of the URL
in certain circumstances.  But consider the following two LDAP URLs:

    a)  ldap://hostb/
    b)  ldap://hostb

The first one (a) is an LDAP URL that includes a zero length DN, i.e.,
it points to the root DSE or the "root of all roots" on hostb.  The
second (b) is an LDAP URL that does not include a DN.  RFC 2255 (The
LDAP URL Format) is silent on this topic but
draft-ietf-ldapbis-url-00.txt says:

    If no dn is given, the default is the zero-length DN, ""

and section 4.1.11 of RFC 2251 says:

   ... If the <dn> part is
   present, the client MUST use this name in its next request to
   progress the operation, and if it is not present the client will use
   the same name as in the original request.

This seems like a small conflict.  In my opinion, RFC 2251 "wins"
because draft-ietf-ldapbis-url-00.txt is still a draft and common usage
(in my experience) is for LDAP clients to interpret a URL like
ldap://hostb as one that does not include a DN.  So I believe that the
trailing "/" should be removed from all URLs in the Named Subordinate
References draft that include one.  But I don't see a way to omit the DN
and also include other options.  Neither 2251 nor
draft-ietf-ldapbis-url-00.txt allow you to use a URL like this:

    ldap://hostb??one

(the dn is required if anything after it is included in the URL).  If
other options are present, the server will need to include the DN in the
LDAP URL it returns to the client in the Referral protocol field.


3) Section 7.2 (Target object considerations), 2nd paragraph: The way
this is worded is a little ambiguous.  Do we mean to say that the server
SHOULD trim the scope, filter, and attribute list from the URL before
returning it?  I think the "e.g.," should be dropped.


4) Section 7.2 (Target object considerations), Case 4: I would like to
see a detailed algorithm specified that a server SHOULD use to construct
the URI value to be returned.  Why?  Because it is critical for
interoperability that all servers produce the same Referral given the
same referral objects in the DIT.  I can produce some text based on what
was in the expired Christopher Lukas Named Referral" I-D if that would
help.  This same comment applies to Case 4 of section 7.3 (Base Object
Considerations).


5) Section 7.4 (Search Continuation Considerations): I was surprised to
see that for a one-level search the server is not required to include a
scope of base in the URIs returned.  I think this can be handled
correctly by the client without the server adding a scope of base, but
it seems better to have the server do this work.  If a client implements
referral processing as described in RFC 2251 (which all should today),
the right thing will not happen unless the server includes the scope of
base in the returned URLs.

I also have several minor editorial comments (typos, etc.) that I will
send to the author tomorrow.

-Mark Smith
 Netscape Directory Product Development