Re: More on ;binary

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

At 02:23 PM 2002-03-01, Jim Sermersheim wrote:
>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..."

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.

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

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
>start diverging in terms of what is to be encoded when ;binary is not
>specified (or if it's just illegal).

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

>It seems more flexible to me to allow many encodings, and distinguish a
>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