RE: clarification: ;binary

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

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.