I don't believe there is agreement on your supposition that the 3 cases you have outlined are non conformant.
Here are some observations on the three cases:
a) and b)
RFC 2252 clause 6.5 only mandates a binary encoding. As previously pointed out by others, there is no absolute imperative that requires the use of the ";binary" option. The part referring to the userCertificiate;binary and caCertificate;binary are merely examples of how one could generate the binary encoding. If one were to include the use of the attribute descriptions as part of the absolute imperative, this would make it impossible to construct legal add and modify messages since this clause only allows the requesting and returning of attributes.
I'm sure you are referring to the "MUST NOT expect" clause of RFC 2251 clause 4.1.5.1. Nowhere does the RFC explain how to apply this clause to an implementation of the protocol specification (the precise impact of "MUST NOT expect" in an implementation is undefined). The query is legal and nothing prohibits the server from replying. If the intent had been to disallow this query, the specification would have said something like " ... if the client performs a query for an attribute by name without the ;binary option, the server MUST NOT return the value in the binary encoding."
c)
Nowhere in the ldapv3 RFCs is there a description of the behavior for this case. There is no justification to label this as non conformant.
Chris.
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, April 05, 2002 3:35 PM
To: David Chadwick
Cc: Mark Wahl; steven.legg@adacel.com.au; 'LDAP BIS'; 'PKIX'
Subject: Re: LDAP Certificate transfer syntax
I think adding a LDAP-specific "native" encoding to certificate
is a bad idea and will actually cause more problems than it
solves.
AFAIK, there are no interoperability problem between clients
and servers which adhere to the technical specification. Things
are basically okay.
This I-D attempts to resolve interoperability problems between
non-conforming implementations and conforming implementations
by altering the specification to require conforming implementations
to accept and support the syntax and semantics of non-conforming
implementations. However, there are a number of different
ways implementations have not conformed to the specification.
I have seen, in the wild, clients which:
a) request "userCertificate" and expect the return of
"userCertificate" using the (updated) LDAPv2 native
string encoding.
b) request "userCertificate" and expect the return of
"userCertificate;binary" using binary transfer.
c) request "*" and expect the return of
"userCertificate;binary" using binary transfer.
This I-D caters to case a) in a manner which disallows servers
from supporting case b) and c). I believe cases b) and c)
are actually for more common than case a). I know of
implemenations which are liberal in accepting b) or c). While
there may be implementations which are liberal in accepting
a), it should be noted that a) requires the server not to
be strict in what it sends.
I also note that b) and c) are generally the result of
the specification not be as clear as it should have been.
Where a) is the result of someone apply LDAPv2 syntax and
semantics to LDAPv3.
However, my objection to adding this I-D is that it that
client and server implementations of it won't interoperate
with existing server and client implementations which
conform to the existing specification.
I suggest we only make the minimal changes necessary to
resolve the issues which caused this schema to be removed
from the LDAP "core" technical specification. It was
removed become of normative reference issues (e.g.,
2nd v 3rd v ... edition of X.500) and to align the
schema with that provided by X.509 (e.g., matching rules).
I note that it was NOT removed because of lack of multiple
independently developed implementations. We need to
be careful to not to require changes to implementations
which have already demonstrated interoperability.
Kurt