There are also some products that do not implement ";binary" as per the current RFCs.
The problem is that there are several different interpretations of ";binary" which affects product interoperability.
Some products require ";binary", some don't; some work either way. Sometimes searches will fail or succeed depending on the presence or absence of ";binary" in the search filter. Sometimes the use of ";binary" is required in ldapv2, sometimes it isn't. So one can allow configurations based on this behaviour but when attempting to process referrals from one product to another, the problem becomes almost insurmountable.
The conclusion is that experience has shown that there is considerable difficulty in implementing this protocol feature of ldapv3. This is enough of a problem to warrant a solution in the specifications. In my opinion, a solution should be drafted that allows products to function without using ";binary" yet is still compatible with products that do use it as per the original ldapv3 RFCs.
The solution is to modify the syntax ID (and later, whichever ID will define the listed syntaxes) and state that the default encoding for Certificate, Certificate List and Certificate Pair is the binary BER encoding and ;binary is not necessary.
A slightly amended version of what I proposed below could be:
The ID should state that values for Certificate, Certificate List and Certificate Pair are transferred as binary encoded BER values by default and therefore the ";binary" option is not necessary in protocol client messages. However, the ";binary" option can be included in attribute descriptions within client messages - a server MUST treat an attribute description with and without ";binary" as identical for these syntaxes. For example, "userCertificate" and "userCertificate;binary" would refer to the exact same set of values that would be encoded the same for protocol transfer. A server SHOULD include the ";binary" option in attribute descriptions within search responses.
For clients that absolutely must (or must not) have the ";binary" option in server messages, a control could be defined to toggle the server behaviour.
Chris.
-----Original Message-----
From: mcs@netscape.com [mailto:mcs@netscape.com]
Sent: Thursday, August 09, 2001 12:59 PM
To: Christopher Oliva
Cc: 'ldapbis'
Subject: Re: syntax ID and ;binary
> Christopher Oliva wrote:
>
> I think we need to change the usage of ;binary with respect to
> Certificate, Certificate List and Certificate Pair.
>
> I realize there is talk of moving the definition of these syntaxes out
> of the syntax ID and into a PKIX ID - I think these changes should be
> reflected in the syntax ID until that move is performed.
>
> Basically, I'd like to make use of ";binary" within the attribute
> description optional for these syntaxes. The ID should state that
> these values are transferred as binary encode BER values by default
> and therefore the ";binary" option is not necessary in protocol client
> and server messages. However, the ";binary" option can be included in
> attribute descriptions within the protocol - a server and client MUST
> treat an attribute description with and without ";binary" as identical
> for these syntaxes. For example, "userCertificate" and
> "userCertificate;binary" would refer to the exact same set of values
> that would be encoded the same for protocol transfer.
I disagree with your proposal. Some (many?) existing LDAPv3
implementations would fail to meet the revised specification. What
problem are you trying to solve by making this change?
--
Mark Smith
Directory Product Development / Netscape Communications Corp.
My words are my own, not my employer's. Got LDAP?