Hello Mr Chu,
[ I am resending this e-mail, because I forgot to use "ReplyToAll" in my first sending, so the e-mail was not sent to openldap-technical)]
Thanks for explanation. I have just the last question. As 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 " " It suggest that the legal form of RDN with BER encoding is:
<attribute type OID>=#<BER encoded value in form of hexstring>
However, according to the syntax the form:
<attribute type NAME>=#<BER encoded value in form of hexstring>
is also correct.
Should we also consider the form:
<attribute type NAME>=#<BER encoded value in form of hexstring>
as legal?
Sorry for asking for such a detail, but we want to avoid any misunderstanding in the patch preparation.
Regards,
Lech POFELSKI
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, April 30, 2015 3:28 PM To: Pofelski, Lech; openldap-technical@openldap.org Subject: Re: About RDN values starting with #
Pofelski, Lech wrote:
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?
The text is quite clear - the hexstring is of the BER encoding of the value. There is no ambiguity here.
"This form is also used when the AttributeValue does not have an LDAP-specific string encoding for it, or the LDAP-specific string encoding is not restricted to UTF-8 encoded Unicode characters."
"This form" refers to "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."
It does not allow the possibility of any other "form."