|
Yes, I see two choices.
1) Make references to fields of LDAP URL explicit (rather than making it appear that any future URL will have these fields), or
2) Generalize the fields of a reference URL that are required, and state that future URLs must accommodate these.
Jim >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 9/3/03 9:35:09 AM >>> At 02:35 PM 8/26/2003, Jim Sermersheim wrote: >All, > >Currently, [Protocol] (Section 4.1.10) says: "If an alias was >dereferenced, the <dn> part of the URL MUST be present, with the new >target object name". This assumes.... I think this is assuming that the URL is an LDAP URL. If you just s/the URL/a LDAP URL/ here, the sentence is fine. Likewise in following sentences. I think we need only specify handling of LDAP URLs. While the protocol is capable of transferring other URLs, specification of such should be left to other documents. We likely should clarify that as well. That is, in 4.1.11 and 4.5.3), Other kinds of URLs may be returned (as specified in future documents) so long as the operation could be performed using that protocol. Thoughts? Kurt >that there is a <dn> part in the >referral URL. [Protocol] says that other kinds of URLs can be returned. >There are no requirements that all types of URLs contain a place for a >DN. So, if an alias is dereferenced while resolving a name, and the >referral contains non-LDAP URLs, is the server expected to: > >a) not return those non-LDAP referrals? >b) only return non-LDAP referrals where the server knows the format, >the URL format allows a DN, and the server fills in the DN part >c) return the non-LDAP referrals as they exist in the data store (if >they exist at all), even if no knowledge of DN placement is known. > >I note that another case where the server should provide the dn part is >where a reference object has been placed and the referral attribute has >the dn part populated (and that dn is different from the dn of the >reference object). If the name being resolved is subordinate to that >reference object, the dn of the referral(s) should refle! ct the D N held >in the referral attribute plus the unresolved portion of the original dn >on the operation. |