[ldapext] RE: Complex knowledge information

["Howard Chu" <hyc@highlandsun.com>]

> From: "Jim Sermersheim" <jimse@novell.com>

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

I think the answers depend a great deal on the actual usage scenarios. In
particular, it depends on whether the first server's referral points to
another trusted/local server, or if it points to a foreign/unknown server. I
suppose if you know enough about the remote server to have schema mapping,
data transformation, and name resolution information, then you probably know
a fair amount of other things about it too.

In the case of trusted/cooperating servers, my preference is for the server
to maintain all of this information internally, chain the queries, and return
the mapped results to the client transparently. In this case,
authentication/authorization is also handled by the chaining server.

In the case of a foreign/untrusted server, generally it would be
inappropriate for the local server to automatically tell the client anything
about how to authenticate/authorize.

Probably not a very useful reply, but that's how I see things at the moment.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext