Subject: Comments on namedref draft

From: [email-masked] (Richard V Huber)
Date: Mon, 23 Apr 2001 16:32:41 -0400

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 23 Apr 2001 14:05:56 -0700

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

We would lose the flexibility provided by RFC 2251:
   Other kinds of URLs may be returned, so long as the operation
   could be performed using that protocol.

While RFC 2251 could use some clarification in this area, I believe
that it's generally accepted that clients should ignore URLs they
cannot process (either because they are not of a scheme the client
recognizes, or have unrecognized critical extension, or other
reason).

>but why make it "illegal" for the server to do them if it wishes?

I believe a SHOULD would be fine.  This recommends a practice
consistent with the data model but would allows behaviors
which do not violate the interface.

>I think this needs some discussion on the list.

I should reword this a bit.  The intent was not to disallow the
server from chaining the request, but was to recommend the server
not return a referral to the bind operation (as the semantics of
such are ill defined).

> As this text stands,