Comments on namedref draft

[rvh@qsun.mt.att.com (Richard V Huber)]

A few comments on draft-zeilenga-ldap-namedref-03.txt.

Section 4.2 says:

   If the URI contained in a ref attribute value refers to a LDAP
   [RFC2251] server, it MUST be a in the form of a LDAP URL [RFC2255].
   In general, the LDAP URL should not contain an explicit scope
   specifier, filter, attribute description list, or any extensions.  If
   the DN part is absent (or empty), the LDAP URL refers to entry of the
   same DN as the referral object in which the value is held.

   Other URI schemes MAY be used but MUST refer to services which are
   capable of completing operations referred to the services.  All URIs
   contained in a ref attribute MUST point to services which are equally
   capable of handling operations referring to these services.

I'm not clear what it means to return something other than an LDAP URL
here.  What if, for example, I built a referral where the URI was an
HTTP URL:

  http://www.anywho.com/cgi-bin/htwpq?qtype=rfull&name=john_smith&tel=212+555+1212&state=ny

It seems to satisfy the criteria - it is a valid URI, and given this
URL the service will indeed complete a lookup operation and give
address information for the (mythical) John Smith of New York, NY.  But
in practice, what could the client do with this or any other URI that
does not point to an LDAP server?

What would we break if we required referrals to be LDAP URLs?

In the same section:

   The referential integrity of the URI SHALL NOT be validated by the
   server holding or returning the URI (whether as part of the value of
   the attribute or as part of a referral result or search reference
   response).

I'm not clear why we need to be so emphatic here.  I believe that the
client MUST NOT expect the server to do referential integrity checks,
but why make it "illegal" for the server to do them if it wishes?

In Section 7.6.1:

   7.6.1 Bind

   A server SHOULD process a bind request as if it held no referral
   objects.  That is, if the bind name is a referral object or is
   subordinate to a referral object, the server SHOULD process the
   request normally as appropriate for a non-existent bind name (e.g.
   return invalidCredentials).

I think this needs some discussion on the list.  As this text stands,
it would make it very difficult to split a large directory into several
pieces on different servers.  Other current drafts (e.g.
draft-reed-ldup-inheritance-00.txt) seem to be working towards
supporting a more distributed environment.  I would prefer a MAY here
(or remove section 7.6.1 entirely) so we can address this issue in more
detail in future work.

Rick Huber