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