I don't believe the suggestion was to eliminate ";binary". I won't speak for David but I believe the suggestion is to make the default encoding for Certificate, Certificate List and Certificate Pair the BER encoding. This means that it would not be necessary to use ";binary" but if it were used, everything will work as expected.
I'm glad you mentioned backwards compatibility because this change would enable compatibility with ldapv2 and RFC 2559. When ldapv3 was deployed many systems that were already deployed became broken because of the stringent ";binary" requirement. So in order to truly fix backwards compatibility, the ";binary" rules must be relaxed.
This proposed fix would only apply to servers (not clients) and increase interoperability as well as backwards compatibility.
Chris.
-----Original Message-----
From: mcs@netscape.com [mailto:mcs@netscape.com]
Sent: Tuesday, February 19, 2002 1:30 PM
To: David Chadwick
Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS
Subject: Re: Private email re LDAP and ;binary
David Chadwick wrote:
>
>>The only argument for insisting on the mandatory ";binary" is the
>>possibility that the old RFC 1778 string formats will be presented in
>>a response. However, those old RFC 1778 syntaxes were updated by RFC
>>2559.
>>
>>
>
> Yes, I guess you are correct. The ;binary was really a hack job to cater
> for the broken string encoding of certificates. I dont really see why we
> need to use it now, if the PKIX document states specifically what the
> LDAP transfer syntax is, we should just be able to just simply ask for
> certificates (without ;binary) and get BER back. Since BER is the only
> recognised syntax in the latest specification.
Do you care about backwards compatibility? Any change to the on-the-wire
protocol for retrieving certificates over LDAPv3 makes me nervous. The
entire installed base of LDAPv3 servers and clients uses an
AttributeDescription of userCertificate;binary, as mandated by RFC 2252.
Now you are suggesting that we change all clients and servers to use
userCertificate. What value does such a change really have? Why propose
such a change when it will very likely break some existing implementations?
-Mark Smith
Netscape