Subject: Re: Last call on 'Named Subordinate References in LDAP Directories'

From: [email-masked] (Mark C Smith)
Date: Mon, 07 May 2001 21:53:12 -0400

Roland Hedberg wrote:
> 
> The document in last call is:
> 
> http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-namedref-03.txt

I few last minute last call comments:

1) Section 4.1 (The referral Object Class):  I can't think of a good
reason for the 'ref' attribute type to be mandatory.  I would like to
see it changed to a MAY.

2) Section 6 (Named Subordinate References): Here and in other places in
the document it is noted that the server MAY omit the DN part of the URL
in certain circumstances.  But consider the following two LDAP URLs:

    a)  ldap://hostb/
    b)  ldap://hostb

The first one (a) is an LDAP URL that includes a zero length DN, i.e.,
it points to the root DSE or the "root of all roots" on hostb.  The
second (b) is an LDAP URL that does not include a DN.  RFC 2255 (The
LDAP URL Format) is silent on this topic but
draft-ietf-ldapbis-url-00.txt says:

    If no dn is given, the default is the zero-length DN, ""

and section 4.1.11 of RFC 2251 says:

   ... If the <dn> part is
   present, the client MUST use this name in its next request to
   progress the operation, and if it is not present the client will use
   the same name as in the original request.

This seems like a small conflict.  In my opinion, RFC 2251 "wins"
because draft-ietf-ldapbis-url-00.txt is still a draft and common usage
(in my experience) is for LDAP clients to interpret a URL like
ldap://hostb as one that does not include a DN.  So I believe that the
trailing "/" should be removed from all URLs in the Named Subordinate
References draft that include one.  But I don't see a way to omit the DN
and also include other options.  Neither 2251 nor
draft-ietf-ldapbis-url-00.txt allow you to use a URL like this:

    ldap://hostb??one

(the dn is required if anything after it is included in the URL).  If
other options are present, the server will need to include the DN in the
LDAP URL it returns to the client in the Referral protocol field.

3) Section 7.2 (Target object considerations), 2nd paragraph: The way
this is worded is a little ambiguous.  Do we mean to say that the server
SHOULD trim the scope, filter, and attribute list from the URL before
returning it?  I think the "e.g.," should be dropped.

4) Section 7.2 (Target object considerations), Case 4: I would like to
see a detailed algorithm specified that a server SHOULD use to construct
the URI value to be returned.  Why?  Because it is critical for
interoperability that all servers produce the same Referral given the
same referral objects in the DIT.  I can produce some text based on what
was in the expired Christopher Lukas Named Referral" I-D if that would
help.  This same comment applies to Case 4 of section 7.3 (Base Object
Considerations).

5) Section 7.4 (Search Continuation Considerations): I was surprised to
see that for a one-level search the server is not required to include a
scope of base in the URIs returned.  I think this can be handled
correctly by the client without the server adding a scope of base, but
it seems better to have the server do this work.  If a client implements
referral processing as described in RFC 2251 (which all should today),
the right thing will not happen unless the server includes the scope of
base in the returned URLs.

I also have several minor editorial comments (typos, etc.) that I will
send to the author tomorrow.

-Mark Smith
 Netscape Directory Product Development

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 May 2001 20:36:49 -0700

I've split my response over a few messages to aid in separating
following up discussions.

>reason for the 'ref' attribute type to be mandatory.  I would like to

It's a required attribute as returning no URLs is not allowed
per RFC 2251 and allowing no 'ref' attribute would unduly
complicate the specification and implementations.  Do you have
a more specific reason for desiring support for a referral
object with no ref attribute?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 May 2001 20:48:28 -0700

At 06:53 PM 5/7/01, Mark C Smith wrote:
>returning it?

Yes.  The wording was meant to deal with search specific
URL extensions.  However, I concur the wording is a little
ambiguous and URL extensions are address by following
sentences.  Hence, I suggest replacing the paragraph with:

  In cases where the URI to be returned is a LDAP URL, the server
  SHOULD trim any present scope, filter, or attribute list from the
  URI before returning it.  Critical extensions MUST NOT be trimmed
  or modified.  Other parts MAY be modified or trimmed.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 May 2001 21:33:40 -0700

At 06:53 PM 5/7/01, Mark C Smith wrote:
>scope of base in the URIs returned.

First, I note that:
        ldap://hostb/OU=People,O=MNN,C=WW

and
        ldap://hostb/OU=People,O=MNN,C=WW??base

are equivalent per rfc2255.  That is, a URI without an explicit
scope part has scope base.

If there is a implicit/explicit scoping issue, then it's
with scope subtree and the RFC 2251 examples.   To reconcile
RFC 2251, 4.5.3, and RFC 2255, one must assume that an
not-present scope implies the operation should be continued
with an appropriate scope implied by the originating request
or that an absent scope implies scope subtree.  Otherwise, the
RFC 2251 example (and most implementations) are broken.

Unfornately, RFC 2251 makes no one-level example.

>I think this can be handled

RFC 2251 doesn't say explicitly want to do when the scope is
absent.  So, RFC 2255 should "win".

