> - U-Mich or commercial LDAP server(s) capable of talking DAP/DSP to
> the X.500 root server
>
> - DCE directory servers and security registries populated with
> extended attributes of interest, such as campus/building/room,
> voice/fax phone number(s), public keys, etc.
>
(buzzer sound)
first -- no EAs in CDS. Would like to have them -- but then that would make
CDS a "real" Directory service and not YANN ( a pun on YACC, where NN ==
Network Naming service).
second -- I hope that in the list of EAs above you only meant to include
the pub keys in the registry. I think there are valid reasons for the
separation of "church (security) and state (everything else)" in DCE.
> The conjecture:
>
> - I intend to find out whether an LDAP browser finds the DCE directory
> service data visible
>
Though must be on druggeth....It might find the A/Vs for the CDS servers
and clearinghouses as they have been advertised in the DSAs, but no way
does an LDAP browser start making auth-rpcs with CDSPI calls.
> Anyone have any experience with this? If so, does it work? If not,
> how did you solve the functional requirement I wish to address with a
> minimum of redundantly stored data?
>
Federation of naming systems...now where have I heard that term before....I
think it has an X in front of it....
An alternative is to use CDS where you want to put X.500 and work on
defining a DCE-based junction/federation protocol that extends things like
/.:/sec, /.:/fs, /.:/hosts/foo/config (which btw already exist in DCE...)
to arbitrary junctions, with a generic interface for namespace browsing. I
can send you a paper that I presented 2 years ago at the DCE conferences in
San Jose, Boston and London that spells this out, blow by blow, including a
ns_discovery.idl. It allows a service to define its namespace in terms of
EAs with an interface that can search and display, add and delete, etc.
If you have DCE -- you might as well exploit its wonders...
-jonathan