[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LAST CALL: draft-ietf-ldapext-referral-00.txt
David Chadwick wrote:
> > Date: Fri, 20 Mar 1998 19:46:34 -0800
> > From: Tim Howes <howes@netscape.com>
> > Organization: Netscape Communications Corp.
>
> > > 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.
> >
>
> This is a tricky issue, as my last message mentioned. I suggest that
> we do the following
> I) take a vote on whether NSSRs should be supported, or kicked into
> touch. I can tell you that NSSRs caused us a lot of pain in X.500
> distributed operations (more than their benefit warranted in my
> opinion) but some folks were rooting for them. Steve Kille was one
> expert who stood up for NSSRs once upon a time. I dont know if he
> still does or not.
> Then when this is issue is resolved:
>
> II) if we decide to ignore NSSRs forever, no problem, the basic
> document (or my revised approach as per my last email) can continue,
> but
> if we decide to support NSSRs either now or in the longer term, I
> think that the support should be built in now. This is simply because
> the investment in the existing referral mechanism may get too great
> for anyone to want to retrospectively fit in something new a few
> years from now. We may already have reached that point anyway, but
> the vote above should determine this. However, I dont think that
> technically it is difficult to build support for NSSRs into
> referrals, we simply need "a bit" to indicate if the DN is the DN of
> the actual entry or of the parent of the entry. It should be that
> simple.
>
> > > 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?
>
> Well I have given one already (cross reference) but this depends upon
> using my revised model for knowledge references, which I think is
> cleaner than the current approach anyway. What do you think?
I aggree with David and think we should change this and should not haveany
reference to X.500 NSSR's in the document.
Helmut
>
>
> David
>
>
> ***************************************************
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351 Fax +44 161 745 8169
> Mobile +44 370 957 287
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> ***************************************************
begin: vcard
fn: Helmut Volpers
n: Volpers;Helmut
adr: Otto-Hahn-Ring 6;;;Munich;;81730;Germany
email;internet: Helmut.Volpers@mch.sni.de
title: Directory Server Architect
tel;work: +49-89-63646713
tel;fax: +49-89-63645860
tel;home: +49-89-1576588
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard