Re: More on ;binary

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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