[ldapext] RFC3296 review

["Jim Sermersheim" <jimse@novell.com>]

All,

I have been reviewing RFC3296. I did not review it in earnest (if at
all) during its last call, so, well, there's my excuse--you don't need
to slam me, I've just slammed myself...

I'm splitting my questions/comments into three parts. First are some
general questions which I'm simply curious about (most of the "why does
it say that" nature). Second are issues that I see being obstructions to
future specifications (like chaining). Third (and I wish it were not so)
some problems that I consider being impediments to implementing the RFC.
I know that one or more of these prevent at least one vendor from
implementing the RFC.

Questions:
Q1: Why is it that LDAP URL values in the ref attribute SHOULD contain
a non-empty DN? I imagine that many Referral objects will have the same
name as the object they point at in the remote DSA. It seems better to
state that when the DN of the remote object differs, that the DN field
is present. If they are the same, it's easier to deal with events like
moves and renames.

Q2: In Section 5.3, Cases 2 and 4: Why MUST the server return an
explicit scope when returning a referral (not search result reference)?
It will always be the same as the original--thus not needed as the
client (per RFC2251) MUST use the same scope.

Q3: Why is there a SHOULD NOT return referral for bind? I can think of
some possible problems, but it's not clear why this imperative is here.

Issues:
I1: Section 2.1 says: "Referral objects are analogous to X.500
subordinate knowledge (subr) DSEs [X.501].". But in fact a Referral
object is more like a DSE with the subr *and* entry DSE Types. I believe
there are many (most) cases where a subr DSE in and X.500 deployment are
*not* entry's. This inconsistency with X.501 makes me worry that X.500
servers with LDAP front-ends will have a hard time implementing this
RFC.

I2: Why SHOULD NOT an LDAP URL in the ref attribute contain extensions?
Future applications will wish to make use of this field. 

I3: Why is there an imperative restricting referential integrity
validation of the ref URI?

I4: The ref attribute has an EQUALITY of caseExactMatch. This will
prohibit applications in the future from using it. Future applications
will want to treat the "ldap://example.org"; and "ldap://192.0.34.166"; as
equal. This _may_ be able to be worked around using an extensible match,
not sure...

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.

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.

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? Either RFC 3296 needs to address this, or
draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in
referral values.

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. Otherwise, how does one manage a
Referral object that is subordinate to another Referral objet (in the
DIT)?


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