[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LAST CALL: draft-ietf-ldapext-referral-00.txt
> 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?
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
***************************************************