RE: Implementation of 4.5.2 and 4.5.3 of RFC 2251

["Cabrera Borges, J.P." <J.P.CabreraBorges@research.kpn.com>]

	>The attribute I describe "non-specific subordinate reference" is
the
> > same that has been 
> > 	already described on draft-ietf-ldapext-referral-00.txt section 5.3.
> > Thank you for the point.
> > 
> > 	But, On this draft I don't understand the DN:
> > 
> > 	dn: ref=ldap://hostB/o=abc,c=us
> > 
> >       Is this a valid DN? Formally speaking, it is valid but I think it
> has
> > gone out of all schemata.
> >       What parts of the DIT are affected by this entry?
> >       The draft says that "is similar to non-specific sub-ordinate
> reference
> > concept found in X.500"
> > so then it affects to all the leafes entries...
> > How does this entry affects to the search operations?
> 
> These entries are similar to the way referrals are handled in OpenLDAP
> now. In the current version, referrals have to be leaf entries and the
> ref attribute has to be used in the DN of the entry. Note that section
> 5.1 removes both of those requirements.
> 
> Formally speaking, the DNs have problems since the comma would have to
> be escaped to make the ",c=us" part of the URL rather than another RDN.
> 
> I don't really understand this section of the draft either, since I don't
> see what the utility of the additional attributes is with respect to
> searching. Using the example, both a one-level and subtree search of
> the root DSE for the server, regardless of the search filter, should
> return continuation references for all of the referrals. A base search
> wouldn't find them at all. The only time the attributes would be
> meaningful is if you were looking for referrals, i.e., included the
> manageDsaIT control, which would "turn off" the referral so that it could
> be returned as a search result.
> 
I understand the ref attribute in the way to make references to other 
services in general i.e. a file, a web page, or even to provided an "alias"
to
another entry where I can find more information about one item, for example,
if I work in two companies or two departments, It can be interesting to 
put a "link" from one entry to the other. But, I think the parameter is not 
useful for browsing through LDAP servers as it is the intention of this
Draft. 

	Until now, I didn't know the way openLDAP store the referrals.
	Does Somebody know
	the reason that leads the developers to do it on that way?, What are
the 
	advantage? 
	On a first view I think it gets more difficult the access to X.500.

> Since this draft has technically expired and does have a gap or two,
> further discussion should go to the ldap-ext list. Not because of the
> topic, but because it addresses the specifics of the draft and that's
> the list that counts in that case.
> 
	OK. I have posted some questions about this Draft to the IETF list.

	Regards,
	----
	Juan Pablo Cabrera Borges.
	KPN Research.