Subject: RE: Re[2]: OIW/XAPIA Directory Synchronization Paper
From: "Bor, Alexis" <[email-masked]>
To: capple <[email-masked]>, epg <[email-masked]>, Kirpal Khalsa <[email-masked]>, Neil Cook <[email-masked]>
Cc: dssig <[email-masked]>, xapia-dirsynch <[email-masked]>
Date: Thu, 16 Mar 95 08:00:00 PST

Chris,
The initial intent of the work was to provide a common format for the   
exchange of directory information.  You may want to review the the   
minutes and output from the June 1993 OIW DSSIG meeting as for the   
perspective of the DSSIG.  The DSSIG sent a liason to a joint meeting of   
the EMA and XAPIA that was held the following week in Atlanta.

Date: Thu, 16 Mar 95 09:18:54 EST
From: [email-masked] (Christopher Walon Apple)
To: Kirpal Khalsa <[email-masked]>, [email-masked], Neil Cook <[email-masked]>
Cc: [email-masked], [email-masked]
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
[email-masked]

Date: Wed, 15 Mar 95 10:27:05 pst
From: "Kirpal Khalsa" <[email-masked]>
Encoding: 125 Text
To: [email-masked], Neil Cook <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re[2]: OIW/XAPIA Directory Synchronization Paper

     replies KSK>>

______________________________ Reply Separator _________________________________
Subject: Re: OIW/XAPIA Directory Synchronization Paper
Author:  Neil Cook <[email-masked]> at internet-mail
Date:    3/14/95 5:56 AM

In your message you said:
     
> Folks:
> 
> Will someone who  has been participating in the directory Synchronization 
> work please answer Nick's question?
> 
     
<Header deleted>
     
> Ella, I have a quick question on the XAPIA Directory Synchronization 
> Specification: Why were the TotalRefresh and IncrementalRefresh
> datatypes changed from standard DISP? 
> 
> This seems like a bad mistake to make because it means that implemetors 
> have to implement yet another set of encoders/decoders. It would have
     
I don't really think this is an issue. It took me about 1/2 a day to do this. 
More annoying is the fact that it *does* use some DISP data types, and thus 
you end up mixing and matching the two. This lead to me changing the names
of the data types which had the same name as in X.525, but were 
different. Surely it would be better to rename them,
e.g. XapiaTotalRefresh. This at least would clarify things.
     
     KSK>> we used the names in the NADF spec which was from an early 
     rendition of X.525, correct?
     
> been far better to use the standard datatypes and state that the
> components that are not required should be omitted or have standard values. 
> 
> For example, in TotalRefresh, SDSEContent in the standard protocol
> has been replaced with SET OF Attribute. It would have been better to 
> state that 
>    a) encoders always
>  1) encode sDSEType with no bits set to 1 
>  2) omit subComplete
>  3) omit attComplete
>    b) decoders always
>  i) ignore sDSEType
>  ii) ignore subCOmplete
>  iii) ignore attComplete
     
The point is that, even though they are omitted in the XAPIA format, 
if you actually want to send the information over DISP, you have to 
perform the exact steps above, i.e. fill in sensible defaults for 
sDSEType, subcomplete etc. This is particularly difficult for the area 
prefix information.
KSK>> X500 was treated in the model as a Directory type, in the same 
vein as proprietary and de facto standard directories. The pain was 
meant to be dealt with in the agents that sit between Directory 
implementations and the DirSynch space.
     
Also, I am extremely unhappy with the way that contextPrefix has been 
shoved into the spec, seemingly on a whim. We have implemented xapia 
0.6, and we used a separate shadowing agreement file to specify all 
the parameters such as where the info will be loaded into the DIT, 
which DSA to contact etc. Using contextPrefix in this way is extremely 
heavy handed, and a bit of a bodge. It only allows you to load the 
info directly under the contextPrefix, which is unsatisfactory. What 
if you wanted to load the info at a point further below the 
contextPrefix? If you only have the contextPrefix to separate between 
area prefix and area information, this is not possible.
KSK>>Good point (I'm not sure about "a whim" but that probably 
captures the spirit, whimsical might be more apt). Couldn't this be 
handled in an agent?
     
