Subject: RE: XAPIA Directory Synchronization Recommendation
From: [email-masked] (Bruce Greenblatt)
To: [email-masked]
Date: Fri, 23 Jun 95 10:19:18 PDT

Alexis,
 
Thanks for your fast response to my comments of last week.  I'm 
certainly glad to see that we will at least see Unicode as an
option.  I didn't really follow all of the arguments against
using DISP, or a DISPish protocol in a file, as the directory
synchronization standard.  Since there were some business reasons
for this compromise, does anyone out there wnat to announce release
dates for the support of this protocol in their products, or at 
least semi-commit to its near term support.  If not, then the business
reasons for the compromise are, in a nutshell, bogus.
 
Bruce

==============================================
   
Bruce Greenblatt              [email-masked]
Messaging Products Group      (408) 577-7688
Novell, Inc.                  Prodigy: GSWF67A
 
==============================================

From: "Bor, Alexis" <[email-masked]>
To: Bruce_Greenblatt <[email-masked]>, xapia-dirsynch <[email-masked]>
Cc: bgg <[email-masked]>, "ed.owens" <[email-masked]>, ed_reed <[email-masked]>, lebeck_sue <[email-masked]>
Subject: RE: XAPIA Directory Synchronization Recommendation
Date: Wed, 14 Jun 95 09:18:00 P
Encoding: 107 TEXT

Bruce,
Here are some replies to your comments.

1.  This is not DISP protocol.  If fact, this is just a flat file format   
specification.  We spent a lot of time working with the X.500 SIG at the   
OIW to see if DISP could be used.  There were both technical and business   
reasons that it was rejected.  The idea of the format is to allow any two   
disparate directory systems to exchange data.  There is no requirement   
that you have X.500 as one of your directories - and some vendors were   
very insistent on this, including Tandem, Lotus and HP.  Most people came   
to the consensus that a simple utility can be developed to handle this   
that would not require an update to their product.  This was very   
important.  To implement DISP is a significant technical challenge that   
many Email vendors did not have resources for.  It is also a lot of code   
for something that is considered an interim solution to help people   
migrate to a common directory service.

2.  We can easily add UNICODE support as one of the options.  This is a   
good idea.

3.  The format is flexible enough that it can support both.  It is really   
an issue for the two synchroniztion partners to determine local sync   
policies.  I expect that over time that these dir sync files will be sent   
with digital signature via an email and some message enabled application   
will process them.

I sent the latest 'balloting' draft to Ed a few weeks ago, but in my   
group we had a major mail burp and this may have been one of the messages   
that got lost.  I will add the optional UNICODE suggestion to the spec in   
the next day or so and resend it to Ed.

If anyone has any concerns about this one, please let me know ASAP.   
 Thanks.

Alexis Bor
Boeing Information & Support Services
[email-masked]
(206) 865-3631
(206) 865-6903 (FAX)
 ----------
From:  Bruce_Greenblatt
Sent:  Tuesday, June 13, 1995 4:03PM
To:  bora; xapia-dirsynch
Cc:  bgg; ed.owens; ed_reed; lebeck_sue
Subject:  XAPIA Directory Synchronization Recommendation

I've not yet seen the ballot for the directory synchronization
recommendation, but I have reviewed the latest copy that is available
and I have the following comments.  Note that (to me at least) the
comments are serious enough to warrant disapproval from Novell during
the ballotting (sp?).

So, here we go...

Here are some comments/reactions.

1) This isn't X.500 (1993) DISP.  Why not?  What's the rationale that
lead to the choice to develop a new protocol?  This may be covered in the   

archives of the working group, but it should be addressed directly in the   

specification itself.

2) In the definition DomainName ::= CHOICE {Printable String, T61String}   
 - it
is not acceptable to Novell for the CHOICE to not include Unicode as one   
of
the choices...  can be expressed as BMPString, or UniversalString with
subtype of the 16 bit characters from the Basic Multilingual Plan as
described
in ISO 10646.  FYI - BMPString == the 16 bit BMP of ISO 10646 == Unicode.   

This requirement should be placed on ALL string and distinguished name   
types.

Another way this might be addressed is by explicitly including Name and
other attributes from the 1993 versions of the X.500 InformationFramework   

module...that should satisfy our need to have Unicode String attributes
supported.

3) Novell's recommendation would be that only public readable attributes
be eligable for synchronization...unless some really trusted mechanism   
for
enforcing our ACL information (requiring that the extract file itself be
encrypted, I would think, to preclude unconstrained access to controlled
attributes being exchanged) is available in the foreign directory service
with which the exchange is being conducted.  I'd like to see the draft
discuss access control issues at more length...but would simply enforce
the rule that an extract process running against a directory like X.500   
or
NDS will only have access to attributes which are readable by the user
whose identity the process is running with.  Does this make sense?

 ==============================================

 Bruce Greenblatt              [email-masked]
 Messaging Products Group      (408) 577-7688
 Novell, Inc.                  Prodigy: GSWF67A

 ==============================================

Date: Tue, 13 Jun 95 16:03:41 PDT
From: [email-masked] (Bruce Greenblatt)
To: [email-masked], [email-masked]
Subject: XAPIA Directory Synchronization Recommendation
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

I've not yet seen the ballot for the directory synchronization 
recommendation, but I have reviewed the latest copy that is available
and I have the following comments.  Note that (to me at least) the
comments are serious enough to warrant disapproval from Novell during
the ballotting (sp?).

So, here we go...

Here are some comments/reactions.

1) This isn't X.500 (1993) DISP.  Why not?  What's the rationale that 
lead to the choice to develop a new protocol?  This may be covered in the 
archives of the working group, but it should be addressed directly in the 
specification itself.

2) In the definition DomainName ::= CHOICE {Printable String, T61String} - it 
is not acceptable to Novell for the CHOICE to not include Unicode as one of 
the choices...  can be expressed as BMPString, or UniversalString with 
subtype of the 16 bit characters from the Basic Multilingual Plan as described 
in ISO 10646.  FYI - BMPString == the 16 bit BMP of ISO 10646 == Unicode.  
This requirement should be placed on ALL string and distinguished name types.

Another way this might be addressed is by explicitly including Name and 
other attributes from the 1993 versions of the X.500 InformationFramework 
module...that should satisfy our need to have Unicode String attributes 
supported.

3) Novell's recommendation would be that only public readable attributes
be eligable for synchronization...unless some really trusted mechanism for
enforcing our ACL information (requiring that the extract file itself be
encrypted, I would think, to preclude unconstrained access to controlled
attributes being exchanged) is available in the foreign directory service
with which the exchange is being conducted.  I'd like to see the draft
discuss access control issues at more length...but would simply enforce 
the rule that an extract process running against a directory like X.500 or
NDS will only have access to attributes which are readable by the user
whose identity the process is running with.  Does this make sense?

 ==============================================
 
 Bruce Greenblatt              [email-masked]
 Messaging Products Group      (408) 577-7688
 Novell, Inc.                  Prodigy: GSWF67A
 
 ==============================================