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.

---

From: Peter Bachman <[email-masked]>
Date: Tue, 09 Apr 2002 15:57:58 -0400

>    encoding of a value is transferred in the protocol.

Nicely put.

Perhaps there is a scoping problem with the requirements, and ;binary is 
either a good candidate to act as a proxy for those more general 
transfer requirements, or is a special use case which can't be neatly 
generalized to the other issues in the state machine, and thus could be 
disposed with in a specific fashion.

This would relate to Fantou's comment that there is "no choice with 
attributes like certificates", which to me would indicate that decision 
to encode in a particular way has dependencies outside the scope of the 
protocol, one of which is accepted practice.

If the following snnipet from RFC 2251 is true, then the core 
requirement or value behind ;options is not to facilitate 
interoperability, but to allow for flexibility, where agreement may not 
be forthcoming, with the understanding that community of "conforming" 
participants may need to negotiate for their own compatibility.

 > Any option could be associated with any AttributeType, although not
 >    all combinations may be supported by a server.

This of course adds to potential network overhead for negotiation by the 
implementors. If something breaks, which I remember happening with PPP 
and C023, the recourse is to go back to the state machine, and see what 
required message was not sent or replied to. But as Kurt said, is it 
required? There is a brokenness that comes from failing to ack, a 
brokeness that comes from making a requirement that does not belong, but 
a brokeness that comes from not implementing to an actual valid 
requirement is a change management issue.

If the client can probe the server with * and get back the actual 
supported AttributeTypes, why can't it decide what to do? What am
I missing here? A defined "example" for an "option" would have to get
some legs to be a requirement.

-pb