The Preference Registry

This document descibes the implementation and intended use of the Iceberg preference registry.

The preference registry is a repository of user preference profiles. The preferences refer to management of incoming communication. The profile serves to redirect or filter incoming communication based on several input parameters.

General description

The inputs to the preference registry (i.e., the members of the pref_req structure) are:

• callee_uniqid -- the callee's unique id in LDAP DN format
• caller_id -- the caller's service-specific-id in LDAP DN format
• caller_uniqid -- the caller's unique id in LDAP DN format
• caller_type -- the caller's end-point format type (the same as the one given in the EndPointInfo by the caller -- see the IAP documentation for more information on this).
• call_state -- this refers to the state in which the callee's device was found in a previous recent call. This field is intended for the following scenario: the caller is redirected by the preference registry initially to a device that is found to be busy. The caller end would query the preference registry again with "call_state" set to "BUSY". The caller could be redirected to a second device of the callee now. The call_state can take one of four values: "IDLE", "BUSY", "RINGING", and "UNREACHABLE".
• called_number -- this is for the same scenario as the previous case (call_state) -- it gives the number that was called the previous time.

The output from the preference registry (pref_rep) has the following fields:

• succ -- indicates success of lookup (OK/FAILED)
• iap_url -- the URL (for iSpace lookup) of the preferred end-point IAP
• callee_id -- the service-specific-id of the callee at the preferred IAP.

The preference profiles are generated by the preference manager (or some other GUI) and uploaded to the preference registry. The profiles are stored as TCL scripts (with if-then-else rules) and are interpreted to get at the preferred end-point of the user.

Currently, there are no mechanisms for the following:

• Verifying the caller-id of the caller
• Verifying that the caller has actually tried the "called_number" and that the called_number was in the mentioned "call_state"
• Hiding the service-specific-id from the calling end-point
• Checking that the TCL preference script uploaded by someone terminates (this is easy to verify though)
• Authenticating the user before accepting upload of the preference script

Structure of the preference registry

The preference registry has a front-end that provides the interface for the outside world. The front-end uses a pool of Java-based TCL interpreters (Jacl interpreters -- see the Scriptics Java page). The front-end prepares the script for the interpreters, feeds it to them, and reads two variables set by the interpreters. The front-end also exports the interface to upload scripts into the preference registry.

The back-end uses files (or Steve Gribble's DDS - Distributed Data Structures) to store and retrieve preference profiles. Since the DDS is not part of the release, the back-end uses files for preference profile storage. For each user, there is a file <uid>.tcl containing the script.

Interface with the TCL preference profiles

The interface of the preference registry front-end with the stored TCL preference profiles

The script fed to the interpreter consists of two parts. The first is a bunch of variable assignments. The second is the user's preference profile itself.

The following variables are set before the user's preference profile:

• callee_uniqid, caller_id, caller_uniqid, caller_type, called_number, call_state -- these come directly from the pref_req of the lookup request
• year, month, date, day, hour, min -- the current values (at the preference registry)

The following variables are expected to be set by the user's TCL preference profile:

• iap_url, callee_id -- these go directly to the reply structure in the response to the lookup request

Interface to load scripts

The ScriptLoaderIF has a single routine "load(String dnStr, String script)" to upload scripts. The first argument "dnStr" gives the user's Iceberg unique-id in LDAP DN format. The second argument gives the TCL script itself.

The files

• front_end.java -- the main file with the relevant interfaces
• back_end.jc -- the backend for storage
• pref_reg_if.java, pref_req.java, pref_rep.java -- the interface file, the request and reply structures respectively
• interpPool.java -- manages a pool of Jacl interpreters
• ScriptLoaderIF.java -- interface to upload user preference profiles
• ScriptLoaderClient.java -- client program to upload preference profiles
• BadDNException.java, InternalException.java -- exceptions to throw in different interfaces

Running the preference registry and the script loader

pref_reg.front_end use-files <pref-dir>

The first argument is just the string "use-files" indicating that the back-end of the preference registry should use files for storage. The second argument gives the directory in which the preference files are to be stored ot retrieved from.

The usage for the ScriptLoaderClient program is:

pref_reg.ScriptLoaderClient <pref-server> <email-id> <pref-file>
OR
pref_reg.ScriptLoaderClient <pref-server> <num_email_ids> <pref-file>

In the first case, the given script is uploaded for the user identified by the given email-id (Iceberg unique-id). In the second case, the same script is uploaded for several dummy users: bi@domain for 0<i<num_email_ids. The second usage is for loading the preference registry with lot of dummy scripts to stress test it. In either case, if the pref-file is given as "-", STDIN is read instead of a file.