I am restricting my comments to the Certificate, Certificate List and Certificate Pair syntaxes. Other functionality for other syntaxes do not apply and no changes are needed as far as I am concerned.
Comments in-line below.
> 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.
If the Certificate (etc.) syntax is changed so that the native encoding is the BER encoding, then the quote from RFC 2251 above does not apply. I believe the above statement applies to attributes whose native syntax is not BER encoding. Clients that are not aware of the native encoding will continue to request certificates with the ";binary" transfer option.
> 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.
>
The proposed change is not to alter the binary transfer syntax for certificates. Instead the native encoding of certificates will change to be BER encoding therefore the above statement about the binary transfer mechanism does not apply since the transfer of the native encoding will be BER. The fact that the native BER encoding for a certificate and the encoding used for the ";binary" transfer option are the same is inconsequential.
> 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.
>
In reality there are serious interoperability and backwards compatibility problems. Vendors have not been able to implement the strict interpretations of ";binary". The proposed solution is clean, simple and preserves interoperability in all cases.
I don't think we can simply choose to ignore interoperability and backwards compatibility.
I have still not seen a compelling reason to enforce the strict ";binary" interpretation. On the other hand, there are many compelling reasons to adopt the proposed change.
Chris.