Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!EMU.NCSL.NIST.GOV!colella
From: colella@EMU.NCSL.NIST.GOV (Richard Colella)
Newsgroups: comp.protocols.iso
Subject: Re:  X500: Does alias have to point to an existing entry?
Message-ID: <8910021405.AA14035@emu.ncsl.nist.gov>
Date: 2 Oct 89 14:05:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: National Institute of Standards and Technology (NIST)
Lines: 31

> > 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...

I would argue that not only does this use 'local administrative
policy' as a (weak) excuse, but this approach violates the standard
as stated in 11.1.2.2.  There is no reason that I should be specifically
disallowed from creating the alias entry before the aliased entry.
If this is something that needs 'fixing', it should be fixed in the
standard, as Rolf suggests may happen.  However, repair by 'creative
interpretation' will lead to problems (e.g., an inconsistent service
as viewed by the user depending on the access point and the location of
the alias and aliased entries).  I believe the 1988 version is explicit
on this point and, while I don't feel that strongly on the issue of
dangling aliases, I do feel that a more conservative interpretation
of the standard will serve us all better in the long run.

> ...Is alias quiestions like this covered in the NIST functional standard
> yet? It seems it needs to be covered.
> 
> /hans

The OIW Stable Agreements defer to the standard on this point.

Regards,
Richard