Subject: More on ;binary

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Mar 2002 12:57:38 -0700

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.

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.

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?

Jim

---

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

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

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

>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