[Date Prev][Date Next]
Re: More on ;binary
Let me clarify:
As you say, all LDAP syntaxes have an ASN.1 definition. My point is,
that in the absence of any other encoding, the BER encoding of the ASN.1
definition is implicitly the "native" encoding.
I believe you will argue that this is not true. But this was my
understanding. It was with that foundation that I wrote the new text.
Can you point me to where we state that the native encoding is never the
BER encoding of the ASN.1 definition?
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 03/01/02 01:28PM >>>
At 11:57 AM 2002-03-01, Jim Sermersheim wrote:
>I'd like to add "Some syntaxes are only defined with an ASN.1 type
>no other native encoding is given. It is unnecessary to use the
>option for these syntaxes." to the end of the ;binary discription.
That would be a change in semantics which has, as you noted below,
bad side effects. (Liberties aside,) If a client asks for the
"native" string encoding and that encoding cannot be generated,
then the attribute description is to be treated as unrecognized.
>It strikes me though, that this sort of causes problems for any
>that is initially defined with only an ASN.1 type, and then later
>defined with a "native" string type.
You use of "type" here is confusing. I assume what you mean is
that a LDAP syntax (which always has an ASN.1 data definition)
previously had no "native" string encoding now has a "native"
Yes, that's one reason why clients MUST NOT expect ;binary when
;binary was requested.
>Or perhaps that kind of thing just isn't possible anyway. Once a
>is defined with only an ASN.1 type, the ASN.1 type MUST always remain
>the "native" type for encoding. Right?
Again, confusing use of "type". An LDAP Syntax (which always
has an ASN.1 data definition) can be defined without a "native"
string encoding. Later, a "native" string encoding could be
added by updating the specification of the LDAP syntax to
include one. For example, Steven and I doing this for subentry