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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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