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
> 
>