Re: LDAP Comments

[Tim Howes <[e-mail]>]

> From:    [e-mail] (Eric Rosenquist)
> To:      [e-mail]

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

This is an error.  The second invalidAttributeSyntax should really be
invalidDNSyntax.  I will fix this.

> 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.

It was intentional to leave out both list and read.  These are trivially
implemented using search and leaving them out simplifies the protocol.

> 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.

I am reluctant to change the text, so I'm inclined to say that as
long as you were able to understand it eventually, it's ok as is! :-)

> 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?

Several reasons.  1) It allows clients to have smaller memory requirements
(buffer space).  2) It allows clients to easily cancel part way through
retrieving a lot of search results.  3) It allows "streaming" to be done
(i.e. start sending search results before all of them have been collected).

> 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.

The DUA should return "invalidDNSyntax", as described above.

> 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.

This would add complexity to the protocol, for very little benefit.
The text error messages are not essential to the protocol and are
provided primarily as a "debugging" aid.  Adding multi-language
support there just doesn't seem worth it to me.

> 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.

The LDAP DN format does not preclude using any characters in RDNs.  The
DN format document LDAP references explains how other attributes (including
non-string attributes) are represented.  The representation may not be
pretty, but the thrust of LDAP is simple access for 90% of the applications
out there.  It does allow everything to be represented, and most of it
even looks nice!

Thanks for your comments.  I'll make the change I mentioned above (along
with adding a reference or two that came up earlier) and resubmit to the
RFC editor.                                                    -- Tim