|
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 4/21/04 3:17:17 PM >>>
>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: Well, I'm sure we all agree that sending an entire entry packed into a single attribute value would be ugly, sending all the data normally held in a subtree of entries in this way is even uglier. Even today's representation of schema elements is ugly ? they would be much more manageable if they were each objects, where things like MUST and MAY were attributes. This is basically what I'm talking about.
>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. Heh, a solicited unsolicited notification. This solution seems to require message synchronization. I think (if we can't place all the data on each ref attribute) it would be preferable to just put it in a response control on the message containing the referral (or searchResultReference).
>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. I'm thinking that might cause some unwanted effects on existing clients which only expect a valid URI. If this route was taken, the extra information would have to be solicited via a control (and the control specification would be the document that defines the referral syntax extension).
>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. Yeah, this would have to be coupled with the solution above right? What do you mean when you say it would refer to something local to the server? It could potentially contain anything, right (a reference to something, raw data, a mathematical formula, a SAML assertion, etc).
Thanks for the feedback so far. Do you think it would help if I illustrated some extreme examples of storing stuff on values of the ref attribute, and contrast that with returning that same kind of stuff in a control, and further contrast those with returning small (reference data) which would force the client to make a subsequent read? Jim
|