Ed, I'm not sure what your end point is from the message. The one thing that that I would caution you is that you are making an assumption that everyone has an email address. This simply is not the case in most companies today or in the foreseeable future. Of course, you are ignoring a lot of other issues, such as directory stability. Every time someone changes their name, or wants an additional nickname, your tree requires maintenance. What happens when someone's certificate requires reissuing due to the move of it within your structure. This has both operational cost and perhaps external costs since you may be paying a certificate authority to issue the certificates. Wouldn't it be nice if the DN was just a pointer to your data and never changed. I think that is what many people are finding to be important as they start to roll out large directories. You can build logical views of the directory data using attributes and search filters intelligently. I first did this successfully in 1993 on a very large directory. Certain users thought the tree looked organizational, others thought it looked geographical, others thought it was a hybrid of the two, and very few knew that it was actually flat. This really saved the project from large operational costs - it had to run almost unattended, including updates. -- Alexis As of June 25, 1998: Alexis Bor Directory Works, Inc. P.O. Box 470276 Celebration, FL 34747-0276 407-566-9250 407-566-9251 (FAX) alexis.bor@directoryworks.com http://www.directoryworks.com > -----Original Message----- > From: Ed Reed [mailto:ED#032#REED@novell.com] > Sent: Friday, August 07, 1998 5:04 PM > To: ldup-repl@external.cisco.com; IETF-LSD@LISTSERV.UMU.SE; > ietf-ldapext@netscape.com; merrells@netscape.com; Ed Reed; > ietf-asid@umich.edu; usriniva@us.oracle.COM > Cc: Bob Jueneman; CCASTLETON.PRV-7.PROVO@novell.com; Dale Olds; Gary > Hein; Jd Marymee; Kent Prows; Michelle Respess; Roger Schell; Steve > Carter > Subject: Flat Bushy Trees - or are they really? > > > I've been thinking about scaleability and bushy trees, and > happened to look over at my inbox in Groupwise. > > People spend loads of time talking about how flat namespaces > are sooooo much better than structured > namespaces, so that things like email addresses are stable, > easy to perform email lookups, etc. > > But are they, really? Flat, I mean. > > The most common email address convention I've seen is one > that MDF mail systems made popular... > > Ed.Reed@novell.com > > where a period separates the first and last names. Instead > of a space, or an underscore. > > Okay, think about it, now... > > What we've wanted are secondary indexes that allow users to > experience a flat namespace, with > guarantees of uniqueness across the whole organization, while > allowing administrators the > freedom and flexibility to move user objects into > organizational and geographical containers > that make management and policy enforcement easier. > > So - here's my first point - the "flat namespace for email > addresses" isn't flat at all...it can be > easily broken into separate containers identified by the last > names (for western european > derived cultures, perhaps by personal names for eastern > culture names), and further > identified by the first names, subordinate to the last name > (family name, subordinate to > personal names for eastern cultures), etc. > > The point being, that the hierarchy looks like > > dc=novell.com, ou=Reed, cn=Ed being an alias pointing where > ever my real object is. > > SMTP name resolution is simple - the administrative area, > designated by the contents > of the MX record from DNS (novell.com, in my case) tells the > email forwarder where > to look for my name, at dc=novell.com, or dc=com, dc=novell > depending on your > preferences...and from there, a relative name lookup/LDAP > search for cn=Ed > in the context ou=Reed (maybe ou isn't the best choice for > this type of container, but > let's keep the conversation going), which isn't likely to > carry a large number of entries, > at all. Even large organizations are likely to have only a > few hundred Smith's. > > So, maybe everyone else already had this figured out. Maybe not. > > But the point is that names for users certainly don't have to > be RFC822 strings in > a flat name space. Rather, a simple, straight forward > mapping that supports common > conventions today is easily constructed, doesn't require huge > database engines > on the back end to support them, and lends themselves to more > natural organization > for administrative purposes. > > Expect a draft RFC describing this approach in more detail > after the Chicago IETF. > > Ed > > ------------------- > Ed Reed, Technologist > Novell, Inc. > +1 801 861 3320 >
Attachment:
Alexis Bor (E-mail).vcf
Description: Binary data