Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!ucivax!gateway From: PWW@bnr.ca (Peter Whittaker (P.W.) ) Newsgroups: comp.protocols.iso.x400 Subject: Re: X.500 name-space question Message-ID: <91Jan12.014532est.58169@ugw.utcs.utoronto.ca> Date: 12 Jan 91 09:59:54 GMT Lines: 72 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: na-mhsnews-request@ICS.UCI.EDU ReSent-From: Jerry Sweet ReSent-To: mhsnews@ICS.UCI.EDU 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. Since replication requires bilateral agreements to begin with, the negotiation required to establish said agreements could include these 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 IETF OSI-DS WG is also looking at this issue in more detail. There is a paper on user friendly naming (ufn.txt, ufn.ps) available in the osi-ds directory of the cs.ucl.ac.uk server. In this paper, the onus of user- friendliness lies with the DUAs. Each DUA is given sufficient intelligent to guide a user through a search for a purported name. The naming context at which a search begins depends on the amount of information supplied by the user. For instance, if I supply J. Smith, my DUA starts looking in my department. If I supply J. Smith, Finance, my DUA assumes that Finance is a dept. within BNR. If I supply J. Smith, DEC, my DUA looks first for a dept. named DEC, next for a corporation named DEC (if it was not yet resolved, it would look for a country named DEC). The DUA returns to the user with a query as to whether the supplied names are the correct ones. The user chooses from among the responses until they have a definite, correct name. Next time they need to address that person, they can use the DN supplied in the first search. Note that it would be up to the X.400 UA (or application on top of the UA) to take care of personal mailing list, i.e. when my UFN search for J. Smith returns the name I want, the mail application writes J. Smith and the DN into a personal mailing list so that I can address mail to J. Smith in the future, and be guaranteed to get the right person. The conclusion to draw is that DUA applications and DIT structure should evolve in parallel. I think that eventual useful DITs are going to have a lot of alias entries, while DUAs are going to require AI engines (:->) sort out searches. Where the issue of performance is concerned, the IETF OSI-DS WG concluded that replication of upper level data (the top 2-4 levels of the DIT) should be as wide as possible, in order to narrow searches down to right organizations/corporations as quickly as possible. This could include wide replication of the alias-packs maintained by various organizations. There is a related concern, however, with a potentially large impact on friendly searches: in order for a friendly search to work, the DUA must provide the user with enough information to make quality guesses as to which provided name is the desired target name, but some organizations will not permit limitless searches of their DITs (to prevent dumping and raiding - i.e. by corporate head hunters). This may force users to provide more detailed information than they might otherwise have (though a tighter search would increase performance considerably, esp. across a network). Finally, DIT organization and searchability may reveal more about a corporate structure than a corporation might want revealed. Corporations might solve this problem by providing one public access point to their internal DIT, perhaps even using internal proprietary DSA operations to focus searches in such a way that corporate structure is not revealed. Anyway, my $0.02 worth (note to CDN gov't: is there GST on that?). Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7