Subject: [ldapext] Complex knowledge information

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 20 Apr 2004 15:21:22 -0600

All,
 
RFC 3296 defines a 'ref' attribute for holding knowledge information.
The format of this is a labeledURI. Each URI holds knowledge information
about another service that can be used to progress an operation
affecting this part of the tree.
 
We are seeing needs for extra data to be associated with each remote
address (each value of the ref attribute). Examples of this include:
 
- Authentication information (instructions on how to authenticate to
the remote service)
- Authorization information (assertions regarding the authorization to
be used on the remote service)
- Cost-related information
- Schema mapping information (name mappings, syntax mappings)
- Data transformation rules (especially for URI's pointing to non-LDAP
DSAs)
- Name resolution information (i.e. entryUUID of remote object)
 
There is other information that applies to the group of URIs in a
referral, but that's a different thread.
 
The question is twofold: 
1) What is the preferred way to represent this type of auxiliary
knowledge information in the directory?
2) What is the preferred way to represent this type of auxiliary
knowledge information in operations returning a referral (or
searchResultReference)?
 
When using LDAP URLs, one could answer both questions by stating that
the extension part of the URL should hold all auxiliary data associated
with a remote service. This gets uglier as the amount and complexity of
auxiliary data increases. 
 
Other suggestions have been:
 
- Same as above but use pointers to other information when the data
becomes too complex or needs to be constrained or validated. Take the
example of schema name mapping, there may be many hundreds of name
relationships involved. Furthermore, this information may be the same
for every local URI which points to server X. Instead of placing all
that information on each URI which points to server X, one would place a
DN which points to some 'remoteServiceSchemaNameMapping' object.
Consumers of any referrals generated by the references holding these
URLs would have to read the pointed-to object(s) if they wanted to use
that information.
 
- Store the data in a subtree of entries (or perhaps subentries), and
make the data available via response controls when returning referrals.
This solution decouples the relationship between the ref attribute and
the referral URI we have had to date. This doesn't require multiple
reads in cases where the client wants to get at the auxiliary data. This
also doesn't rely on the extensions part of the LDAP URL (relying on the
LDAP URL extensions means a similar mechanism must be defined for future
URI types). The drawback to this is the fact that there would be some
amount of data duplication in terms of the knowledge information unless
the ref attribute is simply not used.
 
Any other ideas?
 
Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 Apr 2004 23:17:17 +0200

Jim Sermersheim writes:
> address (each value of the ref attribute). (...)

> auxiliary data increases.

What is uglier about it?  If much information is needed, then it must be
sent somehow anyway.  If the point is that you don't want to repeat all
that information in many referrals, then:

For (2) you could define an unsolicited notification which provides the
extra information, and must be sent before any referral which uses it.
Unless the referral also can be followed without that information, I
think the notification should only be sent if the client has sent an
extended request which solicits it.

The extended request should have an optional field with a limit of much
such information the client is willing to cache.  The client may discard
information on a first-in-first-out basis or something when the info
sent from the server exceeds that limit.  Finally, you probably need an
LDAPURL extension or something which refers to this information (but see
below).

> (relying on the LDAP URL extensions means a similar mechanism must be
> defined for future URI types).

Or the syntaxes of referral and continuation references in the protocol
could be extended to e.g. 'URI [SPACE <extra information>]', if the
client has sent an extended request which solicits this.

Similarly, maybe the 'ref' attribute could be extended to use the label
part of 'labeledURI'.  That would probably refer to something local to
the server, though, so I'm not sure if it would be practical to make the
label part of the referral protocol field identical to the label part of
the 'ref' attribute.

-- 
Hallvard

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext