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:[email protected]]
Sent: Thursday, April 30, 2015 3:28 PM
To: Pofelski, Lech; [email protected]
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."
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
