Subject: Re: More on ;binary

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

[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

---

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

lol,

I pulled the offending text just before submitting.

>>> "Kurt D. Zeilenga" <[email-masked]> 03/01/02 02:53PM >>>
At 01:37 PM 2002-03-01, Jim Sermersheim wrote:
>Let me clarify:

After you submit!

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Mar 2002 15:40:35 -0700

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" <[email-masked]> 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" <[email-masked]> 03/01/02 03:07PM >>>

No.

Kurt