interoperability concerns: namespace

[John McGarvey <mcgarvey@us.ibm.com>]

Besides schema, the other interoperability concern I have is in the
organization of the namespace.  Directory vendors differ in the kind of
namespace organization they support, and customers differ in how they set
up a namespace.  LDAP applications can traverse the namespace, but it is a
complicated process often requiring a number of LDAP queries to find key
objects, and a particular namespace traversal logic may not work for all
LDAP implementations or all customer deployments. I think it is undesirable
to require this kind of logic in a DSML v2 application, which might reside,
for example, in a small pervasive device.

I suggest that we remedy this in DSML v2.  (I am sure this will be a
controversial point.)  I suggest that all DSML v2 implementations ought to
support certain external entities in the specification of DNs, which:

%this;    -- Corresponds to the DN of the authenticated identity that sent
the DSML v2 request.  This entity is useful for a user (who may not know
his DN, or may not use it to authenticate to the DSML v2 server) to
retrieve information about himself/herself; or for a device to retrieve
information about itself.  Of course, it may happen that there is no DN for
the authenticated identity, in which case "unknown object" would be
returned as an error.

%personQueryRoot;  -- the base DN where the authenticated identity (perhaps
anonymous) that sent the request may find person entries.  The person
entries may not be immediately under this base DN, but this describes the
starting point for a subtree search.

%personCreateRoot;  -- the base DN where the authenticated identity that
sent the request may create person entries.  The person entries are to be
created immediately under this base DN.

%groupOfNamesQueryRoot;  -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find or create groups. (Each
*QueryRoot is a starting point for a subtree search.)

%groupOfNamesCreateRoot;  -- the base DN where the authenticated identity
that sent the request may create groups.

%physicalDeviceQueryRoot;  -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find physical device entries.

%physicalDeviceCreateRoot;  -- the base DN where the authenticated identity
that sent the request may create physical device entries.

%logicalDeviceQueryRoot;   -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find logical device entries.

%logicalDeviceCreateRoot;   -- the base DN where the authenticated identity
that sent the request may create logical device entries.

%servicesQueryRoot;  -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find service
location/description information.

%servicesCreateRoot;  -- the base DN where the authenticated identity that
sent the request may create service location/description information.

Via the use of these external entities, we can eliminate the need for
namespace traversal logic from many and perhaps most DSML v2 applications.
The DTD would specify URIs that return values for each of these external
entities.  I believe we want to specify a closed and short list of which
external entities are to be supported, and I suggest the list specified in
this note.

-- John McGarvey