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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Feb 2002 10:20:25 -0800

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.

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
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).

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.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Feb 2002 10:49:58 -0800

At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote:
>Additionally, client

I mispoke.  The ambiguity I refer to above doesn't
does apply in the certificate case as the existing
specification mandates use of ;binary for certificate
syntaxes.  Hence, this warning would not be needed.

My apologies for any confusion caused by my error.

Kurt