Also, a question which has been bugging me is this; are mail programs 
such as CCMail etc. expected to produce XAPIA files? Having them know 
about the area prefix info, and having to fill in the xapia informaion 
for this seems somewhat... ambitious. The question is; should the 
xapia file contain area prefix info at all? This limits the file's 
scope to a certain place in the DIT, and places a burden on the 
creator of the file to have detailed knowledge about where the file is 
going to be placed.
KSK>> Once the file format settles then CCMail can contemplate 
migrating ADE (and Export) natively or via a translation (think 
installed base of 6.5 million users) agent to this format. 
Possibilites are there regarding Notes as well.
     
If I have misunderstood any of this, then feel free to correct me, but 
from my experience, these are important issues. 
KSK>>Absolutely. 
If the effort of creating XAPIA files is too much, will people bother 
with them? 
KSK>> Probably not. We had to balance considerations of simple flat 
directories with X500 strategic directions. 
We have defined a text-format file whiich we use in a similar way to 
xapia's intended use. 
KSK>> We had debates about whether to go text based or use ASN.1. 
Every DSSIG mtg we moved to ASN.1, every non-DSSIG meeting we 
revisited text-based.
We find it much more flexible, because it contains no area prefix info 
- this is filled in with sensible defaults by the loader. This seems 
to be a much more sensible and flexible approach. It really seems that 
XAPIA was simply copied from DISP, and only afterwards was much 
thought put into seeing where it was deficient.
KSK>> We copied NADF, which copied an early version of DISP. Area 
prefix info was added with X500 in mind. If it doesn't work, drop it.
     
We have implemented xapia 0.6 for example, and found that the hardest 
part was generating files that we could use. They contain so much 
context specific info, that it is impossible to reuse a file 
containing e.g. employee telephone numbers. That is why we developed a 
text format, in conjunction with an agreement file. The agreement file 
can change, but you can reuse the information in the text file. Maybe 
an automatic text-xapia converter would be useful?
KSK>> very useful.
     
Neil.

Regards,
        Kirpal

     

Date: Wed, 15 Mar 95 09:57:29 pst
From: "Kirpal Khalsa" <[email-masked]>
Encoding: 108 Text
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: 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. 
     
     Is that useful as a backgrounder? More if you need it. Mark messages 
     urgent (in attribute and subject line) if you need rapid response, I'm 
     suffering from severe email/work overload.
     
     Regards,
        Kirpal

______________________________ Reply Separator _________________________________
Subject: OIW/XAPIA Directory Synchronization Paper
Author:  [email-masked] at internet-mail
Date:    3/13/95 6:12 AM

Folks:
     
Will someone who  has been participating in the directory Synchronization 
work please answer Nick's question?
     
Thanks!
Ella
-----------------------------------------------------------------------------
  Ella P. Gardner
  The MITRE Corporation
  +1 703 883 5826
  +1 703 883 7142 fax
  [email-masked]
-----------------------------------------------------------------------------

------- Forwarded Message
     
mwunix.mitre.org (8.6.10/8.6.4) with SMTP id PAA07853 for 
<[email-masked]>; Thu, 9 Mar 1995 15:28:41 -0500
>From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: OIW/XAPIA Directory Synchronization Paper 
Date: Thu, 09 Mar 95 11:02:18 +0000

     
Ella, I have a quick question on the XAPIA Directory Synchronization 
Specification: Why were the TotalRefresh and IncrementalRefresh 
datatypes changed from standard DISP?
     
This seems like a bad mistake to make because it means that implemetors 
have to implement yet another set of encoders/decoders. It would have 
been far better to use the standard datatypes and state that the
components that are not required should be omitted or have standard values.
     
For example, in TotalRefresh, SDSEContent in the standard protocol 
has been replaced with SET OF Attribute. It would have been better to 
state that 
   a) encoders always
 1) encode sDSEType with no bits set to 1 
 2) omit subComplete
 3) omit attComplete
   b) decoders always
 i) ignore sDSEType
 ii) ignore subCOmplete
 iii) ignore attComplete
     
- --Nick 
     
------- End of Forwarded Message

