Subject: [ldapext] RFC3296 review

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 03 Oct 2003 17:59:37 -0600

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 04 Oct 2003 08:33:56 -0700

>I know that one or more of these prevent at least one vendor from

Most of these topics were discussed on the list....

>is present. If they are the same, it's easier to deal with events like

While some servers do that... others treat the URL as referring
to the root DSE.  To avoid interoperability problems, the
specification recommends the DN always be explicit.

>client (per RFC2251) MUST use the same scope.

Because, per RFC 2255, the default scope is "base".  However,
some clients regarded no explicit scope as meaning to use the
same scope (as implied by RFC 2251).  To avoid interoperability
problems, the specification mandates the scope be explicit.

>some possible problems, but it's not clear why this imperative is here.

Note that this imperative is limited to one particular case...
when the bind name is or is subordinate to a referral object.
(There may be other cases where such an imperative might be
appropriate, but that was left to LDAPBIS to address.)

This imperative is because chasing a referral to another server
cannot complete the authentication of the client to the original
server.

>object is more like a DSE with the subr *and* entry DSE Types.

Analogous is that referral objects and subr DSE provide similar function.

>I believe

We'll see (at implementation report time, I guess).

>Future applications will wish to make use of this field. 

Because it would be confusing as to whether the extension applied
to how the server processed the URL or whether the extension
was to be returned to the client for it to process.  If some
future application developer fully understands the implications
of using LDAP URL extensions referrals, they can make use of them.

>validation of the ref URI?

Because the server cannot assume that it has the ability
to verify the integrity of the URL.   If the server developer
fully understands the implications of verify URIs, they may.

>equal.  This _may_ be able to be worked around using an extensible match,

The choice of caseExactMatch was made due to labeledURI use of it.
As far as doing matching differently, it would be hell.

>in a variety of ways. If this was an AUXILIARY class, this problem could

Such implementations likely should use subclasses of referral (as
they do for aliases).

>DIT Content rule that allows [anything] in the MAY list. It has nothing

We likely should add the subclassing approach when the RFC is revised.

>to a more specific URL?

As used in RFC 2251 and RFC 3396, the terms URI and URL are
interchangeable.  

>Either RFC 3296 needs to address this, or

We likely should s/URL/URI/ in RFC 2251.

>the DN being evaluated is a reference.

Yes.  We'll need to correct this when the RFC is revised.

Kurt