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

[Steven Legg <steven.legg@adacel.com.au>]

Simon,

Simon Spero wrote:
> 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.

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

> 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