[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on namedref draft
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