Subject: clarification: ;binary

From: Christopher Oliva <[email-masked]>
Date: Wed, 7 Jun 2000 15:14:44 -0400

I often have to explain this issue to people so I thought I would raise it
once again on the list and hope that it will get clarified in the updated
version of RFC 2251.

There are four common interpretations for the use of ";binary":

1) It is used to override the BNF string syntax of values by encoding them
in BER
2) It is used to transport values where the only known/possible syntax is a
complex ASN.1 syntax (i.e. attributeCertificate)
3) It can optionally be used to transport values that have the "Binary"
syntax (the values must be BER encoded).
4) It is used to transport values that are non-printable (i.e. a string of
bytes that is not UTF8).

As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
encoding of values must be used for case number 4. In other words, there are
cases where an attribute syntax is a non-printable string of bytes and the
use of ";binary" is not required. One example of this is the Octet String
syntax.

For example, if I have an attribute named "private" with an Octet String
syntax, I can transmit this in ldap with the attribute description "private"
and encoded as 2 bytes "FFFF". It is not necessary to transmit this with the
attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Chris.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 07 Jun 2000 14:17:08 -0700

>1) It is used to override the BNF string syntax of values by encoding them

This interpretation is close.  attribute descriptions with the
";binary" option are transferred using the BER encoding of their
syntax wrapped in an octetString.  Some attribute types must
be transferred using this mechanisms, others may (depending
upon implementation support).

>complex ASN.1 syntax (i.e. attributeCertificate)

No. ;binary may be used with any and all attribute types (assuming
server support) irregardless of whether a string syntax is available.

>syntax (the values must be BER encoded).

Yes, and this is generally recommended and in some cases required.

>4) It is used to transport values that are non-printable (i.e. a string of

No.  It's used to transfer BER encoded (per syntax) attribute values
(wrapped in an octetString).

>use of ";binary" is not required. One example of this is the Octet String

Correct.  The lack of ;binary does not imply that the value is
a printable string.  It's whatever the syntax defines as a
"string" representation.  That could be any old blob.

>attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Yes.  We RFC 2252, 4.3 for clarification.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 8 Jun 2000 11:39:51 +1000

I agree with 1), 2) and 3).

I think you are wrong on 4). In the case of jpegPhoto and audio, the string
of bytes is sent as an octet string without using ;binary.

In fact, I believe that LDAP requires there always be a displayable encoding
except where this would lead to corruption of the data (certificates, for
example) or where the syntax was audio or jpegPhoto. This may also include
octet string but I can't be sure.

;binary is used to override the string encoding. It is also used for
certificates but I think this is because certificates once had a string
encoding.

I agree that the statements in RFC 2252 could be clarified.

On that subject, would it be worth starting a list of things in LDAP that
need clarification. I know I have two issues:

1) It is not clear when 'operational' attributes should be specifically
requested to be returned in a search response. 'namingContexts' is
interesting in that it is defined as an operational attribute that can only
appear in the root DSE? 'ldapVersions' is not marked in this way? Mark Wahl
has suggested that all attributes in the root DSE should be returned as if
they are not operational, but I think this doesn't really clarify matters.

2) The extended response 'protocolError' MAY be returned. This is
unsatisfactory. I tried to return it to a previous version of MS ADSI. I
don't think it expect it. And this is the problem - if it is not a MUST then
clients needn't support it, so servers CANNOT use it.

Ron.

-----Original Message-----
From: Christopher Oliva [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 5:15
To: 'LDAP EXT'
Subject: clarification: ;binary

Chris.

---

From: Christopher Oliva <[email-masked]>
Date: Thu, 8 Jun 2000 11:55:06 -0400

In your response, you stated:

"In fact, I believe that LDAP requires there always be a displayable
encoding except ..." 

That is the misconception that leads to the confusion about ";binary" and
the transmission of values within the ldap protocol.

In fact, there is no requirement in RFC 2251 that states that attribute
values MUST be printable (or can be displayed). It does encourage this goal,
but states that some values may not be displayable. RFC 2252 gives audio as
an example.

You can generalize the use of ;binary to two cases:

Case (1):
It is the attribute syntax that determines whether the ";binary" mechanism
must be used, and not the actual value itself (before encoding for
transmission)i.e. the issue is not whether or not the value can be diplayed.
For example, the Certificate syntax requires the ";binary" mechanism but
Octet String does not and yet Octet String can be used to transmit either
printable or non-printable values. In the case where an Octet String syntax
is used to transmit a non-printable value, there is no need to use the
";binary" mechanism. The example I have is the Octet String value composed
of two non-printable bytes "FFFF". This is transferred as FFFF and does not
require the ;binary attribute option.

Case (2):
The user wishes to use the BER encoding of the data in order to override the
"regular" ldap representation. In this case, if you have the Octet String
value "FFFF", you can encode this as "0402FFFF" for transmission along with
the ;binary attribute option. (You're not really gaining much by doing this
for the Octet String syntax.) But it is important to note that this is not
required by ldap v3.

Chris.

-----Original Message-----
From: Ramsay, Ron [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 9:40 PM
To: Christopher Oliva; 'LDAP EXT'
Subject: RE: clarification: ;binary

Ron.

-----Original Message-----
From: Christopher Oliva [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 5:15
To: 'LDAP EXT'
Subject: clarification: ;binary

Chris.

---

From: [email-masked]
Date: Thu, 8 Jun 2000 15:58:51 -0400

O.K. I will bite.

I agree that the RFC 2252 section 4.3 requires clarification.  The text is way
open to misinterpretations and interoperability problems because of text like
"to the greatest extent possible" and "string encoding".

Maybe it's a hang up from LDAP V2 but when I see "string encoding" I
automaticaly think of something like base-64 etc. and further more the wording
sort of strongly encourages printable strings.  I agree it doesn't state that it
must be a printable string but it seems to me that the implication is that
internaly it can be treated using 'conventional' string operations such as
strcpy.  To me it seems to imply that if you can't handle the value as a
"string" then it should be flagged with the ";binary" option.

I would suggest thet "string encoding" be replaced by "Directory String" and the
ambiguity would pretty much go away.