interworking issues

[[e-mail]]

After having spent some time looking at the logs of both
  the french master (OPAXdsa) and an organisational DSA (INRIA)
  I would like to submit a few observations comments to the experts
  and managers of these lists

1. the effective interworking has improved a lot (a big lot) in the
	last 6 months
  bravo and thanks to all the contributors
	product suppliers   they have really provided us with much
		better interworking products (and notably between
		Nexor QUIPU and TS-E3X UCOMX.500)
	DSA managers which have better configurations and settings
	clients (DUA) suppliers which are generaly behaving with
		a lot more respect of both the standard and the effective
		operational constraints
	and I will not forget :-) PAradise OIFP (VALUE X.500) which
	enabled to identify and often fix several key problems
	thanks Bruno Koechlin

2. However there are still plenty of more or less minor problems
	and I will try to list them below so that suppliers
	and mangers might try to improve again the situation.

---------

Here is my list:

1. There are still several clients which are not using the PSAP
	officialy announced and used in Paradise
	(eg. a goX500 gtw somewhere in michigan seems to use a
	PSAP which is many weeks old for the frrench master:-(

2. There is an awfull lot of discrepancies between clients which
  claims to be of the same origin
  
  . for the WWW LDAP X500 gateway
	the processing of some attributes is different from one to the
	others:
		MHSORaddress  OK at isode.com, generaly not elsewhere
		pictures : some problems (eg. Huizer Photo) or  not
	
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

4. many clients still depend to heavily on the QUIPU specific
  attributes (eg. QuipuNonLeafObject) and behave particurlarly bad
  when not available
  eg. the isode.com WWW X500 gateway insists in searching twice
  each leaf entries in non QUIPU DSA 
    performance is bad, load for server far to high and unjustified
  while unmodified version are now correct
  Behaviours such as the isode.com one should be banned from
  Paradise... How?

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

6. several DSA are configured so that they do not accept search on
  perfectly not sensible attributes (eg. stateorprovince)

  ==> from 5 and 6 we see an absolute need to have common/acceptable
  recommandations (a RFC probably) as regards the list of searchable
  attributes (at a given level) and more generaly in the longer term
  the use of a usable version of something similar to search guides.
  We need that in the short term to configure DSAs and adjust client
  algorithm accordingly

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)

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)
  -> clients seems to be neraly completely unaware of loops
  and of loop-detection code in such configurations.



9. the uncontrolled freedom in creating/modifying ObjectClasses
  or even in some cases attribute definition, or even to still use
  obsolete definitions (eg. still oldQuipu photos with the same oid)
  is an unsolvable problem on the clients side in an heterogeneous
  environment



there are many many others minor glitches

but let me terminate with the MOST SERIOUS one : conformance

NO CHANCE to achieve really acceptable interworking with non
conformance....

  Most products (if not all) are still non conformant and
  unfortunately all QUipu public versions.
  notably many many products do not handle correctly the
  Operationprogress and Nameresolution properly.

  eg. there will be no real interworking as long as products
  will at the same time
	set the "DontUseCopy" flag
	while not setting correctly Operationprogress and Nameresolution
   -- this may be acceptable zwith the QUIPU knowledge model, but
      is not acceptable for any conforming implementations


Hope this may help improve the situation

-- PAP