Subject: Re: LDAPDN (WG last call on the Java API)

From: "Timothy Hahn" <[email-masked]>
Date: Tue, 27 Mar 2001 07:15:08 -0500

Kurt,

To some extent this discussion is related to an LDAPbis discussion on what 
attributes are "acceptable" for use in distinguished names.

While I agree that caseIgnoreMatch is sufficient for the set of attributes 
in the current "published table", I know of applications that already 
expect to use case-sensitive strings in naming attributes (i.e. allow 
entries under some container to have names that differ only in the 
upper/lower case of the characters in the naming attribute value).  Thus, 
I would suggest that at least:

caseExactMatch

be added to the set of matching rules (since we have foresight here).

Regarding the situation you note below with "ambiguities" in names and how 
to deal with them - it seems to me that the code could "bail" (i.e. throw 
some exception) if it encounters something that doesn't conform to RFC 
2253 - or is ambiguous based on RFC 2253.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"Kurt D. Zeilenga" <[email-masked]>
03/27/2001 01:00 AM

        To:     Rob Weltman <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: LDAPDN (WG last call on the Java API)

As I noted before and given your description of the normalization
function, I would very much like a method provided with this
capability.  Also, a syntax validation function might be useful
as well (though the normalization function could be used for this).

At 07:46 PM 3/26/01 -0800, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> Is there any specific set of matching rules an
>> API implementation must support?
>
>  We could refer to RFC 2252:
>
>"6. Syntaxes
>
>   Servers SHOULD recognize all the syntaxes described in this section."
>
>  There are 33 syntaxes listed there, many of them obscure and 
uninteresting at this point as naming attributes. I doubt there are many 
servers that support them all.
>
>  We could also add a MUST for the ones commonly used as naming 
attributes(Directory String, IA5 String, ...?), 

That sounds fine... that is, MUST attributes with directoryString
syntax with caseIgnoreMatch equality matching (that covers all
attributes in the published table in RFC 2253, Section 2.  Maybe
SHOULD IA5string with caseIgnoreIA5Match as well.

> but it is a little odd to specify that for a client API but not for a 
server.

I agree.

>> >> What if the comparison is Undefined?
>> >
>> >  What does that mean?
>> 
>> The implementation is unable to determine 'true'
>> vs. 'false' for any number of reasons... such
>> as not supporting a particular equality matching
>> rule needed to compare RDN values of each DN.
>> 
>> See X.501 for details.
>
>  What would you suggest? It can't be a common problem since we haven't 
run into it. But it's not a case of invalid input. Probably the best thing 
would be to throw UnsupportedOperationException (which is a 
RuntimeException).
>
>
>> How does the API determine whether a "+" in the input is part
>> of the value or a multiple-valued RDN separator?
>
>  In this and the other questions in this message about how to parse an 
RDN or DN, I don't think it is a good idea to specify it in this document. 
It is better to refer to RFC 2253 as the authoritative source on legal 
syntax for RDNs and DNs, including the escaping rules.

My point here is that RFC 2253 is useful if everything
is escaped... but if you unescape things you cannot
tell whether "cn=foo+sn=bar" is cn with a value of "foo+sn=bar"
OR cn with a value foo and sn of bar.

>> Which syntaxes is the API required to support BER decoding for?
>> Is the API required to support transliteration between T.61
>> and Unicode?
>
>  No, that was eliminated in the previous round of discussion on the 
ldapext list about the Java LDAP API. It now only supports UTF-8, not 
T.61.

I was noting that if you support BER encoded directoryStrings
one of the choices is TeletexString (T.61)....