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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I don't understand this business about two transfer syntaxes. Certificate is
to be given a native encoding which is, basically, the certificate.

If you request "certificate", you get a binary blob which is the
certificate.

If you request "certificate;binary", you get the same thing!

As regards compatibility, if a client requests "certificate;binary", the
server returns "certificate;binary". If a client requests "certificate" (and
no current conforming client will), the server returns "certificate".

Seems self-correcting to me!

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, 22 February 2002 5:20
To: Christopher Oliva
Cc: 'mcs@netscape.com'; Ramsay, Ron; Christopher Oliva; LDAP BIS
Subject: RE: ;binary and userCertificate (Was: Private email ...)


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