Path: utzoo!utgpu!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!agate!bionet!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!hans
From: hans@ditmela.oz (Hans Eriksson)
Newsgroups: comp.protocols.iso
Subject: Re:  X500: Does alias have to point to an existing entry?
Message-ID: <7300@ditmela.oz>
Date: 2 Oct 89 07:20:57 GMT
References: <8909142001.AA29457@emu.ncsl.nist.gov> <742@trlluna.trl.oz>
Reply-To: hans@ditmela.oz.au (Hans Eriksson)
Organization: CSIRO/DIT, Melbourne, Australia (on leave from SICS, Sweden)
Lines: 41

In article <742@trlluna.trl.oz> exner@rhea.trl.oz (Rolf Exner - css) writes:
> (My mail access has been down for a while)
>
> Supporting guaranteed aliases is complex and operationally costly
> when the alias points to an entry in a remote DSA. (Note that
> current extensions work in CCITT/ISO on X.500 is again looking at 
> supporting such aliases as a second kind of alias)

But we are not talking about guaranteed aliases, just aliases as they
are intended and also defined in the standard.

> Yet this does not mean that aliases that point to non-existent objects
> have to be retained by a DSA. Directory management actions, outside
> the scope of the standards, may delete such dangling aliases whenever
> they are detected - e.g on receipt of an aliasProblem NameError.
> X.500 makes no guarantee that an entry created one day (and not removed
> via RemoveEntry) will be there the next.
>
> A DSA may also elect to keep its own house on order and prevent the
> creation of alias entries that it *knows* point to a non-existent 
> entry (X.511, 11.1.2.2 notwithstanding). It can do this simply by
> returing an unwillingToPerform ServiceError on the basis that it
> violates local administrative policy.

With 'local administrative policy' as an excuse you could deny
everything, but still comply. If you will remove dangling aliases when
your DSA discovers them, you remove quite a bit of functionality.
Maybe the aliased entry was just being updated by removal and add, or
renamed and a new entry placed there instead.

What's so bad with a dangling alias?
 
Is alias quiestions like this covered in the NIST functional standard
yet? It seems it needs to be covered.

/hans
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)