Re: OIW/XAPIA Directory Synchronization Paper

     As I recall the choice was to use terminology in the NADF documents 
     that were based on earlier drafts of X500(93) or to use the terminolgy 
     in the DISP documents. The other issue we were addressing related to 
     expressed concerns on the part of non-X500 proprietary mail and 
     dir-synch vendors regarding the overhead and complexity of extensive 
     use of ASN.1 (in some cases, fear and loathing of ASN.1). So 
     simplifying the ASN.1 was seen as a big win and making clear that it 
     was different from DISP (you don't need a DSA to do XAPIA DirSynch) 
     was also a big win in potentially motivating large proprietary email 
     vendors (wonder who they might be?) to migrate their Directory export 
     capabilities directly to the XAPIA format. 

     Audience of implementors was seen to be: proprietary email vendors, 
     X400 vendors (it is XAPIA, right?), proprietary dirSynch/email (I like 
     the h) vendors, and X500 vendors. Ignoring the needs of the entire 
     audience in preference for an X500-specific solution will provide a 
     window of opportunity for gateway/dirSynch/X500 vendors but might have 
     the nasty side-effect of making the spec irrelevant.

     If you look at the models, the architecture was meant to work in 
     environments that have X500 DSAs in them and environments that don't 
     have X500 DSAs in them. X500 was not envisioned as the center of the 
     DirSynch universe. X500 was seen as yet another Directory. In the 
     non-X500 environment, some directories are hierarchical and many are 
     flat. In a flat directory space, how useful is a DSE? Also, a lot of 
     issues addressed by X500 attributes regarding master/shadow and 
     complete/non-complete records is irrelevant for many flat directories. 
     The concept of an agent interfacing between Directories and the 
     virtual DirSynch space was there to allow mappings to different 
     directory environments.