|
>>> "Kurt D. Zeilenga" Kurt@OpenLDAP.org> 10/4/03 9:33:56 AM >>
>>Problems: >>P1: The Referral object class is STRUCTURAL. This prohibits various >>implementations from implementing the RFC. The DIT Structure Rule and >>Name Form for this object class needs to allow it to be placed and named >>in a variety of ways. If this was an AUXILIARY class, this problem could >>be avoided. > >Such implementations likely should use subclasses of referral (as >they do for aliases). As we all know this underspecification of aliases has been problematic. I assume one reason that RFC3296 was published was to promote interoperability of the management of subordinate references. If one DSA allows "referral" and "extensableObject" to build a subordinate reference, and another requires some number of subclasses (domainContainerSubRef, organizationSubRef, localitySubRef, and on and on ad nauseum), it is an imedement to interoperability. If there is a better solution, the better solution should be preferred.
>>P2: Referral suggests using "extensibleObject" object class to allow >>any naming. This doesn't work for some implementations that use name >>forms. the extensibleObject object class is more analogous to having a >>DIT Content rule that allows [anything] in the MAY list. It has nothing >>to do with naming. > >We likely should add the subclassing approach when the RFC is revised. I would prefer a non-subclassing solution. I'd rather not see one referral-type subclass for every naming and containment scenario. One idea is to allow an aux class to mark an entry as a reference, another idea is to use a DSEType attribute, a third idea is to invent an <any> name form and <any> dit structure rule.
>>P3: The ref attribute is supposed to hold a URI, and the RFC goes as >>far as to say "If the URI component is not a LDAP URL, it should be >>returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a >>referral holds one or more URLs. How can a more generic URI be converted >>to a more specific URL? > >As used in RFC 2251 and RFC 3396, the terms URI and URL are >interchangeable. It is not clear in my mind why you say this. I'll have to do some more reading I guess.
>>Either RFC 3296 needs to address this, or >>draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in >>referral values. > >We likely should s/URL/URI/ in RFC 2251. Probably. I'll raise in ldapbis.
>>P4: In various places, the semantics of the ManageDsaIT control are >>wrong. It states things like "When the control is present in the >>request, the server SHALL NOT generate a referral or continuation >>reference based upon information held in referral objects and instead >>SHALL treat the referral object as a normal entry". AFAIK, during name >>resolution, the manageDsaIT control is applied only when the last RDN of >>the DN being evaluated is a reference. > >Yes. We'll need to correct this when the RFC is revised. > >Kurt Regarding the answers to the other questions/issues, they all seam reasonable, but I wish most of the explanations were present in the RFC. Also, I think the issues #2 and 3 (SHOULD NOT have LDAP URL extensions, and SHOULD NOT validate referential integrity) should be prefixed with like "in absense of further specification...". This would clarify the intent.
Thanks for the quick response. Jim |