LDAP Comments

[Eric Rosenquist <[e-mail]>]

Wengyik, Tim, Steve, and others:

I've just finished reading the January 1993 LDAP Internet-Draft and
have a few questions and comments.  My apologies if these have been
brought up before - I think SKL has an alias on the osi-ds list, but I
can't remember getting any messages from it so I can't be sure.

Comments & questions:

o  pg. 5: the 'invalidAttributeSyntax' error is listed twice, as values
   17 and 34.

o  Was it intentional that there be no "List" operation?  I suppose a
   DUA could use a "Search" instead, but as a DUA implementor I'd
   rather be able to issue a List operation when all I want is a list
   of subordinates.

o  pg. 9: I had to read the paragraph on search results a couple of
   times before I understood what you were trying to say.  On first
   reading I thought that the first '-' item ("Zero or more Search
   Responses... terminated by") was an incomplete sentence.
   Eventually I realized that the sequence is terminated by the second
   '-' item, but even still it doesn't read as well as it could.

o  Further on the Search Response topic... what is the reasoning behind
   returning a sequence of search responses rather than a single
   response containing multiple matching entries?  The only thing I
   could think of is that it might simplify the task of the LDAP
   server in handling referrals or unexplored/uncorrelated results.
   Given that the aim is to simplify the DUA implementation by
   offloading work to the LDAP server, why not have the LDAP server
   present a single response containing all of the search results?

o  What error is returned to a DUA if the LDAP server can't parse an
   LDAPDN, "invalidAttributeSyntax"?  In the case of a Mofify
   operation it would be hard for a DUA implementor to tell whether it
   was the object or one of the modifications that was at fault.

o  Given that a string may be returned with each result and that
   attribute types are passed around as names, it would be nice to
   have a language specifier in the Bind request.  This would allow
   the LDAP server to pick the appropriate language for any error
   strings it returns to the DUA, and could also be used to select the
   names used for attribute types.

   A French/German/etc DUA could get around the problem of having
   English attribute types by doing the translation itself internally
   I suppose, but it's not going to be able to automatically translate
   error text from the LDAP server.  Having an (optional maybe?) field
   in the BindRequest (an ISO 639.2 language code for example) would
   at least provide a means for the DUA to ask the server to use a
   particular language.  Whether or not it does is up to the LDAP
   server implementation.  Similarly it might be useful to be able to
   ask the LDAP server to always return object identifiers for
   attribute types, since they aren't affected by language.

o  Another language-specific problem that I can see is that LDAPDN and
   RelativeLDAPDN are both defined as IA5String.  This precludes
   non-IA5 characters from being used in distinguished attributes,
   even though X.500 itself has no such limitation.  I know for a fact
   that the Canadian government is particularly sensitive to the need
   for accented characters in names (try telling a deputy minister
   that their brand new state-of-the-art X.500 system can't handle the
   accented characters in their name), so a strict LDAP server/DUA
   combo would have some inherent limitations that would not sit well.

   I'm not sure what the best solution is, but given that we're
   assuming an 8-bit clean pipe between the DUA and LDAP server
   anyway, why can't we at least use an 8 bit character set like
   ISO8859?  Better yet, allow this to be negotiated between the DUA
   and LDAP server in the BindRequest/BindResponse, with IA5 stated as
   the default and a minimum requirement.

That's it for now!

Eric
-- 
Eric Rosenquist - Software Kinetics Limited          __ __
65 Iber Road, Stittsville Ontario Canada, K2S 1E7   / // /
Tel: [phone], Fax: [phone]            \ \\_\
email: [e-mail]                    /_/