Problems with named-ref draft with replicated entries

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

I have a big problem with the draft called draft-ietf-ldapext-namedref-00.

This is in the area of efficient searches through information where part
of the information is copied from other places.

My canonical example is the Norwegian Directory of Directories, which I
am currently in charge of designing & implementing.

This will have a server carrying full information about one level of the
Norwegian directory tree (the one below C=no), and no information below that.
The information stored is not mastered with the NDD; it's either copied
in from another database or spot-replicated from other LDAP services into
the NDD.

My constraints are:

- Single level searches under C=NO must be executable WITHOUT chasing
  referrals.
- Whole subtree searches under C=NO, O=xxx MUST be referred to the
  LDAP server(s) of O=xxx

This means that I can NOT use the "ref" method as stated, because of the
paragraph that says (5.1.1.3):

>If a matching entry contains a ref attribute and the URI contained in
>the ref attribute is NOT an LDAP URI [RFC2255], the server should return
>the URI value contained in the ref attribute of that entry in a Sear-
>chResultReference.
>
>If a matching entry contains a ref attribute in the LDAP URI syntax
>[RFC2255], the URL from the ref attribute must be modified before it is
>returned by adding or substituting a "base" scope into the URL. If the
>URL does not contain a scope specifier, the "base" scope specifier must
>be added. If the URL does contain a scope specifier, the existing scope
>specifier must be replaced by the "base" scope.

In my case:

- The server knows every attribute of that entry. So it knows what should
  be retrieved by the search.
- The server has an open information model, meaning that access controls
  are Not A Problem for search (cross your fingers!)
- The server has one million entries at the single level, and hopes to
  have tens of thousands of them containing ref attributes or equivalent
  after a few years of operation.

I suggest the following modification:

"If the server has complete information on the content of the entry,
as it would be retrieved from the remote server, the server MAY return
that information in the search.
(Question: do we have DontUseCopy/Cache controls defined this week?
They obviously interfere....)
(Questionable addition: Should the server include the "ref" attribute in 
the reply? Or return that if asked for it, even when manageDSAIT is not set?)

If the server does not have complete information on the content of the entry,
the server <<<existing text goes here>>>

(BTW, this gives something very close to X.500 NSSR.....hmmmm...)

Comments welcome!
(This question will also be raised in the LSD BOF, if LDAPEXT doesn't
beat it to death before that....)

                   Harald A







--
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no