hans@ditmela.oz (Hans Eriksson) (09/14/89)
A question concerning Directories (IS 9594, X.500): I am almost convinced that you may create an alias which points to a non-existing entry. But my fellow implementors are not, so I post the question here. As I see it, an alias which points to nowhere, just generates a NameError with aliasProblem. Maintanence of aliases is a matter outside the standards. Could I have some educated confirmations, please? /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)
alg@bcr.cc.bellcore.com (Al Grimstad) (09/14/89)
In article <7055@ditmela.oz> hans@ditmela.oz (Hans Eriksson) writes: > A question concerning Directories (IS 9594, X.500): > > I am almost convinced that you may create an alias which points to a > non-existing entry. But my fellow implementors are not, so I post the > question here. > > As I see it, an alias which points to nowhere, just generates a > NameError with aliasProblem. Maintanence of aliases is a matter > outside the standards. > > /hans You are correct (as of the December 1988 "UNOFFICIAL 'final' version"). Refer your fellow implementors to X.511 (ISO 9594-3) clause 11.1.2.2 : "... Where the entry being created is an alias, no check is made to ensure that the aliasedObjectName attribute points to a valid entry." It is the user's responsibility to manage aliases properly. The Directory will only detect and report invalid aliases when it encounters them in the course of its operation, it won't prevent them. Al Grimstad alg@bcr.cc.bellcore.com
tebbutt@RHINO.NCSL.NIST.GOV (John Tebbutt) (09/14/89)
Hans,
You are absolutely correct. Section 11.1.2.2 of ISO IS 9594/3 (actually
the unofficial CCITT X.511) states, with regard to the Add Entry
Operation :
"Where the entry being created is an alias, no check is made to ensure
that the aliasedObjectName attribute points to a valid entry."
In Section 11.2 of 9594/3 (Remove Entry), no mention is made of any
course of action to be taken with regard to alias entries pointing to
an object which is to be removed. There is an obvious implication here
that the Directory leaves such aliases in place unless directed to do
otherwise by the user. Thus, such aliases would remain in place, and
they would point to a non-existent entry.
In addition, as you rightly point out, the Standard makes provision for
the case where an alias points to no object. Section 12.5.2.1 b) of
9594/3, states that in the case where an alias has been dereferenced
which names no object, a Name Error with value aliasProblem should be
returned.
All the best,
-----------------------------------------------------------------------
John Tebbutt tebbutt@rhino.ncsl.nist.gov
U.S. Department of Commerce
National Institute of Standards and Technology
NIST Phase II Directory Prototype Implementationcolella@EMU.NCSL.NIST.GOV (Richard Colella) (09/15/89)
Hans, > > A question concerning Directories (IS 9594, X.500): > > I am almost convinced that you may create an alias which points to a > non-existing entry. But my fellow implementors are not, so I post the > question here. Yes, you can create an alias that points to a non-existent entry. The decision to let this happen was made a couple of years ago. The standards folks decided that the tradeoff between the complexity and cost of guaranteeing aliases appeared to outweigh the necessity of having this feature. > > As I see it, an alias which points to nowhere, just generates a > NameError with aliasProblem. Yes--X.511/ISO 9594-3, Clause 18.4.6, Item 12.5.2.1. > Regards, Richard
exner@rhea.trl.oz (Rolf Exner - css) (10/02/89)
(My mail access has been down for a while) From article <8909142001.AA29457@emu.ncsl.nist.gov>, by colella@EMU.NCSL.NIST.GOV (Richard Colella): > > Yes, you can create an alias that points to a non-existent entry. > The decision to let this happen was made a couple of years ago. > The standards folks decided that the tradeoff between the complexity > and cost of guaranteeing aliases appeared to outweigh the necessity > of having this feature. 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) 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. Rolf Exner Telecom Australia Research Laboratories.
hans@ditmela.oz (Hans Eriksson) (10/02/89)
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)
huitema@JERRY.INRIA.FR (10/02/89)
There is much more to say about aliases than just the consistency problem. One worst point is that, after some decision of ``unification'', aliases are treated ``almost as'' normal entries. There is not much syntactical difference between the ``aliased object'' attribute and e.g. ``see also''; the only thing is that one expect the DSA to follow alias paths during name resolution and (some) searches. But it seems to be possible to construct an object like: Name=some useful name Class= my-private-alias-extension, alias Aliased-object= the real name of the beast Telephone-number= the pink (or blue?) page values, different from aliased object. This may lead to interesting results, e.g. a search on: telephone number (base object) = pink value? yelding different results if aliasing is enforced or not... Christian Huitema
colella@EMU.NCSL.NIST.GOV (Richard Colella) (10/02/89)
> > 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