Subject: Re: More on ;binary

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

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 >>>
[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: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Mar 2002 15:21:59 -0800

>"override any string-based encoding..."

But there is no other mechanism to override the "native"
(string-based) encoding.  An implementation which used
the provided a binary encoding of an value while not
indicating it was binary by in the associated attribute
description is broken.  That is, binary encoding is
used ONLY when the ;binary transfer option has been
indicated. They are tied together.

Likewise, in absence of any transfer option, the "native"
string encoding is used.

>defined with _no_ native encoding.

Exactly, as RFC 2252 did for a number of syntaxes when it
said "no string representation is defined" (a representation
is an encoding).

>And I believe this is where people

I think we need to make it exceedingly clear that ;binary
indicates binary transfer and binary transfer can only
be used where indicated.

>single encoding as native.

I think we can allow multiple encodings where one is
distinguished by the lack of any transfer option (the
"native") and others are distinguished by a transfer
option (such as "binary").

Now, I think where the confusion comes in is when
a client requests the native encoding, is it allowed
to get in return values in another encoding (as would
be indicated in the response by a presence of an
transfer option).  I argue no.

Consider a client which ask for "foo;bar" and gets back "foo;bar"
where it has no knowledge of what "bar" is.  How is the
client to treat "foo;bar"?  If we allow a server to use
non-native transfer encodings when not requested, then "bar"
could be a transfer option.  This means a client cannot do
anything with "foo;bar" unless it knows what "bar" is.  That's
bad.

Now, consider "binary".  A general purpose client which asks
for "foo" cannot be expected to be able to know that "foo;binary"
indicates an alternative encoding.  To it, it appears as
if ;binary is a tagging option!

Hence, for interoperability sake, I believe we need to
REQUIRE that servers only return values in the requested
transfer encoding.

Kurt