Re: [ldapext] RFC3296 review

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:45 PM 10/3/2003, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <mailto:Kurt@OpenLDAP.org> 10/4/03 9:33:56 AM >>>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.

Note that some prefer to use cnAliasObject, uidAliasObject, etc.,
then to use SUPs, others prefer an AUX cnObject, uidObject, etc..
Others avoid multiple classes by having one class which list all
the allowed naming attributes.  Others use DIT content rules.

Sure, it is hard for a client to know which to use.  Anyways, as
this issue:
        How do clients determine how to augment objectclass attribute
        to allow the naming attribute(s) to be present?

exists for alias objects and that specification is currently being
revised, I suggest we take this issue to LDAPBIS.

I note, at least, where one uses subclasses... the client can see
determine which subclasses are available in the subschema.  Likewise
for DIT content rules.

>If there is a better solution, the better solution should  be preferred.

I think there is significant contention as to what's best here.
Personally, I think the server should describe in its subschema
which naming attributes are allowed to be present in which
referral and alias objects (just as they do for other objects).
The server should be allowed to use any schema mechanism available
to it.

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

I rather not re-invent referral objects (or invent new schema mechanisms).

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

Because to the protocol, it is irrelevant as to whether a particular
URI was classified as a URL or not.  What matters is whether or not
the URI can be used to complete the operation.

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

Some elaboration may be appropriate...

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

No, that wasn't the intent.

The intent was to say that implementors should not do X unless they
fully understand the implications of doing X.   That is, (as I attempted
to clarify) the SHOULD NOT, like any other SHOULD NOT, may be ignored
as discussed in RFC 2119.

I don't think we should cloud the imperatives with "further
specification" statements.

>Thanks for the quick response. 

You're welcomed.

Kurt 


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