[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE:referrals question
I think the first sentence of the paragraph (protocol 4.1.10) is critical
for context:
URLs for servers implementing LDAP and accessible via [TCP]/[IP] (v4
or v6) are written according to [LDAPURL]. If an alias was
dereferenced, ...
Other kinds of URLs may be returned, so long as the operation could
be performed using that protocol.
This suggests that the entire discussion of returning a DN in the referral
URL is already in the context of LDAP URL, but that could be reading more
into the document than was intended (in which case some sort of change is
warranted). To return something other than an LDAP URL implies that we are
not using LDAP or not using TCP/IP.
These paragraghs are defining the interaction between a client and server
with respect to how a client handles continuation references. In that
context it seems appropriate to do something like:
1. A referral URL may contain the following components, which are used to
modify the original request: DN, filter, etc.. These components are to be
handled as decribed in the original text (generically - without reference
to LDAP URL)
2. The type of URL returned is dependent on the transport protocol; a
mapping of LDAP to a given transport protocol must include the type(s) of
URLs that are to be used in continuation references and the mapping of the
above components (server, DN, filter,...) to the type of URL.
3. For use of LDAP over TCP/IP, this document defines the use of LDAP
URLs. In addition to the components described above, the referral URL will
contain the target DNS host name, and optionally, port number (I assume
that these are not universal to all URL types that might be of interest).
Having said all that, is there any reason to not require LDAP URLs?
John McMeeking
"Jim Sermersheim"
<jimse@novell.com> To: <kapurva@in.ibm.com>
Sent by: cc: <ietf-ldapbis@OpenLDAP.org>
owner-ietf-ldapbis@O Subject: RE:referrals question
penLDAP.org
09/03/2003 08:47 AM
>>> Apurva Kumar <kapurva@in.ibm.com> 9/3/03 7:08:20 AM >>>
>Jim,
>
>> "If an alias was dereferenced, the <dn> part of the URL MUST
>> be present, with the new target object name". This assumes that
>> there is a <dn> part in the referral URL.
>
>Since an alias entry will contain an LDAP DN in its aliasedObjectName
>attribute (unlike referral attribute which might contain non LDAP URLs),
>the server will always have a <DN> part to return in the referral.
The point is not whether the server has a DN available, rather it has to do
with the format of the referral URL. When using an LDAP URL, all is
well--there is a place for the DN to go. When not using an LDAP URL, there
may not be a DN field. There are no guidelines in [Protocol] or anywhere
else that tell what fields are required in future referral URLs, nor can
any server know ahead of time how to modify any future referral URL in
order to inject a DN.
Jim