Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!jarthur!ucivax!gateway From: atkins@hpindda.cup.hp.COM (Brian Atkins) Newsgroups: comp.protocols.iso.x400 Subject: Re: X.500 name-space question Message-ID: <47920019@hpindda.cup.hp.com> Date: 17 Jan 91 01:54:01 GMT References: <1991Jan6.125643.39433@camb.com> Organization: HP Information Networks, Cupertino, CA Lines: 29 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: comp-protocols-iso-x400@rutgers.edu ReSent-From: Jerry Sweet ReSent-To: mhsnews@ICS.UCI.EDU / hpindda:comp.protocols.iso.x400 / PWW@bnr.ca (Peter Whittaker (P.W.) ) / 1:59 am Jan 12, 1991 / >Brian, Stef: >I think Brian hit upon the right idea: each corporation could maintain >alias lists of its organization, and make these available through replication >to all sites normally permitted to search/read their DIT. There would be no need to keep "alias lists" as far as I can tell. The alias tree would be rooted in a place where searches would logically begin. W.r.t the previous example, /C=FR/O=HP might be an alias to /C=US/O=HP/L=FR. I'm not following you w.r.t. "alias packs". >This allows corporations to "appear" at the root level (providing we allow >non-country objects to hang off root) while actually residing at more >adminitrable lower levels, but it does raise the problem of guaranteeing >alias DN uniqueness. This could be solved by limiting the alias data to >intra-corporate DSAs (i.e. an IBM employee seems IBM at root, while we see >them where they belong :->). The intent was not to allow corporations to appear at the root level, but rather to show how a faster-than-search access could be set up using an alias tree to impose an alternate structural breakdown of information (ie. alternate from the actual corporate structure, or whatever structure is used to form the real subtree). Lots of great info on the IETF work, thanks. Brian