[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: More on ;binary
[for clarity, let me fix a couple of typos]
At 01:37 PM 2002-03-01, Jim Sermersheim wrote:
>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.
No.
>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?
In RFC 2251/2252, there were two distinct encodings possible for
any given syntax. These were referred to as the "string"
encoding and the "binary" encoding. Hence the distinction
in RFC 2251, 4.1.5.1:
If the "binary" option is present in an AttributeDescription,
it overrides any string-based encoding representation defined
for that attribute in [5]. Instead the attribute is to be
transferred as a binary value encoded using the Basic
Encoding Rules [11].
The WG determined that "string" encoding was not clear. Instead,
this is now referred to as the "native" encoding. It remains
distinct from the "binary" encoding.
The key here is that the presence or absence of the binary transfer
option does not change the syntax of the value, but the encoding
of the value. As we have two different encoding schemes, we need
two different terms to refer to them.
Kurt