Re: Regarding <draft-ietf-ldapext-knowledge-00.txt>

[David Chadwick <d.w.chadwick@salford.ac.uk>]

> ==========  SG ==================
> If we are talking about different namespaces (I don't like the word
> "global" cause that gives an impression of one namespace for the entire
> world.),

I am using the term global in a relative sense, ie. relative to that
directory name space. Each directory namespace domain thinks it
is a global namespace, since every server in its domain conforms to
its naming scheme. As a side point, there is a difference between a
naming authority and a directory namespace domain. A namespace
domain may encompass many naming authorities. For example,
domain names are operated by one naming authority (ICANN), and
ISO based country names are operated by other naming authorities.
But these can be combined into a single directory namespace
domain using different attribute types.

>then what is the relevance of keeping the referral. To refer to a
> particular node of a entirekly different namespace the current server
> needs to keep the knowledge of that entire namespace. To make it less
> confusing let me present an example.

No I dont believe so. Say I am looking for information about an entry
named  DN1, this entry may exist in one or more directory
namespace domains. Same DN but different attributes (it may be
the name of different objects or the same object, this is irrelevant).
Therefore if one directory namespace knows about another one, it
can refer me to that one by pointing to the root of that namespace
and letting that remote set of servers find the entry named DN1. I
can then two different sets of attributes about the object named DN1.

>    Let us have two namespaces "A" and "B". If a server "SA1" within the
>    namespace "A" needs to refer a client, which came to it, to some server
>    "SB1" belonging to namespace "B" then it has to retain the knowledge
>    (i.e the complete structure along with schema) of the namespace "B".

No I disagree. It only needs to have a pointer to one or more of the
LDAP servers that hold the remote namespace. It can then leave it
up to them to solve the user's query however they want to.

>    This assumption or requirement is not practical and in real life not
>    acceptable. So how can LDAP servers from namespace "A" refer to
>    specific servers in namespace "B". I think cross namespace references
>    need a better definition and much more rigid operation. Do you agree?

No for the reasons given above. The referral simply says "Hey there
are a bunch of LDAP servers over there that have a different
namespace to mine. Here is a pointer to one (or more) of them. (It
does not reallymatter which one, except perhaps for efficiency
purposes.) They may be able to help you get information about this
(these) objects you are looking for."

I see this of particular use for organisations that have set up their
own independent LDAP servers without any reference to any
naming authorities (ie. they invented their own namespace). Then
sometime later they find they want to connect their directories to
each other but cannot because of name clashes. So the external
references caters for this. You might want to think of it as a bit like a
superior reference to an external namespace, if that helps.


>
> ==========  SG ==================
> If privateRef is within the server then why would one need it. Since the
> data that the referal is trying to point is within the same server, why
> does one need a referal? ==========  SG ==================
>

This is easy. There are two reasons for defining these knowledge
attributes. Firstly ease of open distributed management. A manager
client can dynamically update knowledge attributes via LDAP.
Secondly, privateRefs are not all refs to data in this server. I actually
said privateRefs  are private to the server they are stored in and
cannot sensibly be shared with other LDAP servers without some
modification or changes being made to them. So a superior ref is a
private ref, since the superior server of one LDAP server is not
necessarily the superior server of another LDAP server. Thus the
ref cannot be shared. It is private. YOu have confused private with
pointing to internal data.



>
> ==========  SG ==================
> My implementation does the processing and hence I do not need the sup or
> sub. It is simplistic but works fine. I hadn't read you spec when I
> starting working on this last summer.
>
> ==========  SG ==================

This is a real shame, because I wrote my spec over a year ago but
did not post it to the list because I thought the work had died a death
i.e. noone was interested in persuing it. Clearly I was wrong. But just
to clarify, when you say sup you actually mean immediate superior,
since immediate superior has an associate DN whereas superior
has the null name associated with it and so no processing is needed
to know that the sup server is superior to the current one. It is by
definition always superior, and by storing it in the root DSE you
know it is superior, so no processing is needed to work this out.

David
>
> Hope the above helps
> ¤
> David
>
> >
> > I would really appreciate if you guys help me see light here.
> >
> > Regards
> > Sukanta Ganguly
> >
> >
> >
> >
>
>
> ***************************************************
>
> 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
>
> ***************************************************
>
>


***************************************************

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

***************************************************