;binary and userCertificate (Was: Private email ...)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

;binary has uses beyond those with certificates.  For
example, to request transfer of a DN in BER form instead
of RFC 2253 form.  IMO, an attribute of syntax DN would
serve as a better example of ;binary's "intended" use
(as described in Section 4.1.5.1 of RFC 2251).

It doesn't make much sense to return values in BER form
when the client has not explicitly requested it.  While
RFC 2251 stated: 
   Clients MUST NOT expect servers to return an attribute
   in binary format if the client requested that attribute
   by name without the binary option. 

This did not prevent, generally, a server from running any
attribute in binary format even though requested without
;binary.  Likely it was assumed to be obvious that a server
shouldn't return CN;binary unless it was asked to.  The
revised specification explicitly states that servers must
not use binary transfer when the attribute was requested
without ;binary.

As all attributes explicitly make use of binary transfer
state that values MUST be requested and transferred with
the ;binary option, the revised specification is self
consistent.

In regards to X.509 schema, one should not fix that which
is not broken.  The document should:
	a) indicate edition of X.500 recommendations used
	   is different from those used in LDAPv3 and diccuss
	   impacts of this difference,
	b) add missing matching rules, and
	c) state that values and their encoding forms
	   be preserved.

I see no reason to define a LDAPv3 native (octet)string encoding
for these syntaxes as ;binary works just fine.  Yes, there
may be broken LDAPv3 implementations, they should be fixed.

The fact that LDAPv2 uses a different mechanism is
inconsequential to this discussion.