So what is the correct behavior of an ldapv3 server when a client does a wildcard search for "all attributes" ?
Is the server supposed to include the userCertificate or omit it? In this case the client did not specify the binary transfer mechanism. So I guess the server should omit the attribute.
My argument here is that the current ldapv3 RFCs do not really say one way or another what should happen. Since there is no obvious reason to omit the certificate, an implementation may elect to include it. Since the only way to transfer the values is to use the binary encoding, then one might conclude a couple of things.
First, all syntaxes should have a native encoding so that all user attributes can be returned. This is an encoding that a client can expect.
Second, the default way to transmit certificates is to use the binary encoding. You can call this the certificate's implicit native encoding.
If you accept that a current implementation might behave this way, then wouldn't changing the specs break interoperability ? Or can interoperability be preserved simply by defining the native encoding for a certificate as the binary encoding.
Chris.
>
> Unfortunately, client implementors often don't take into account all
> the potential responses they can get. They usually do enough to make
> their client work with their preferred LDAP server and leave it at
> that. So even if we explicitly specify that servers are
> allowed to return
> ";binary" without it being requested, there will still be people
> implementing clients that don't expect it.
>