tinkelman@camb.COM (Bob Tinkelman) (01/07/91)
[Moderator: Please ignore this if it appears to be a duplicate. I tried to post an item earlier today, but think that it failed to get sent. Also, if there's a better place for me to post this question, please let me know.] I have a fairly naive question regarding setting up an X.500 name space. I am working with an international organization that it trying to do the ``right thing'' -- design their X.500 name space before the various parts of the organization start going their own ways with independent implementations. Their first throught was to design a name space where the branching started at the country level. That is, names would look like this: /CO=xx/O=org-name/OU=xxxx/L=xxxx/etc where the org-name was constant and the x-fields varied. However, the (small number of) examples I've seen published seem to do things differently. They start the branching under the organization name. For example, the OSF literature on their DCE (which incorporates Siemans Dir-X for X.500) shows a diagram with both the OSF's Cambridge and Munich offices under /CO=US/O=OSF/etc. So my questions are: Are both approaches feasible? If so, what are the trade-offs to consider between them? Thanks in advance for any advice or pointers to other resources. -- Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830, bob@camb.com
atkins@hpindda.cup.hp.COM (Brian Atkins) (01/10/91)
If you use the top level country name to separate branches, you're
organization will be spread across multiple subtrees. If, however,
you locate a feasible root that all parts of your organization
can live under, you can keep it all in one subtree.
Although the standard would accommodate either approach, in reality
it will probably be much to your advantage from a support and
configuration point of view to keep your org under one root.
For example, take my company, HP. Assume we have research labs in
the US, France (FR), and the UK (GB), here are the two alternatives:
Split by country:
/C=US/O=HP/OU=LABS
/C=FR/O=HP/OU=LABS
/C=GB/O=Hewlett-Packard/OU=LABS
(Note that the Orgname "HP" might not be available in all
countries, already being assigned to some other outfit)
Single root:
/C=US/O=HP/OU=HP-UK/OU=LABS
/OU=HP-FR/OU=LABS
/OU=HP-US/OU=LABS
(Or something along those lines)
The latter would keep the entire HP name space, now and into the future,
in one subtree of the name space. Note that this in no way imposes a
structure on the actual distribution of subtrees across DSAs, machines,
or countries. If fact, it makes perfect since in this case for the
naming context (subtree) holding the "French" data to be in physically
France, even though the naming prefix is /C=US/O=HP....
Help?
Brian Atkins X.500 Development Team
----------------------------------------------------------------------
Brian Atkins atkins@hpindqj.HP.COM (408) 447-2057
Hewlett Packard (43LS) 19420 Homestead Rd. Cupertino, CA 95014cjr@xtel.co.UK (Colin Robbins) (01/10/91)
>Single root: > > /C=US/O=HP/OU=HP-UK/OU=LABS > /OU=HP-FR/OU=LABS > /OU=HP-US/OU=LABS > (Or something along those lines) > >The latter would keep the entire HP name space, now and into the future, >in one subtree of the name space. Note that this in no way imposes a >structure on the actual distribution of subtrees across DSAs, machines, >or countries. If fact, it makes perfect since in this case for the >naming context (subtree) holding the "French" data to be in physically >France, even though the naming prefix is /C=US/O=HP.... If I am a user trying to find an entry for somebody I know works for HP in France, how would I know that I actually had to look under the c=US node, and not the c=FR node ? Colin
Stef@ICS.UCI.EDU (Einar Stefferud) (01/11/91)
To generalize a bit on Colin's remark: It is critical to look at the structuring problem from the point of view the lookup end of the operation, not the data loading end. I have often found companies trying to find ways to get their "root" higher in the tree, like trying to get an OID arc at the COUNTRY level (because they are MULTINATIONAL). I claim that it is a natural human phenomenon to want to be higher in trees of all kinds. (Now, if we could put the root at the bottom...) My obsevation is that few non-IBM people are going to look for an IBM Office address by first looking for IBM Worldwide. They are going to be looking for an address in some place, and not just anyplace in the whole world. Now, I expect that this has to be balanced between two main populations of users: INTERNAL who look at the directory as a CORPORATE thing, and want to find people the way Brian suggested, and PUBLIC who are on the outside looking to find an address in some specific locality. How we balance the organization of the directory information to meet the needs of both populations is a question I am not able to answer, in general or in particular for any given case. I would be interested in learning more about how to do this, and I expect that many other people would also. Cheers...\Stef
atkins@hpindqj.cup.hp.COM (Brian Atkins) (01/11/91)
Hola' Stef, Glad to see you're still keeping you hand in the standards, are you still attending the X.400 SIG? (If you remember, I represented a company called NBI there a few years back, around the same time Jody Reed and Tim Bishop were there). One thing we have looked at here at HP is using alias trees to provide multiple lookup paradigms. Continuing along my example with HP, an alias could be set up allowing references to /C=FR/O=HP to go to /C=US/O=HP-FR or /C=US/O=HP;L=FR or whatever the breakdown under HP is. Except the for alias entries themselves, the HP subtree is still consolidated under one root. Such an alias tree can even be used to provide a different lookup tree allowing faster access than search, for example by phone number. The top level node could be country code, then area code, then prefix, then extension. The leaf node would be an alias to the real entry which may have its DN constrained by something else, like the organizational structure of the entity of which it's a part. Brian ------------------------------------------------------------------ Brian Atkins atkins@hpindqj.HP.COM (408) 447-2057 Information Networks Division - 43LS Hewlett Packard 19420 Homestead Road, Cupertino, CA 95014
PWW@bnr.ca (Peter Whittaker (P.W.) ) (01/12/91)
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
atkins@hpindda.cup.hp.COM (Brian Atkins) (01/17/91)
/ 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