Multiple Service Providers and Distributed Entries

[Sze-Ying Wuu <[e-mail]>]

It's good that the problems of the multiple provider and linking
needs of distributed entries will be discussed at the IETF meeting.

We have a different solution than what NADF proposed for the problems of 
multiple providers and distributed entries. We use the concept of a 
"linking directory" to cross-reference distributed entries of the same
real-world object. 

The problems and needs we see are:
1. There are many different contexts in which information is maintained
   about an object. Examples of contexts for people are business, residential,
   and different communication media. 

2. There are many different ways of naming or addressing an object. 
   An object is known to users by the names and attributes
   of some but not all contexts or provider's directories.
   The name and known attributes in one context is not enough to
   uniquely identify the same object in another context. 

   For example, although I know John Doe's business address and phone number, 
   I may have a hard time to find John Doe's personal email address
   if I don't know his email provider or his DN in the email context. 

3. It is unreasonable to have a single directory entry that contains all
   information of an object. 
   -- providers want to retain ownership and privacy of information
   -- management overhead of replicating information from all sources and
      making the information consistent with the sources.

4. As Paul-Andre has pointed out, references distributed entries at the 
   entry level is not efficient to search the referenced entries for
   some specific information of an object. 

5. It is difficult for every user to make queries to directory only
   by some defined set of names. This problem is worse if this
   well-defined names can be changed during the lifetime of the objects.


The NADF solution has the problems of (4) and (5).

The "linking directory" solution we propose solves the above-mentioned
problems.

A linking directory contains an entry for each real-world object that
have entries to be cross-referenced.  A linking directory entry
of an object contains "linking references" to the distributed entries.
A linking reference contains the context type and the DN of the
object entry or the directory entry that has further information
of the object entry of interest. The linking entry of an object is identified
by a lifetime, immutable, globally unique linking identifier of the 
object. The linking identifier is also included in the distributed entries of 
the object as backward references to the linking directory entry. This 
identifier can be some opaque string because it is not expected that a normal 
user to use the identifier for queries. 

The context type that is used in the linking directory can be viewed
as a way to group related attributes so as to reduce the number 
of references pointers to be maintained in the linking directory.

A linking reference can point directly to a object directory entry.
However, there are several advantages that it does not:
-- reduce management overhead: local changes are not propagated
   to the linking directory. e.g., the linking reference points to
   the root of the provider's domain of an entry, then local changes of 
   a provider's domain that change the DN of the entry does not affect 
   the linking reference. 
-- hide the internal organization of a domain from the linking directory
-- can point to directory entry that may not have the information
   locally but has other means to get the information. 

A typical use of the linking directory is:
A user sends known attribute information of an object and requests for
some other attribute information of the same object. The user needs
not be aware that the information of the object is distributed.
The input attributes are used to query one or more directory entries
for the linking identifier of the object. The linking id is used
to identify the linking entry of the object. The contexts of interest are
then determined based on the requested attributes. The corresponding
linking references of the contexts are used to query the 
directory entries that potentially have the requested information.

Gita Gopal presented the concept at the November '90 IETF in
Boulder, CO.

A more detailed descriptions of the concept is available in 
the conference paper that I presented at IFIP-UPLAA last year:

Gita Gopal and Sze-Ying Wuu, "A Directory Model to Support
Cross-Context Naming and Addressing," IFIP-UPLAA Proceedings,
May 1992, Vancouver, B.C.

The paper also describes one implementation of the linking directory
prototype. Since the writing of the paper, we have other
implementations of the concept to experiment with different
architectures and study other issues. Making the linking directory
useful in the directory infrastructure without requiring mandatory
changes to the X.500 standard has always been one of our goals in
our realizations of the concept.


Both Gita and I won't be at the IETF meeting next week. If anyone
is interested, Abel Weinrib, my colleague, who cochairs the "mmusic" 
working group meeting have copies of the paper I mentioned above.

Regards,
Sze-Ying Wuu