[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Regarding <draft-ietf-ldapext-knowledge-00.txt>
Date sent: Fri, 23 Jul 1999 10:57:18 -0500
From: Christopher Lukas <lukas@cs.wisc.edu>
> David,
>
> After an admittedly cursory reading of the draft and the messages about
> it, I'm somewhat confused. As a general comment, I think the draft could
> use some clarification like that you've written in some of your messages
> about the draft.
You are absolutely right of course. The draft was just that, a draft,
written about a year ago and sent away for comments by Mark and
Tim. But after a while the comments seemed to fizzle out so I forgot
all about it until your named ref ID came out, and I saw there was
interest once again. Thats why I quickly re-issued it to get some
more comments flowing. There is quite a lot of extra text that needs
adding. For example, it is now obvious that immediate superior
references are now "in", and that NSSRs are now a possibility once
again. Also there are many more examples of use that need adding
to section 5.4. These will make the ID much more understandable.
>
> So the general point of the draft is to allow servers in different
> namespaces to refer to one another by sending clients referrals, right?
No, this was not the general point. The main point was to allow
thousands of servers using the same name space to interconnect,
as I suspect that this will cover most servers (especially those that
use the DC and country based naming schemes as they are all part
of the same global namespace). But we also recognise that some
"do it yourself" types will set up their own namespaces without
reference to anyone else, so I was also, as a secondary aim,
hoping to help them as well. But this remains a secondary aim from
my perspective. (We cant stop people shooting themselves in the
foot, but if they do, it would be nice to have a hospital nearby).
>
> It seems like the draft has some redundancies with the
> draft-ietf-ldapext-namedref-00.txt. Don't the referrals with types
> "cross" and "subr" function in the same way as referrals defined in
> draft-ietf-ldapext-namedref-00.txt?
I see namedref as a subset of the knowledge ID. So yes, there is
some redundancy between the two, which means that they could
easily be merged. The main differences as I see it are
i) the DN is removed from the ref attribtue in the knowledge ID as it
is unnecessary duplication (it is the same as the name of the DSE)
ii)knowledge has a ref type and namedref does not
iii)knowledge supports more types of references than namedref
(and new types can easily be added as required)
iv) protocol field was removed in knowledge as I did not think
anyone used it, but it can be easily put back if it is needed.
That is a quick summary of the major differences.
>
> Also, the "sup" referral is closely related to the other discussion
> about the namedref docuemnt for "smart" superior referrals. I don't have
> an issue with it, but I think it falls into the "other ways to do smart
> superior referrals" that I talked about in that thread.
>
> In fact, isn't this draft really a specification on another way to do
> "smart superior referrals"?
Actually it wasnt, but it can easily be added. Immediate superior
references are not in the knowledge ID.
>In one sense, when a server doesn't hold a
> naming context, it doesn't really matter whether or not the requested
> context is in that server's local-global (by this I mean the global
> namespace from the perspective of that server) namespace or not. Couldn't
> one simply have one extra type of referral, namely "external" and let the
> "normal" referrals take care of subr and cross functionality?
Yes, I think you could extend it this way. If you have external ref
attributes at different points in your DIT, you could send new
external referrals to the client ("this particular DN exists in this other
external namespace over there, you might want to try contacting it.
Here's a referral to it") but I did not get this far in the knowledge ID.
Are you suggesting that I should? (I think it would be useful) Or
should we forget about externals for now?
>
> Also, does the draft indicate that clients will need to process the
> various referral types differently? Why?
AH, now I possibly see a major misunderstanding. The client is
never told about the knowledge type at the moment. It is simply given
a standard referral. Note that I have NOT changed the format of the
referral, only the ref attribute. The server takes the ref attribute and
turns it into a referral for the client. But we do have some problems
to encounter once external refs and NSSRs are to be returned to the
clients, because the existing referal construct will not work for these.
David
>
> - Chris
>
>
>
> ------------------------
> Christopher E. Lukas
> Internet Scout Project
> http://scout.cs.wisc.edu
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
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
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************