Re: root knowledge

[[e-mail]]

(In reply to a mail from [e-mail] dealing with methods
on how to exhange (out 0f protocol) knowledge info between
heterogeneous implementations of X.500. P Barker is planning
to provide an uptodate file containing the current knowledge
of Giant Tortoise, and a pizarro script was proposed which tries
to extract this root knowledge.
As it seems the problem with heterogoneous implementations might be
complex, I take profit from this to suggest a new OSIDS to
cope with this problem - second part of the message-)

>
> Paul-Andre,
>
>   It looks as though your duat script does the job pretty well.  I will
> stick with what I have already as we need to be able to offer this service
> to other people.  I may enrich the attribute set, along the lines you have.
>
> Paul
>


That's fine.
The problem that remains with our script and the difference
(apparently) that remains with the data you provided is that
our script limits to search  (one level) for
	Class= dSA;
 under the root
and that
  is it certain we will get all "national masters"?
	Does QUIPU enforce to have them all under the root?
  as, we don't manage the EDBInfo attribute (entry?), we have no garantee about
	the knowledge to be associated with each of them.
	We have to rely on the Desc attribute value :-(
	Thus, for example, it seems we have extracted several DSAs which
	are not	"national masters" and that it is often difficult to know
	which is wich

The advantage with your results is that "we take them for granted",
whereas with ours we have to try to make educated guesses.


Thanks again for all this, and even if we (pizarro people), manage to
get directly the info, I strongly support your intention to produce
this data in an uptodate automated version with a few additional attributes.


Moreover, as we discussed it during the PARADISE meeting, I really wish
there could be a meeting and discussion between several implementors,
which would result in a "recommended" convention on how to store
and present the knowledge in each DSA. I really wish an OSI-DS #XX
could be produced that would specify this.

Basicaly the need is to have objects to represent the binding
betwee a DSA and the information it manages (directly or not,
as a matter or a slave)
What we observe today is that QUIPU and PIZARRO have choosen othogonal
approaches
	. QUIPU seems to have the DSAs managing the entries relative to
	a branch as attribute of an object describing that DIT branch.
	(is that a correct understanding of EDBInfo?)
	. Pizarro conversely for each DSA entry has attributes
	(Know-Mastered, Know-Copied, Know-Shared) that refer to the
	DIT branches for which it manages the information
	. I suspect that other implementations might have different
	different mechanism for the same logical purpose.
The task is not tremendous, whatever the approach, as it is sufficient
to associate
	a DSA (possibly by the DN of its entry)
     with
	one or several DIT branches (represented also by the DN of
	their root)
     and
	a "type of knowledge" attribute which would specify wether the
	DSA is for each branch a master, a slave and if it is
	supposed to privide access to all the entries of tha branch
	or to only some of them
I think it would really be an unvaluable contribution from the current
piloting activities to be able to aggree on such a common
recommendation (and obviously to publish it and have at least
the national master DSAs present these objects).

Two approaches might be envisaged

  1. create a brand new object class: commonKnowledge

commonKnowledge: SUBCLASS_OF top,
	MUST_CONTAIN	CN KnownBranch KnowBranchType KnownBranchHolder
	pilotObjectClass xx;

KnownBranch:        distinguishedNameSyntax,        paradise-attributeType 1;
	-- the relative root of the branch
KnownBranchType:    integerSyntax,                  paradise-attributeType 2;
	-- the type : 1: mastered, 2: copied, 3: shared, ....
KnownBranchHolder:  distinguishedNameSyntax,        paradise-attributeType 3;
	-- the DN of the appropriate DSA entry



  2. enrich the existing object Class "dSA"

dSA: SUBCLASS_OF applicationEntity,
        MAY_CONTAIN Know-mastered Know-copied Know-shared ..... .....,
        objectClass 13;

with the above knowledge attributes

Know-mastered:  distinguishedNameSyntax,        paradise-attributeType 1;
Know-copied:    distinguishedNameSyntax,        paradise-attributeType 2;
Know-shared:    distinguishedNameSyntax,        paradise-attributeType 3;

giving the DN of the relative root of the KnownBranch



Ideally the different implementations might be modified to really
use directly these new objects (and my expectation is that
this would probably happen), BUT this is not required at
all; it would be enough to duplicate the existing proprietary
knowledge information, within the above new objects to
enable heterogeneous X.500 to interoperate much more
efficiently than what we experience today.
Knowledge replication (or maybe forwarding may be a more appropriate
term) could thus be designed and implemented easily.

That along with other proposed extensions such as "in base" explicit
schema management would highly improve the success of X.500.


Regards,

-- PAP