Re: Comments on draft-seilenga-lldap-cancel-00.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:58 PM 1/24/01 -0700, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/24/01 12:36:57 PM >>>
><snip>
>>In my view, this I-D proposes a change to the LDAP protocol
>>using one of the provided extension mechanism.  That is, the
>>changes are only visible when the extension is being used
>>by mutual agreement of both peer.  If an extension mechanism
>>was not used, I would argue the version would have to be
>>incremented.
>
>This may be a good philosophy, but before it's practiced in I-D's headed for standards track, I think this larger issue should be itself standardized.

Well, this I-D is certainly not the first I-D to require
amendments to the ASN.1.  There have been I-D published
suggesting new CHOICEs and/or ENUMERATION values.

I believe it a reasonable interpretation of RFC 2251 that
such is allowed.  I don't view anything in RFC 2251 as
restricting the scope of what extensions might be engineered.
Some extensions requires changes to the ASN.1.  As long
as these changes don't break interoperability with peers
which do not implement the extension, there is no problem.

One could argue that no changes to the ASN.1 is allowed as
no extensibility markers were provided.  If one were to take
this stand, the following types of extensions would be disallowed:
  - additional PDUs (e.g.: partialExtendedResponse)
  - additional authentication methods (these exist)
  - additional search scopes (forthcoming)
  - additional filter choices (extensibleMatching is
    not necessarily extensible enough)

But I note that 2251 failed to use extensibility markers even
where it explicitly stated extensibility is allowed.

I also note that disallowing additional result codes leads
to overloading of existing result codes.  This leads to
significant interoperability problems as it becomes unclear
as to which semantics were meant.

> This kind of thing can be seen by people to extend past the three ammendments you outlined.

I don't think you can stop folks from suggesting odd semantics.
Luckily, we have a fairly active review community which keeps
these from getting progressed on the standard track.

I don't this I-D will have much impact on what others may
or may not suggest otherwise.  A revision to RFC 2251 might
help (that's an LDAPbis issue).  A informational guide on
extension do's and don't might help (that's an LDAPext issue).