Flat Bushy Trees - or are they really?

[Ed Reed <ED#032#REED@novell.com>]

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