DUA implementors guidelines

[[e-mail]]

As a result of the email discussion about LDAP, it was suggested
by Tim Howes that a separate document be envisaged:
  Guidelines for X.500 "clients" implementation.

This proposal was done within the LDAP context, with 2 goals
in mind:
  - how to make efficient use of the LDAP set of available operations
  - avoid implementation dependencies.

This issue was discussed during the WG-NAP meeting in Trondheim,
and I suggested that the goal should have to be larger.

I am really convinced that this guidelines document has to be prepared
for X.500 "clients" in general and not limited to LDAP, because
our experience with several different implementations has shown
that many existing X.500 clients are still designed without
a clear view on the impact of the algorithm used on
  - specific impementations
  - specific structuring and distribution of the DIT over
	different DSAs
Of course a specific section will have to be devoted to LDAP
and its set of operation, but this will only have to cover
what is specific to LDAP (not too much in my mind).

The last message from Steve Kille, when talking about 1rst
and 2nd generation DUA, highlights the evolution (gained
from experience) of X.500 clients algorithms (BTW this TERM
seems to me more appropriate than DUA for this purpose).
It is really time to share and write down our experiences
in that area, because it does not only have a great impact
on "clients" design, but also -- and probably even more
important- a very high impact on the design of the servers (DSA)
themselves.

As our goal is "success" and "deployement" of X.500, it is of the highest
importance that, as soon as possible, our community is provided
with an efficient X.500 infrastructure (ie. clients + servers).
To reach this goal it is mandatory that the
   - Client designers/implementors are well aware of the servers
	behaviour
   - Server designers/implementors are well aware of the clients
	behaviour and requirements.

I don't know how this concretely could be handled, but given
the importance and consequences I suggest this activity
be started as soon as possible and associates all "players"
ie. at least osi-ds, wg-nap, and paradise interworking group.
Steve, any suggestion?

BTW: Tim Howes will give a lecture here and participate
to a working meeting (May 27th and 28th) and we have
planned to start discussion about this.
Thus some contribution might be expected as an early outcome.
Steve, would it be possible to have this item be part
of the OSI-DS agenda in Amsterdam?

best regards,

-- PAP


~h