RE: clarification: ;binary

[Christopher Oliva <Chris.Oliva@entrust.com>]

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:Ron.Ramsay@ca.com]
Sent: Wednesday, June 07, 2000 9:40 PM
To: Christopher Oliva; 'LDAP EXT'
Subject: RE: clarification: ;binary


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:Chris.Oliva@entrust.com]
Sent: Thursday, 8 June 2000 5:15
To: 'LDAP EXT'
Subject: clarification: ;binary



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.