Re: LAST CALL: draft-ietf-ldapext-referral-00.txt

[Tim Howes <howes@netscape.com>]

David Chadwick wrote:

> Tim
> this document is fine apart from the following:
>
> i) it does not support the X.500 NSSR model of chaining and
> referrals, and is incompatible with the X.500 model for subordinate
> reference chaining and referrals. This is because X.500 has unified
> the chaining and referral techniques to be the same for both
> reference types. LDAP presently only caters for subordinate
> references and not NSSRs. The reason is as follows: X.500 passes the
> name of the superior entry in the continuation reference or referral,
> and informs the subordinate DSA to continue with the children below
> this entry. LDAP on the other hand passes the name of the subordinate
> entry in the referral, and informs the server to continue with this
> entry. Consequently LDAP cannot cater for NSSRs, simply because the
> names of the children are not known by the referencing server.

There was some talk earlier of addressing this with an extension
to the URL giving the name of the superior entry. Mark Wahl
also had some ideas for how to handle this on the X.500 side
as well. So we decided to defer that to a separate document, or
possibly a later revision. Do either of those solutions appeal to
you? Any better suggestions on how to best address this would
definitely be appreciated.


> ii) section 5.3 on unnamed reference is misleading in my opinion. I
> did send email to Mark (and ASID)  in July 97 pointing out some
> ambiguities (but I dont remeber receiving a reply).
> You state that this use of the ref attribute is similar to the
> non-specific subordinate reference in X.500. But from my reading of
> the current text it is quite different. In X.500, in the referencing
> DSA, we know the DN of the entry holding the NSS reference (it is in
> fact the name of the parent entry of the child naming contexts) but
> we do not know the name of the child entry(ies) that is(are) pointed
> to by the referencing DSA. In the LDAP unnamed reference, the DN of
> the entry that the ref attribute is held in, is the ref attribute
> itself, (which is not a usual DN, I suppose this is why you are
> calling it an unnamed reference) but we do know the name of the entry
> in the referenced DSA. The LDAP DN occurs in the referral of course!
> So it is quite wrong to liken it to an NSSR. It is actually much more
> like a cross reference (with optional indexing information), and it
> might be better (and a lot clearer) if you redrew it that way i.e.
>  Server A
> dn: o=abc,c=us
> ref:ldap://hostB/o=abc,c=us
> cn:babs
> cn:gern
> cn:bob
>
> In your section5.3 you are implying that you do not have
> information that you actually do have i.e. the name of the referenced
> entry. It is thus wrong to call it an unnamed reference, when as I
> have shown above, the name of the reference is clearly known from the
> referral itself.

Point taken. I'll remove the reference to X.500 NSSRs. And I'd
happily call this type of reference something else. My limited
brain power just could not come up with a better name. Any
suggestions?                                           -- Tim