Re: [ldapext] Complex knowledge information

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> 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). (...)

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

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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext