|
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
|