It sounds like you agree with the whole concept but there are a few details to work out (like some strategically placed shoulds and mays). Correct me if I'm wrong.
comments below.
> At 08:37 AM 2002-02-21, Christopher Oliva wrote:
> >It still hasn't been made clear how the proposed change will
> have a negative impact.
>
> If there are two transfer mechanism, one should be a MUST,
> one should be a SHOULD or MAY.
>
> As one of the two would be not mandatory to implement,
> then implementations SHOULD NOT use the non-mandatory
> mechanism unless they have knowledge the peer supports
> it.
>
> Future implementations must be able to interoperate
> with existing conformant implementations. Existing
> conformant implementations should not be expected
> to be altered.
Yes and there are existing conformant implementations using RFC 2559. But the new requirements of the revised RFC 2251 will probably result in some existing implementations to change. Let me explain:
in RFC 2251, the original definition of attribute options said they should be treated like attribute subtypes. So, if you define a search filter like "userCertificate=*", by all rights, this should match any entry that contains a userCertificate value. According to the revised RFC 2251bis document, this functionality would no longer work.
>
> So, servers should be restricted to ;binary unless the
> the client explicitly requested the native string
> representation.
>
> A client would only request the native encoding if it
> knows the server supports it. A discovery mechanism
> would have to be provided. Additionally, client
I disagree. Existing client implementations that only use ";binary" would continue to work. Once a server supports the native encoding, the same clients would still continue to work. Clients that are only capable of requesting the native encoding have no choice therefore a discovery mechanism will not help them. This sounds more like a SHOULD requirement directed to the clients that states they should use ;binary - but they don't have to.
The point is: why would a client requesting the ;binary transfer suddenly try to switch to use the native encoding? Clients that only support the native encoding can't switch.
> developer's would have to be warned that some
> servers might use ;binary transfer even though
> the native string was requested. As this is a
> behavior which the existing specification allowed
> (due to an ambiguity in the specification which,
> I hope, will be removed).
>
See my above comment about ambiguity in the search filter.
> That is, a client MUST be prepared to interoperate
> with implementations which did not support the
> second transfer mechanism. The second transfer
> option, hence, should be a MAY.
>
> As a client would be prepared to interoperate with
> implementations which did not support the second
> transfer mechanism and the second transfer mechanism
> adds no functionality not offered by existing transfer
> mechanism, adding a second transfer mechanism is
> pointless.
>
> Adding pointless features does harm.
Are you suggesting this is pointless ? I disagree.
The ";binary" was never needed to work with certificates and the proof is that ldapv2 systems were deployed using RFC 2559 (standard) that did not use ";binary". So I ask you, what do you call a feature that is not necessary ?
Chris.