RE: AW: LDAP Certificate transfer syntax

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

Nicely summarised.

For myself (and did I hear others express the same opinion), ;binary is
redundant. I think Kurt likes to retrieve DAP-encoded DNs with it, but this
seems a bit non-LDAP. Regarding certificates, it is always clear what the
encoding is, so ;binary is unnecessary.

I liked your point about specification by example!

Ron.

-----Original Message-----
From: Peter Bachman [mailto:peterb@cequs.com]
Sent: Wednesday, 10 April 2002 5:58
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: AW: LDAP Certificate transfer syntax


Kurt D. Zeilenga wrote:
> At 10:44 AM 2002-04-09, Fantou Patrick wrote:
> 
>>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.
> 
> 

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