[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Extension markers in ldap (was Re: I-D ACTION:draft-ietf-ldapbis-protocol-24.txt )
- To: Steven Legg <steven.legg@adacel.com.au>
- Subject: Extension markers in ldap (was Re: I-D ACTION:draft-ietf-ldapbis-protocol-24.txt )
- From: Simon Spero <ses@unc.edu>
- Date: Tue, 08 Jun 2004 19:31:35 -0400
- Cc: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>, ietf-ldapbis@OpenLDAP.org
- In-reply-to: <40ABF873.60804@adacel.com.au>
- References: <s0a9473a.050@sinclair.provo.novell.com> <40A9A2DB.1080606@adacel.com.au> <HBF.20040519erb1@bombur.uio.no> <40ABF873.60804@adacel.com.au>
- User-agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)
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