Problems with aliases and searches

[Colin Robbins <[e-mail]>]

Hello,

I am not sure if this is the right list to send this to, please
forgive me if it isn't (but were else are such thing discussed).

Whilst developing a DUA we have come across a problem with searching
subtrees and aliases.  I include here, a message Graeme Lunt sent me
describing the problem, then I'll try to expand a little!

----  Graeme's Message

        There is a distinct problem with aliases in the directory,
        especially when considering the user's perception of the model
        and the UA's ability to represent it.

        Consider the case where the user is browsing the directory -
        the normal mode of working will be to search aliases. 

        A search will return a set of DNs which match but no
        indication of whether or not an alias was dereferenced.

        (Searches (singelevel) may be more commonly used in UA's than
        lists to allow the UA to restrict the view to a single object
        class). 

        Now, when the user finds an entry they wish to delete, they
        will end up deleting the aliased object rather than the alias.
	(Because this is the DN they were returned in the search)

        Unless of course the UA is intelligent - a UA may guess that
        an alias has been de-referenced by comparing the prefix of the
        returned DNs with the position where the single level search
        took place. If they don't match, then it is likely an alias
        has been de-referenced. 

        When the user selects a DN to delete (or modify), the UA can
        ask if the user means the alias or aliased object. If the user
        requests the alias, then the UA has to do some more work. It
        has to perform a search of the form

        objectClass=alias & aliasedObjectName=<aliasedObject>

*       If this search returns more than one result - the UA will have
        to go back to the user to determine which alias to edit - and
        the user may not know!

        However, there is still another problem. Above we said the UA
        could work out if an alias had been de-referenced by comparing
        prefixes.

*       This will not work if the alias references another object at
        the same position in the DIT - they have the same prefix !

        The alternative of assuming the user knows best - they will
        switch on/off search aliases as required - does not work in
        practice. 

        An example of this is when a user (with search aliases on)
        creates a new alias. A relisting at shows the new object
        (actually the de-referenced object), the user then decides the
        alias is wrong and deletes it - and in fact deletes the
        aliased object.

        This all becomes horribly complex when aliases can be
        de-referenced to arbitrary depth.


----  End Graeme's Message

Here's an example...

       1)   c=GB @ o=X-Tel Servives Ltd @ cn=Colin Robbins

       2)   l=Europe @ o=Cosine @ ou=Paradise @ cn= Colin Robbins

       3)   l=Europe @ o=Cosine @ ou=Another Project @ cn= Colin Robbins

       4)   l=Europe @ o=Cosine @ ou=Paradise @ cn=David Goodman

       5)   l=Europe @ o=Cosine @ ou=Paradise @ cn=Project Manager

Entries 2 & 3 are aliases pointing to entry 1).

Entry 5 is an alias pointing to entry 4).   
[ Yes - I know according to the Barker/Kille Internet Draft Entry 5) is a
bad use of alias, but such aliases may still exists in the DIT! ]

Assume I am the manager of the o=Cosine branch of the DIT, and I want
to do some modifications [maybe I have just read the Barker/Kille ID,
and want to remove the bad alias!!!]

I do a a subtree search below o=Cosine for "sn=Robbins" with the
searchalias flag set.  Entry 1) gets returned, with no indication that
an alias has been dereferenced.  (The alias dereference flag in the
common result refers to aliases on route to the base object of the
search, but not after).  Also, I only get one resultant DN, even
though there are 2 aliases.
So as a user, I might blindly delete entry 1).

I can't use subtree search o=Cosine with the "search aliases" flag
off, because the search for "surname = robbins" would fail.

So, I can't do a simple search.

If I was able to guess the result was an alias, I could search the
subtree for "objectclass = alias" and "aliasedobjectname = c=GB @ ...
@ cn=Colin Robbins", and then decide which ones to delete - but that
seems excessive,(and assume I know the real DN, but I guess I probably
would by this stage).  
[I also understand that the '92 standards allow
aliases to point at other aliases, which would mean this approach
would not work.]
The "guess" is possible in this case because of the DN prefix being
different.

But if I were to alter the search and look for "sn=Goodman", when it
was the project manager alias I wanted to alter (but was not sure of
the DN), the guess would not be possible because the DN prefixes are
the same.

Has anybody else come across this problem?

I think what is needed is an indication in the X.500 search result of which
alias has been dereferenced.  Any other ideas?

Should the Barker/Kille Naming guideline document flag this as a
problem when discussing aliases?


Colin




PS Please cc: [e-mail] in any responses as he is not on the
osi-ds list.