From: "Bor, Alexis" <[email-masked]>
To: dssig <[email-masked]>, Kirpal Khalsa <[email-masked]>, xapia-dirsynch <[email-masked]>
Subject: RE: Need comments on Dir Sync Spec this month
Date: Tue, 14 Mar 95 07:27:00 PST
Encoding: 54 TEXT

I am collecting all the comments and will build a single summarized   
posting of the comments.  At that point, I will solicit any necessary   
text changes to the spec and we will update it.

In any of your comments to the spec, it would be extremely helpful if you   
could propose the wording changes to the spec as well.  This will help   
speed the process.

Thanks a lot...

Alexis

 ----------
From:  Kirpal Khalsa
Sent:  Monday, March 13, 1995 8:44AM
To:  Bor, Alexis; dssig; xapia-dirsynch
Subject:  Re: Need comments on Dir Sync Spec this month

     Alexis,

     Are comments being posted somewhere?
     How are they getting rolled into the document?

     Regards,
        Kirpal

______________________________ Reply Separator
_________________________________
Subject: Need comments on Dir Sync Spec this month
Author:  "Bor, Alexis" <[email-masked]> at internet-mail
Date:    3/13/95 7:49 AM

       

Everyone,
The XAPIA is in the middle of balloting on the Dir Sync spec.  I need
feedback and/or suggested text changes before the end of the month to   
  make
sure that they make it into the spec.  So far I have seen comments   from   

Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of
Nexor.

Thanks.

Alexis Bor
[email-masked]

X400-Received: by /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 14 Mar 1995 09:51:41 +0000
X400-Received: by mta lancaster.nexor.co.uk in /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 14 Mar 1995 09:51:41 +0000
Date: Tue, 14 Mar 1995 09:51:41 +0000
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=NEXOR/ADMD= /C=GB/;lancaster.ne:108801:950314095140]
Content-Identifier: Re: OIW/XAPIA Di
From: Neil Cook <[email-masked]>
To: epg <[email-masked]>
Cc: xapia-dirsynch <[email-masked]>, dssig <[email-masked]>, epg <[email-masked]>
Subject:  Re: OIW/XAPIA Directory Synchronization Paper

In your message you said:

> Folks:
> 
> Will someone who  has been participating in the directory Synchronization
> work please answer Nick's question?
> 

<Header deleted>

> Ella, I have a quick question on the XAPIA Directory Synchronization
> Specification: Why were the TotalRefresh and IncrementalRefresh
> datatypes changed from standard DISP?
> 
> This seems like a bad mistake to make because it means that implemetors
> have to implement yet another set of encoders/decoders. It would have

I don't really think this is an issue. It took me about 1/2 a day to do this.
More annoying is the fact that it *does* use some DISP data types, and thus
you end up mixing and matching the two. This lead to me changing the names
of the data types which had the same name as in X.525, but were
different. Surely it would be better to rename them,
e.g. XapiaTotalRefresh. This at least would clarify things.

> been far better to use the standard datatypes and state that the
> components that are not required should be omitted or have standard values.
> 
> For example, in TotalRefresh, SDSEContent in the standard protocol
> has been replaced with SET OF Attribute. It would have been better to
> state that 
>    a) encoders always
> 	1) encode sDSEType with no bits set to 1
> 	2) omit subComplete
> 	3) omit attComplete
>    b) decoders always
> 	i) ignore sDSEType
> 	ii) ignore subCOmplete
> 	iii) ignore attComplete

The point is that, even though they are omitted in the XAPIA format,
if you actually want to send the information over DISP, you have to
perform the exact steps above, i.e. fill in sensible defaults for
sDSEType, subcomplete etc. This is particularly difficult for the area
prefix information.

Also, I am extremely unhappy with the way that contextPrefix has been
shoved into the spec, seemingly on a whim. We have implemented xapia
0.6, and we used a separate shadowing agreement file to specify all
the parameters such as where the info will be loaded into the DIT,
which DSA to contact etc. Using contextPrefix in this way is extremely
heavy handed, and a bit of a bodge. It only allows you to load the
info directly under the contextPrefix, which is unsatisfactory. What
if you wanted to load the info at a point further below the
contextPrefix? If you only have the contextPrefix to separate between
area prefix and area information, this is not possible.

