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

[Rob Weltman <robw@coscend.com>]

"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, ...?), but it is a little odd to specify that for a client API but not for a server.

 
> >> What are the normalization requirements?  Depending on what
> >> this normalization function, it might be useful to expose an
> >> normalizer method so that callers might make use of it.
> >
> >  As in RFC 2253:
> >
> >   "Implementations MUST allow for space (' ' ASCII 32) characters to be
> >   present between name-component and ',', between attributeTypeAndValue
> >   and '+', between attributeType and '=', and between '=' and
> >   attributeValue.  These space characters are ignored when parsing."
> 
> I note that this is in section 4 which has limited applicability.
> Section 3:
>    Server implementations parsing a DN string generated by an
>    LDAPv2 client MUST also accept (and ignore) the variants
>    given in section 4 of this document.
> 
> If you require implementations to support such normalization,
> I suggest you note a specific requirement otherwise some
> implementation may find DNs containing extra (LDAPish) spaces
> as being invalid.

  OK, normalization means (in this case) the removal of extra space in the positions defined in RFC 2253 above. An implementation of the API MUST do this.

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


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

Rob