Re: More on ;binary

["Jim Sermersheim" <JIMSE@novell.com>]

I guess I've been thinking that 'native' meant 'default', and that when
no transfer options are specified, the 'native/default' encoding is
used. If it comes down that this is wrong, I'll try to clarify where I
can (also should be clarified in [Syntaxes] and [Models]).

Jim

>>> "Jim Sermersheim" <JIMSE@novell.com> 03/01/02 03:23PM >>>
I don't think that the text 
"  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]."

says anything at all about whether or not binary is *needed* to
specify
BER encoded ASN.1 during transfer. Only that it *can* be used to
"override any string-based encoding..."

I'm not sure that the WG *really* agreed to swap "string-based" for
"native". But I could be wrong. I suppose it means that syntaxes may
be
defined with _no_ native encoding. And I believe this is where people
start diverging in terms of what is to be encoded when ;binary is not
specified (or if it's just illegal).

It seems more flexible to me to allow many encodings, and distinguish
a
single encoding as native.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 03/01/02 03:07PM >>>
[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