Re: interworking issues
Bruno Koechlin <Bruno.Koechlin@inria.fr> Thu, 03 November 1994 21:31 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09082; 3 Nov 94 16:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09078; 3 Nov 94 16:31 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa16590; 3 Nov 94 16:31 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03327-0@haig.cs.ucl.ac.uk>; Thu, 3 Nov 1994 19:13:08 +0000
Received: from concorde.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.11442-0@bells.cs.ucl.ac.uk>; Thu, 3 Nov 1994 19:12:48 +0000
Received: from nuri.inria.fr (nuri.inria.fr [128.93.1.26]) by concorde.inria.fr (8.6.9/8.6.9) with SMTP id UAA28014; Thu, 3 Nov 1994 20:12:38 +0100
Received: from localhost.inria.fr by nuri.inria.fr; Thu, 3 Nov 1994 20:15:16 +0100
Message-Id: <199411031915.AA20086@nuri.inria.fr>
To: P.Barker@cs.ucl.ac.uk
Cc: punters@nameflow.dante.net, osi-ds@cs.ucl.ac.uk
Subject: Re: interworking issues
In-Reply-To: Your message of "02 Nov 1994 17:20:38 GMT." <"3383 Wed Nov 2 17:22:48 1994"@cs.ucl.ac.uk>
Date: Thu, 03 Nov 1994 20:15:16 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruno Koechlin <Bruno.Koechlin@inria.fr>
> > > 5. many clients algorithm for searches will not give good results > > because they insist on searching filters which are not allowed > > eg. UserId is NOT searchable for legal reasons in most french DSA > > > This is a problem. I favour some sort of search guide approach, where > organisations can identify the type of searches that are allowed beneath a > node. This allows the best of both worlds: complicated filters if you want > them and they are supported, and the knowledge of what simple filters will > work as a lowest common denominator strategy. I guess that I agree with that Either we enforce a very strict and homogeneous schema which would allow us to design rather simple client algorithms or we make it possible to having a less homogeneous schema which means that client algorithms must be more powerfull and complex in which case these algorithms require additional information in the DIT to help them. I guess that this is what Paul calls the search guide approach. Even in this case the client must have the knowledge of the common schema. So far we have had neither a strict schema nor what is required to have powerful clients. In a pilot this is possible, in an operational service this is no longer possible. > > > > 8. there is still a severe lack of consistency for the respective use > > of chaining vs referals > > -> performance tend to mandate referals (at least in the higher > > part of the hierrachy) > > I am planning to examine this point very soon for some research I am doing. > My hunch is the the opposite of your assumption. This will depend on the query and the environment: if the result consists of a huge amount of data , if you have to chain it throught several DSAs connected by low lines, the referral mode is more efficient. If you retrieve a small amount of data there may be not much difference. The referral mode also makes the "bottleneck problem" less important at the top of the DIT. My feeling is that as long as the name resolution has not been completed the referral mode should be used, after ... > > > -> clients seems to be neraly completely unaware of loops > > and of loop-detection code in such configurations. > > > An argument for chaining, putting such complexity in DSAs, and having to > get it right once, rather than in every DUI. > > I agree that such complexity must not be put in every DUI and a good architecture could be the following one : DUI ----- Directory Access Agent ---- Directory Infrastructure The DIU would only use a lightweight protocol to access the directory. The Directory access agent would be responsible for searching in the directory infrastructure which means - sending basic queries known by the Infrastructure - assessing the results of these queries in order to * resend the same query to another DSA * resend a new refined query * return a result/error to the DUI > > > but let me terminate with the MOST SERIOUS one : conformance > > > > Inasmuch as this means that we all have to speak the same protocol, I agree. > Whether we should be looking for slavish conformance to a model which > many of us doubt is THE way forward is another matter. I suppose my fear > amounts to a feeling that conformance to strict X.500 will be one step > forward for Quipu (and anyone interoperating with it), but two steps back > towards something of baroque complexity. You could say that if it had been clearly stated that this feature of this product is not conformant to X500 for an identified reason and if the consequences of this choice on the interworking level with a conformant (or more conformant) implementation had been assessed and published. The number of problems identified during the OIFP project has demonstrated that under a minimum level of conformance no service can be provided and that we were under this level one year ago. On the other hand, I do agree that implementing the whole 88 standard is a waste of time. I think that there is now an agreement on what is necessary to make X.500 survive until the 93 standard. The software suppliers involved in the OIFP project have implemented this basis but this does not mean that all the DSAs will be upgraded ... If you are concerned by complexity, how do you consider the 93' standard. My feeling is that an implementation will be so expensive that only operators and big companies could afford it. Given the shortcomings of the x500 model is it worth it ? Bruno > > Paul > >
- interworking issues pays
- Re: interworking issues Colin Robbins
- Re: interworking issues pays
- Re: interworking issues Paul Barker
- Re: interworking issues Mark Wahl
- Re: interworking issues Bruno Koechlin
- Re: interworking issues Steve Kille