Re: interworking issues

[[e-mail]]

> 
>    >	and I will not forget :-) PAradise OIFP (VALUE X.500) which
>    >	enabled to identify and often fix several key problems
>    >	thanks Bruno Koechlin
> 
> I will second that, it was, despite my inital sceptisim, very useful
> for us in identifing, resolving and testing many of the interworking
> issues between our products. 

Thanks a lot Colin.
I will just add that it inderectly also improved a lot the interop
with other products (even not participating to the platform
or tests)

> 
>    >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)
> 
> Could you please elaborate upon this?


I have not all the desirable information to come to conclusion

  often clients tend to include "non searchable" attributes into their
	search filters  -> rejected -> no result
	pb: how to know what will be accepted???? RFC...

  I suspect and in some case nearly proofs that some clients
     algorithm are heavily dependant on the "leaf nonleaf"
     indicators
       - this is clearly something needed and a LACK in the std
       - this is however QUIPU proprietary

  finaly I have observed "strange" behaviours (which must be
  understood as : I have not been able to understand identify
  because of time and because of the debug level of DSAs
  serving many 1000 queries a day)
    if you want more, then use the "de" and observe your own logs
      or ask UCL/ULCC to send the "de"logs... 
   for other clients.... I think it is up to the designers
	to test their products againt several other products
	and they have the french master at hand to check what happens
	  -- but please dont use OPAXdsa as a "crash test system" :-)
    sorry I cann't help more

> 
>    >  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 with the QUIPU knowledge model, but
>    >      is not acceptable for any conforming implementations
> 
> I believe this is one of the issues identified in the OIFP testing.  
> As you are aware, we adapted the knowledge model used within our
> version of QUIPU to behave correctly if the remote DSA is not known to
> be a QUIPU system.  The behaviour under 'dontusecopy' was one of the
> last components we worked on before the OIFP funding ran out so may not
> have been fully tested within the platform, but I am confident the
> mechanism now works correctly (as installed on the DANTE central
> machines).

Indeed the interop seems much better, though we have not tested
this entirely.... And I was not attacking your product...
The trouble is that there are still many other products
(including old Quipus) around and not all :-) queries are
chained by Giant Tortois... Moreover we have no information
about which software is sending which query...
> 
> 
> Colin
> 

-- PAP
>