[no subject]

1.  It had to be very simple so that vendors would not have to modify   
their mainline products, but just be able to build an import/export   
facility.  This would make it possible to build the import/export tools   
without shipping a new version of their software.

2.  The development of the spec had to be done within one year.  The   
group felt that the need was urgent and that those uses planning to go to   
X.500 needed an interim solution.  It was felt that an API effort would   
have taken at least twice as long, and most companies weren't ready to   
commit people beyond 1994 for the development of the spec.  The lifetime   
of the spec was anticipated to peak within 3 years of the start of the   
work, with certain legacy systems continuing for an indefinite amount of   
time.

3.  The specification had to implementable in environments that are not   
using X.500 as well as between two or more non-connected X.500   
Directories.

4.  Some people were concerned that the development of an API would have   
made it into very few products - we had no vendor commitments or interest   
in this approach.

If there is enough interest in an Dir Sync API and people are willing to   
devote a significant amount of time to developing a spec, then I think we   
should discuss that and see what we can do.

Alexis Bor
Chair, XAPIA Directory Sync Committee
bora@ct.si.cs.boeing.com
 ----------
From:  capple
Sent:  Thursday, March 16, 1995 6:24AM
To:  Kirpal Khalsa; epg; Neil Cook
Cc:  xapia-dirsynch; dssig
Subject:  Re: Re[2]: OIW/XAPIA Directory Synchronization Paper

Given that the sync spec specifies only a file format and indicates
that all other synchronization-related technology can be proprietary,
I question its utility during the development of inter-enterprise
directory synchronization tools. My belief (that you will probably
disagree with me is not in question) is that directory synchronization
should be treated as a service with an API defined such that a library
of synchronization-related functions could be used by DSA's (and here,
I mean the logical concept of a directory service agent, not necessarily
the X.500 DSA).

Currently, the specification reminds me of the way that we might have
performed synchronization a few years ago. I suppose it is possible
that the intention in writing the spec the way that it has been, is,   
quite
specifically, to keep synchronization functionality within the very   
entities
that require it. This seems a bit short-sighted to me, given that this
synchronization spec should more likely be developed as a stepping stone
to and a systems integration tool for designing synchronizable directory
service systems from (currently) incompatible directory technology.
I think that this spec should have a shelf-life of approximately five
years (the point at which I think we may begin to see some unification
of various and sundry directory schemas). Since proprietary technology
is often difficult to integrate into systems for which it was not   
expressly
designed, the thought of implemetors building synchronization technology
based on proprietary concepts, really scares me. This could create an
interoperability nightmare. If the intention is to eventually extend the
scope of this sync spec into the areas that are currently delcared as
proprietary and sacred, then I apologize for the criticism. I just felt
that this extension should have been made before we moved so close to the
closing date for the spec.


Chris Apple
AT&T Bell Laboratories
capple@arch4.ho.att.com