Re: aliased bases

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

Thanks, that was quite informative.  Having read through that I think there is one important
difference that suffix aliases are and should be capable of that would not be covered in the
specification of normal aliases.  Namely, the ability to pose as another name space for all
operations, not just searching.  Perhaps I should have called the feature suffix
masquerading....

Ludovic Poitou - Sun Microsystems wrote:

> Hi All,
>
> In April, we submitted a internet draft on the use of aliases within LDAP.
>                              Use of Aliases within LDAP
>                           <draft-byrne-ldap-alias-00.txt>
>
> You can find it at :
>
> http://www.ietf.org/internet-drafts/draft-byrne-ldap-alias-00.txt
>
> There was very little discussion about it. But comment are welcome.
>
> Ludovic Poitou.
> Sun Microsystems.
>
> > > Hi Robert,  I have not seen any RFC specifications for aliases in LDAP.
> > Maybe you can > let me know which RFCs they are.
> >
> > They get a brief mention in a few places in the v2 and v3 RFCs, but the
> > alias objectclass is described in RFC-2256. I haven't seen the '96
> > version of X.521, but the '93 version gave the alias objectclass an
> > attribute of aliasedEntryName, which is also the name in Alvestrand's
> > OID database. The RFC, however, uses aliasedObjectName.
> >
> > >   The way the DNs are composed and looked at in the openLDAP source is quite primitive
> > > and does not currently involve looking at all the components in the parentage of the
> > > DN.  That is, there is no traversal up the DIT to see if any of the parents is an
> > > alias.  Without that you cannot use one entry to alias another for the suffix.
> > >
> > >   Doing the walk up the DIT should not be too bad although that might cause havoc with
> > > some of the backends.  I know that some of them do not define all the entries that
> > > would be required for the DIT, they emulate them using attributes from the children, so
> > > what happens if it hits a blank?  The suffix alias solution still seems like a good one
> > > to me although I may look into doing the DIT walk.
> >
> > I think that the dereferencing might best be done in the backend code
> > rather than in the next level up. I took a few minutes to look at the
> > code tonight and it looks like the best place to add it for the ldbm
> > backend is where there is a test to see if dn2entry() fails. dn2entry()
> > walks up the DIT to see what portion of the DN it can match and writes
> > it into a buffer that gets passed in the call. If you added a function
> > to test if the "returned" DN was an alias, you could continue by swapping
> > out the value of aliasedObjectName with the "alias" portion of the
> > original DN.
> >
> > I need to have aliases in my DIT, so I'm going to give this a try.
> > Unfortunately, the v2 RFC only specifies how aliases are to be
> > dealt with when searching and modifying. It doesn't mention anything
> > in add, delete, etc. Any ideas?
> >
> > As a general question: Is the openLDAP source headed towards v3? Should
> > I just be looking at the v3 RFCs?
> >
> > If you're interested in continuing this thread, I suppose we ought to
> > move it to the "devel" list, eh? Feedback would be nice, expecially
> > from anyone who has dug into this code before.
> >
> > bob
> >
> >
> > Robert Streich                        streich@slb.com
> > Schlumberger                  512-331-3318 (voice)
> > Austin Research                       512-331-3760 (fax)

--
Will Ballantyne             GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca