Subject: AW: LDAP Certificate transfer syntax

From: Fantou Patrick <[email-masked]>
Date: Tue, 9 Apr 2002 17:44:17 +0200

Hi Kurt and Chris,
 
I am not sure this discussion really brings us further.

There is no choice with some attributes like certificates.

I fully support David´s proposal:
"The use of the ;binary encoding option, i.e. by
requesting or returning the attributes with descriptions
"userCertificate;binary" or "caCertificate;binary" has no effect on the
transfer syntax."

Patrick

> -----Ursprüngliche Nachricht-----
> Von: Kurt D. Zeilenga [mailto:[email-masked]]
> Gesendet: Dienstag, 9. April 2002 17:19
> An: Christopher Oliva
> Cc: David Chadwick; Mark Wahl; [email-masked]; 'LDAP BIS';
> 'PKIX'
> Betreff: RE: LDAP Certificate transfer syntax
> 
> 
> At 10:05 AM 2002-04-09, Christopher Oliva wrote:
> >> ;binary must be present when the binary encoding is transferred. 
> >> ;binary must not be present when the native encoding is 
> transferred. 
> >
> >Where is that stated in the RFC ? There are no such statements. 
> 
> It is implied by the language of RFC 2251.  When a protocol
> provides multiple possible transfer encodings for a particular
> value, the protocol needs to provide a clear indication of
> which transfer encoding is being used.  In LDAPv3, absence
> and presence of transfer options is used to indicate which
> transfer encoding is used. 
> 
> Kurt
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Apr 2002 11:17:10 -0500

>I am not sure this discussion really brings us further.

I think this discussion is bringing us further along.  It has,
at least, boiled down this particular debate to one issue:
   whether or not ;binary is required when the binary
   encoding of a value is transferred in the protocol.

>There is no choice with some attributes like certificates.

I would have to agree that this is no choice.  But I think
we disagree on what that choice is.

One must transfer certificates in their binary encoding as
indicates by ;binary.   Note only is this the intent of RFC
2251, but we have demonstrated interoperability between
multiple independently developed implementations of this.

Others have argued that RFC 2251 could be read otherwise.
That's a good reason for clarifying the specification.  It's
a lousy reason for making changes which would cause implementations
which interoperate today to fail to interoperate with
implementations of the future specification.

>"userCertificate;binary" or "caCertificate;binary" has no effect on the

Noted.