Re: [ldapext] RFC3296 review

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

At 04:59 PM 10/3/2003, Jim Sermersheim wrote:
>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.

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

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

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.

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

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.

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

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.

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

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

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

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

>I2: Why SHOULD NOT an LDAP URL in the ref attribute contain extensions?
>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.

>I3: Why is there an imperative restricting referential integrity
>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.

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

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

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

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

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

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

>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 


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