Hello Mr Chu,
Thanks for proposing us to submit a patch. We are starting to work on it.
There is still one point to clarify about two possible forms of RDNs with values starting with #.
The RFC4514 says:
"
If the AttributeType is of the dotted-decimal form, the
AttributeValue is represented by an number sign ('#' U+0023)
character followed by the hexadecimal encoding of each of the octets
of the BER encoding of the X.500 AttributeValue
"
This statement explains clearly, without any ambiguity the case when the RDN is of form:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, the RDN syntax definition presented in the same RFC allows also the form:
<attribute type NAME>=#<hexstring>
i.e. where the AttributeType is NOT and OID. This form has the <hexstring> value which does not seem to be explicitly restricted by any constraint, i.e. it is not necessarily a BER.
In brief, there may be two interpretations of this part of the RFC:
* A permissive one:
o In the form <attribute type NAME>=#<hexstring> any <hexstring> is allowed (implicitly, by syntax and not constrained)
o In the form <attribute type OID>=#<hexstring> only BER <hexstring> is allowed (explicitly, including examples)
* A restrictive one:
o in both cases (attribute type NAME / OID)=#<hexstring> - only BER <hexstring> is allowed
Note that in any case we consider only the attribute types having the syntax of Octet String, so as we discussed earlier we don't expect any pitfall issue described in (https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).
Between the two interpretations presented above our preferred choice is the permissive one, i.e. <attribute type NAME>=#<hex string>, with no constraint on the <hex string> value. Note that the restrictive interpretation seems to be more restrictive than the RFC itself.
Which interpretation would you recommend for our fix?