Also, a question which has been bugging me is this; are mail programs
such as CCMail etc. expected to produce XAPIA files? Having them know
about the area prefix info, and having to fill in the xapia informaion
for this seems somewhat... ambitious. The question is; should the
xapia file contain area prefix info at all? This limits the file's
scope to a certain place in the DIT, and places a burden on the
creator of the file to have detailed knowledge about where the file is
going to be placed.

If I have misunderstood any of this, then feel free to correct me, but
from my experience, these are important issues. If the effort of
creating XAPIA files is too much, will people bother with them? We
have defined a text-format file whiich we use in a similar way to
xapia's intended use. We find it much more flexible, because it
contains no area prefix info - this is filled in with sensible
defaults by the loader. This seems to be a much more sensible and
flexible approach. It really seems that XAPIA was simply copied from
DISP, and only afterwards was much thought put into seeing where it
was deficient.

We have implemented xapia 0.6 for example, and found that the hardest
part was generating files that we could use. They contain so much
context specific info, that it is impossible to reuse a file
containing e.g. employee telephone numbers. That is why we developed a
text format, in conjunction with an agreement file. The agreement file
can change, but you can reuse the information in the text file. Maybe
an automatic text-xapia converter would be useful?

Neil.

Date: Mon, 13 Mar 95 08:29:48 pst
From: "Kirpal Khalsa" <[email-masked]>
Encoding: 27 Text
To: [email-masked], [email-masked], "Bor, Alexis" <[email-masked]>
Subject: Re: Need comments on Dir Sync Spec this month

     Alexis,
     
     Are comments being posted somewhere?
     How are they getting rolled into the document?
     
     Regards,
        Kirpal

______________________________ Reply Separator _________________________________
Subject: Need comments on Dir Sync Spec this month
Author:  "Bor, Alexis" <[email-masked]> at internet-mail
Date:    3/13/95 7:49 AM

     
Everyone,
The XAPIA is in the middle of balloting on the Dir Sync spec.  I need   
feedback and/or suggested text changes before the end of the month to   make 
sure that they make it into the spec.  So far I have seen comments   from 
Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of   
Nexor.
     
Thanks.
     
Alexis Bor
[email-masked]

From: "Bor, Alexis" <[email-masked]>
To: 'dssig' <[email-masked]>, 'xapia-dirsynch' <[email-masked]>
Subject: Need comments on Dir Sync Spec this month
Date: Mon, 13 Mar 95 07:05:00 PST
Encoding: 12 TEXT

Everyone,
The XAPIA is in the middle of balloting on the Dir Sync spec.  I need   
feedback and/or suggested text changes before the end of the month to   
make sure that they make it into the spec.  So far I have seen comments   
from Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of   
Nexor.

Thanks.

Alexis Bor
[email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: OIW/XAPIA Directory Synchronization Paper
Date: Mon, 13 Mar 95 08:35:28 -0500

Folks:

Will someone who  has been participating in the directory Synchronization
work please answer Nick's question?

Thanks!
Ella
-----------------------------------------------------------------------------
  Ella P. Gardner
  The MITRE Corporation
  +1 703 883 5826
  +1 703 883 7142 fax
  [email-masked]
-----------------------------------------------------------------------------

------- Forwarded Message

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: OIW/XAPIA Directory Synchronization Paper 
Date: Thu, 09 Mar 95 11:02:18 +0000

Ella, I have a quick question on the XAPIA Directory Synchronization
Specification: Why were the TotalRefresh and IncrementalRefresh
datatypes changed from standard DISP?

This seems like a bad mistake to make because it means that implemetors
have to implement yet another set of encoders/decoders. It would have
been far better to use the standard datatypes and state that the
components that are not required should be omitted or have standard values.

For example, in TotalRefresh, SDSEContent in the standard protocol
has been replaced with SET OF Attribute. It would have been better to
state that 
   a) encoders always
	1) encode sDSEType with no bits set to 1
	2) omit subComplete
	3) omit attComplete
   b) decoders always
	i) ignore sDSEType
	ii) ignore subCOmplete
	iii) ignore attComplete

- --Nick 

------- End of Forwarded Message