> >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.
>
> How else would you indicate that the "binary" encoding was
> requested/used instead of the "string" encoding?
RFC 2252, 6.5 says that ".. values in this syntax MUST only be transferred using the binary encoding ..". Also, no other encoding is provided therefore only the binary encoding can be used. Although 4.3.1 lists two reasons to use the binary encoding, it does not say that other valid reasons or syntaxes cannot require the use of the binary encoding.
Since the use of ";binary" is not mandatory for the Certificate syntax, and there is no other possible encoding, then the default encoding that is used (that must be used) is the binary encoding. If the ";binary" option is used to explicitly specify the binary encoding, this results in the same encodings and this would also satisfy the RFC.
> >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.
>
> You are right in that the RFC does not explicit state this.
>
> But it should be obvious that "CN;binary" should not be
> returned unless "CN;binary" was requested. Same goes
> for userCertificate.
>
Attributes must be returned according to their syntax encoding requirements. The Certificate syntax requires the encoding to be the binary encoding; in this case, the use of ";binary" is a red herring.
Chris.