But, as there are client implementations take different views of
what RFC 2251 examples suggests, I would suggest that namedref
require that returned continuation LDAP URLs always contain an
explicit scope.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 May 2001 21:40:50 -0700

At 06:53 PM 5/7/01, Mark C Smith wrote:
>second (b) is an LDAP URL that does not include a DN.

While I would argue a) and b) are equivalent in any particular
context (2255, referrals, references, ref value), I do agree that
RFC 2251/2255 is ambiguous.

To avoid this ambiguity, the solution is to require an explicit
DN in the returned LDAP URL (and to view an absent or empty
DN part in a ref attribute as implying the DN of the referral
object).

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 07 May 2001 22:52:26 -0700

At 06:53 PM 5/7/01, Mark C Smith wrote:
>the URI value to be returned.  Why?

I guess some additional text regarding DN rewriting considerations
would be appropriate.  I would suggest an additional "Other
Considerations" subsection be added.

>I can produce some text based on what

Suggested text always welcomed.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Tue, 08 May 2001 10:29:06 -0400

> object with no ref attribute?

I don't believe that allowing an entry to have objectclass=referral and
no ref attribute unduly complicates the specification or
implementations.  In general, I believe all attribute types should be
optional unless there is a good reason to make them mandatory.  Why? 
Because operational experience has shown that it is inconvenient to
require administrators and LDAP clients to always add and remove the
"associated" objectclass values when adding or removing an attribute
type from an entry.  This is not a critical issue; I just think it would
be better to say "MAY ref."

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: [email-masked] (Mark C Smith)
Date: Tue, 08 May 2001 10:31:06 -0400

>   or modified.  Other parts MAY be modified or trimmed.

Looks good to me.  One nit: I would say "an LDAP URL" instead of "a LDAP
URL".

---

From: [email-masked] (Mark C Smith)
Date: Tue, 08 May 2001 10:32:18 -0400

> require that returned continuation LDAP URLs always contain an

I think that is the best solution.

-Mark

---

From: [email-masked] (Mark C Smith)
Date: Tue, 08 May 2001 10:34:42 -0400

> RFC 2251/2255 is ambiguous.

Yes.  Something to look at as part of the LDAPBis effort (I see you
posted a message already to that list).

> DN part in a ref attribute as implying the DN of the referral

It would be nice to resolve the ambiguity and not require a DN to always
be sent in the referral protocol field.  But your proposal makes sense
given the situation today.

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 May 2001 20:47:14 -0700

At 07:29 AM 5/8/01, Mark C Smith wrote:
>In general, I believe all attribute types should be
>optional unless there is a good reason to make them mandatory.

In general, I agree.  But in this case, I believe there are good
reasons for the ref attribute to be mandatory.  The primary
reason is that a referral object without any knowledge information
cannot be used for its intended purpose, to hold knowledge
information used in the generation of protocol referrals and
search continuations.  Like alias objects, I think the knowledge
information attribute should be mandatory.

        Kurt

---

From: [email-masked] (Mark C Smith)
Date: Wed, 09 May 2001 11:09:58 -0400

> information attribute should be mandatory.

Okay, I understand your reasoning.  Unless someone else wants to take a
position on this issue, I will stop arguing about it.  I can live with
either choice (MUST ref or MAY ref).

-- 
Mark Smith
Netscape

---

From: Mark Smith <[email-masked]>
Date: Wed, 09 May 2001 15:09:53 -0400

> Considerations" subsection be added.

That sounds like a good idea to me.

> Suggested text always welcomed.

Actually, I went and looked and no text for this is included in the
older named referral draft that I had in my archive.  I remember
talkingamong the authors about adding it but I guess we never did.  Here
is a rough algorithm for DN rewriting within ref values when dealing
with base objects:

Case A: If the base DN in the ref value is an ancestor of the
operation's base DN:

Step 1) Replace the base DN in the ref value with the one from the
operation.

E.g., if we have this entry on serverA:

	dn: dc=example,dc=com
	dc: example
	ref: ldap://serverB/dc=example,dc=com
	objectClass: referral
	objectClass: extensibleObject

and a search operation arrives at serverA with a base of:

	uid=mcs,ou=people,dc=example,dc=com

then the referral URI that is returned would be:

	ldap://serverB/uid=mcs,ou=people,dc=example,dc=com

Case B: The base DN in the ref value is NOT an ancestor of the
operation's base DN:

Step 1) Start with the operation base DN. Remove the portion on the
right that matches the DN of the entry containing the ref value.

Step 2) Prepend the result of step 1 to the DN that is in the ref value. 

E.g., if we have this entry on serverA:

	dn: dc=aol,dc=com
	dc: aol
	ref: ldap://serverB/dc=aoltimewarner,dc=com
	objectClass: referral
	objectClass: extensibleObject

and a search operation arrives at serverA with a base of:

	uid=mcs,ou=people,dc=aol,dc=com

then Step 1 produces:

	 uid=mcs,ou=people,

and Step 2 produces:

	ldap://serverB/uid=mcs,ou=people,dc=aoltimewarner,dc=com

-Mark Smith
 Netscape