Re: root knowledge
pays@faugeres.inria.fr Fri, 24 April 1992 21:53 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02974; 24 Apr 92 17:53 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15116; 24 Apr 92 17:57 EDT
Received: from bells.cs.ucl.ac.uk by NRI.Reston.VA.US id aa15112; 24 Apr 92 17:57 EDT
Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <g.05038-0@bells.cs.ucl.ac.uk>; Fri, 24 Apr 1992 21:38:45 +0100
X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Fri, 24 Apr 1992 21:38:03 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Fri, 24 Apr 1992 21:38:00 +0100
Date: Fri, 24 Apr 1992 22:38:00 +0200
X400-Originator: pays@faugeres.inria.fr
X400-MTS-Identifier: [/PRMD=inria/ADMD=atlas/C=FR/; 704147880@faugeres.inria.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: root know...
From: pays@faugeres.inria.fr
Message-ID: <704147880.3868.0@faugeres.inria.fr>
To: P.Barker@cs.ucl.ac.uk
Cc: osi-ds@cs.ucl.ac.uk
Subject: Re: root knowledge
(In reply to a mail from P.Barker@cs.ucl.ac.uk 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
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Steve Hardcastle-Kille
- Re: root knowledge Sylvain Langlois
- DSAs through ISDN connections Sylvain Langlois
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Christian Huitema
- Re: root knowledge Steve Hardcastle-Kille
- Re: root knowledge yeongw
- Re: root knowledge Andrew Waugh
- Re: root knowledge yeongw
- Re: root knowledge Andrew Waugh
- Re: root knowledge yeongw
- Re: root knowledge Thomas Johannsen