Subject: RE:referrals question

From: Apurva Kumar <[email-masked]>
Date: Wed, 3 Sep 2003 18:38:20 +0530

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.

> I note that another case where the server should provide the dn
> part is where a reference object has been placed and the referral
> attribute has the dn part populated (and that dn is different from the
> dn of the reference object). If the name being resolved is subordinate
> to that reference object, the dn of the referral(s) should reflect the DN
> held in the referral attribute plus the unresolved portion of the
original
> dn on the operation.

I guess, if the <dn> part of the referral attribute is not the DN of the
referral entry, then the entry should be an alias rather than a referral
object. However, if such referral entries are allowed, then they should be
treated as aliases with aliased object name given by the <dn> part of the
referral attribute. A referral generated after dereferencing such an alias
will be identical to the referral you describe above.

Regards,
Apurva

-----
Apurva Kumar,
Research Staff Member,
IBM India Research Lab
Phone: +91-11-26861100
Fax: +91-11-26861555

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 03 Sep 2003 07:47:52 -0600

>>> Apurva Kumar <[email-masked]> 9/3/03 7:08:20 AM >>>
>Jim,
>

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

---

From: Apurva Kumar <[email-masked]>
Date: Wed, 3 Sep 2003 19:25:18 +0530

> 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

If a referral is generated due to derefencing of an alias, then the
referral URL should be an LDAP URL.

Apurva

                      "Jim Sermersheim"                                                                                                
                      <[email-masked]        To:       Apurva Kumar/India/IBM@IBMIN                                                  
                      >                        cc:       <[email-masked]>                                                   
                                               Subject:  RE:referrals question                                                         
                      09/03/03 07:17 PM                                                                                                

>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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 03 Sep 2003 08:23:35 -0600

>>> Apurva Kumar <[email-masked]> 9/3/03 7:55:18 AM >>>

Not true. "Other kinds of URLs may be returned, so long as the
operation could be performed using that protocol.". Nothing mandates
that LDAP URLs be used in any scenario (except for the scenario where
the referral points to an LDAP DSA.
 
Jim

---

From: Apurva Kumar <[email-masked]>
Date: Wed, 3 Sep 2003 20:05:40 +0530

Jim,

Since a referral generated due to alias dereferencing, will still point
somewhere inside the DIT, the assumption that it will contain an LDAP URL
does not sound unreasonable. I guess, to be more specific, [Protocol] might
say when discussing the scenario: "In this case the URL returned in the
referral MUST be an LDAP URL".

Please let me know your comment on this.

Thanks,
Apurva

                      "Jim Sermersheim"                                                                                                
                      09/03/03 07:53 PM                                                                                                

>referral URL should be an LDAP URL.
Not true. "Other kinds of URLs may be returned, so long as the operation
could be performed using that protocol.". Nothing mandates that LDAP URLs
be used in any scenario (except for the scenario where the referral points
to an LDAP DSA.

Jim

---

From: John McMeeking <[email-masked]>
Date: Wed, 3 Sep 2003 10:23:17 -0500

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"                                                                                     
                      <[email-masked]>          To:       <[email-masked]>                                            
                      Sent by:                    cc:       <[email-masked]>                                     
                      owner-ietf-ldapbis@O        Subject:  RE:referrals question                                           
                      penLDAP.org                                                                                           

                      09/03/2003 08:47 AM                                                                                   

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Sep 2003 08:35:09 -0700

At 02:35 PM 8/26/2003, Jim Sermersheim wrote:
>All,
>
>Currently, [Protocol] (Section 4.1.10) says: "If an alias was
>dereferenced, the <dn> part of the URL MUST be present, with the new
>target object name". This assumes....

I think this is assuming that the URL is an LDAP URL.  If you
just s/the URL/a LDAP URL/ here, the sentence is fine.  Likewise
in following sentences.

I think we need only specify handling of LDAP URLs.  While the
protocol is capable of transferring other URLs, specification of
such should be left to other documents.  We likely should clarify
that as well.  That is, in 4.1.11 and 4.5.3),
   Other kinds of URLs may be returned (as specified in future
   documents) so long as the operation could be performed using
   that protocol.

Thoughts?

Kurt

>that there is a <dn> part in the
>referral URL. [Protocol] says that other kinds of URLs can be returned.
>There are no requirements that all types of URLs contain a place for a
>DN. So, if an alias is dereferenced while resolving a name, and the
>referral contains non-LDAP URLs, is the server expected to:
>
>a) not return those non-LDAP referrals?
>b) only return non-LDAP referrals where the server knows the format,
>the URL format allows a DN, and the server fills in the DN part
>c) return the non-LDAP referrals as they exist in the data store (if
>they exist at all), even if no knowledge of DN placement is known.
>
>I note that another case where the server should provide the dn part is
>where a reference object has been placed and the referral attribute has
>the dn part populated (and that dn is different from the dn of the
>reference object). If the name being resolved is subordinate to that
>reference object, the dn of the referral(s) should reflect the DN held
>in the referral attribute plus the unresolved portion of the original dn
>on the operation.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 03 Sep 2003 09:52:10 -0600

>>> John McMeeking [email-masked]> 9/3/03 9:23:17 AM >>

I agree. This was not done intentionally on my part (more a lucky
happenstance), and I kind of doubt it was the intent of the original
authors. I agree that if we choose to tie the DN, filter, etc
specifically to LDAP URLs, there need to be clarifications.

>above components (server, DN, filter,...) to the type of URL.

Yes, this is what I feel is missing. Some kind of definition of
reference "parts" and a forward looking statement requiring those parts
(or equivalences) to be defined in future reference types.
 
Currently, it is only implied by some language in Protocol and RFC 3296
that some of these fields are required to perform certain LDAP
operations.
 
>Having said all that, is there any reason to not require LDAP URLs?

Good question. Though I assume one could reasonably say referrals to
DSML, DAP, XLDAP, etc. are things people want. Another proposal is to
allow any URL, so long as the <path> and <query> parts adhere to LDAP
URL.
 
Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 03 Sep 2003 09:56:15 -0600

Yes, I see two choices.
1) Make references to fields of LDAP URL explicit (rather than making
it appear that any future URL will have these fields), or
2) Generalize the fields of a reference URL that are required, and
state that future URLs must accommodate these.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 9/3/03 9:35:09 AM >>>

Thoughts?

Kurt