RE: interoperability concerns: namespace

[Tony Gullotta <TGullotta@access360.com>]

Along these same lines, I have a concern about how DN's are delimited.
We've seen how different directory servers can use different delimiters.
Is there at least one common one that all will support, or that DSML can
define as common that the directories will have to map in their gateway?

Tony

-----Original Message-----
From: John McGarvey [mailto:mcgarvey@us.ibm.com]
Sent: Tuesday, July 31, 2001 10:14 PM
To: dsml@lists.oasis-open.org
Subject: interoperability concerns: namespace


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


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: dsml-request@lists.oasis-open.org