Subject: Re: More on ;binary

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Mar 2002 14:37:08 -0700

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?

Jim 

>>> "Kurt D. Zeilenga" <[email-masked]> 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
and
>no other native encoding is given. It is unnecessary to use the
"binary"
>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
syntax
>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"
string encoding.

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
syntax
>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
attributes!

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Mar 2002 13:53:10 -0800

>Let me clarify:

After you submit!

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Mar 2002 14:01:47 -0800

>definition is implicitly the "native" encoding.

No.

>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 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