[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: clarification: ;binary



At 03:14 PM 6/7/00 -0400, Christopher Oliva wrote:
>
>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

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

>2) It is used to transport values where the only known/possible syntax is a
>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.

>3) It can optionally be used to transport values that have the "Binary"
>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
>bytes that is not UTF8).

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

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

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.

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

Yes.  We RFC 2252, 4.3 for clarification.