RE: Implementation of 4.5.2 and 4.5.3 of RFC 2251

[Robert Streich <streich@austin.apc.slb.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.

> Probably the conversation is getting out of topic so I suugest, If everybody
> is agree, to change 
> to the conversation to the ietf mailing list "ldap-ext@netscape.com" or
> other suugested mail-list. 
> I'll wait for a confirmation.

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.

bob