Subject: Extension markers in ldap (was Re: I-D ACTION:draft-ietf-ldapbis-protocol-24.txt )

From: Simon Spero <[email-masked]>
Date: Tue, 08 Jun 2004 19:31:35 -0400

Steven Legg wrote:

> After intermediateResponse. The ellipsis is placed at the end of the 
> alternatives
> in the original base definition (which I would take to be the one in 
> RFC 2251).
> Each extension thereafter is appended to the end.

There's a problem with adding extension markers to the CHOICE, but we 
can get around it with the power of imagination.

RFC2251 doesn't have implicit extensibility on CHOICE - just SEQUENCE .
Making a CHOICE extensible changes the encoded form under the PER.
Even if the protocol version number were to be changed, it would be 
inside the bindRequest, which is  inside a protocolOp.

The easy way around this problem is to just  pretend that 
intermediateResponse and the extension marker were  in RFC2251 all the 
time; nobody noticed because the module was declared with IMPLICIT FNORDS.

Simon

---

From: Steven Legg <[email-masked]>
Date: Thu, 10 Jun 2004 10:13:10 +1000

Simon,

> Making a CHOICE extensible changes the encoded form under the PER.

Yes, though if the supposed implementation of LDAP in PER had assumed
implied extensibility everywhere (the case in X.500) then putting the
intermediateResponse after the extension marker would be backward
compatible for PER, while putting them the other way around would not be.

Putting the intermediateResponse after the extension marker is the
lesser of two evils. If nothing else, it alerts future extenders of the
protocol that the extension marker doesn't just go at the end, and that
its placement could have important consequences.

Regards,
Steven