This document describes why and how we can use X.500 ideas (and implementations) for naming in ICEBERG. And in order that you dont get put off when I say X.500, there's a section on what I mean when I say X.500. Most of the details of X.500 are unnecessary and we need to use only a subset of the features that we need.
Some examples of the scenarios we want to support in ICEBERG are listed in this document.
As was borne out by the the scenario descriptions, we need the following two distributed naming services.
Note that the second service is not a strict requirement. We dont necessarily need to have a service that does name mapping. We can just have a service that returns the appropriate preference registry server given a unique-id. And we can then contact the preference registry server to get the preferred end-point and the associated IAP. But even if we do so, we still need a distributed service that is indexed on the unique-id.
What do I mean when I say that a distributed service is indexed on a particular field? When I say that a particular distributed service is indexed on the unique-id, I mean that the server corresponding to an entity can be reached given the unique-id. As an analogy, the DNS distributed service is indexed on domain names. Reverse DNS mappings are indexed on IP addresses. (It is possible to have forward and reverse mappings in DNS in the same service since both the name spaces - domain names and IP-addresses - follow the same hierarchy).
For the reverse name mapping service, we need to have a mapping service for each name space: one for pager numbers, one for email addresses, one for telephone numbers and so on.
Essentially, we have multiple name spaces: a name space for the unique-id of entities and a name space for each network (pager, e-mail, telephone, ...). It would be nice if we have a single distributed service that can be indexed on any of these name spaces. That's the requirement.
Choice of name space for unique-id
It would be nice if we had the unique-id follow a structure similar to e-mail ids. This has some shortcomings. For example, it ties the identity to an organization (e.g. bhaskar@cs.berkeley.edu ties me to Berkeley). But all the same, among the name spaces that we have (e-mail addresses, pager numbers, phone numbers, IP-addresses), e-mail addresses seem to be the easiest for people to handle. From that point of view, an e-mail address like unique-id for ICEBERG entities is certainly the best choice.
The only (but effective) tricks we CS people know for scaling and distributing a service are: hierarchy and caching. So, conceptually, there's only one approach - imposing a hierarchy on the name space and distribute the servers to handle parts of the hierarchy tree. Hierarchy and caching are well used in DNS for e-mail addresses and can be mirrored in ICEBERG.
Further Choices
The problem with DNS is that is handles only a single name space - that of domain names. The DNS tree cannot have entries from other name spaces - for example country-code and area-code in telephone numbers.
Hence we need a way of accomodating other name spaces as well in the same tree. One naive way of doing this would be to have a DNS entry 9076.642.510.1 for the telephone number +1-510-642-9076. But this does not quite work - we'd have problems if we have a pager number 1-245-675 which has to be mapped onto the DNS entry 675.245.1.
This problem has an easy fix - just tag entries with an identification of the network. Thus, the telephone number +1-510-642-9076 becomes 9076.642.510.1.tel in the DNS world and the pager number 1-245-675 becomes 675.245.1.pager as a DNS entry.
The above solution would actually work. So, why X.500 directories? Read on..
One other way to avoid name space clashes (other than tagging them at the end with tel or pager) is to tag all levels of hierarchy in the hierarchical division of the name space. For instance, the email address bhaskar@cs.berkeley.edu becomes (level1 = edu, level2 = berkeley, level3 = cs, user = bhaskar) and the telephone number +1-510-642-9076 becomes (country-code = 1, area-code = 510, exchange-code = 642, number = 9076).
Now, if you had looked at X.500 names before, the tagging of the fields above would look familar. They are X.500 names - but not with any of the predefined X.500 schemas - but with a directory schema that can be easily defined. Now, I'll argue why this "tagging all fields" may be a better choice than the "tagging at the end" approach.
Finally, so that you are not intimidated by a telecomm spec, I need to say what features of X.500 we are using and more importantly what we are not.
Features of X.500 that we use
Features of X.500 that we DONT use