Re: interworking issues

Paul Barker <P.Barker@cs.ucl.ac.uk> Wed, 02 November 1994 18:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09128; 2 Nov 94 13:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09123; 2 Nov 94 13:30 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12465; 2 Nov 94 13:30 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03344-0@haig.cs.ucl.ac.uk>; Wed, 2 Nov 1994 17:21:26 +0000
Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.00432-0@bells.cs.ucl.ac.uk>; Wed, 2 Nov 1994 17:20:43 +0000
To: pays@faugeres.inria.fr
cc: osi-ds@cs.ucl.ac.uk, punters@nameflow.dante.net
Subject: Re: interworking issues
In-reply-to: Your message of "01 Nov 94 14:46:51 +0100." <783697611.25658.0-faugeres.inria.fr*@MHS>
Date: Wed, 02 Nov 1994 17:20:38 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Barker <P.Barker@cs.ucl.ac.uk>
Message-ID: <9411021330.aa12465@CNRI.Reston.VA.US>

> 3. the time-outs are very different and in some case don't even allow
>  for retrieving entries with larger content (eg. X.509 certificates)
>  especially when a X.25 link has to be used for reaching the leaf DSA.
>  they need to be short, but not that short
> 
My view is that timeouts should be as long as the patience of the user,
possibly within some very large maximum.

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

> 7. some clients have strange behaviours preventing interop
>    this may come from the search filter see above
>    this also come from non-conformance (or Quipu proprietary features)
>    -- this seems to be the case of "de" (at least the publicly
>    available DUA at ULCC)

I wish you wouldn't say things like this (about DE) without some sort of 
supporting evidence.  DE doesn't use quipu object classes in filters.  It does
ask for the quipu attribute masterDSA when reading country entries, so that
it can use a modified search algorithm (more use of read and list) when
querying countries which do not use the Quipu distribution model.  Your
comments of two/three years ago prompted this change.
> 
> 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.

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

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

Paul