I agree in general to these statements. The next question from me to Bob then, is can I go ahead and merge draft-rharrison-ldap-intermediate-resp into [Protocol]?
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 12/12/03 12:22:02 PM >>>
At 07:17 PM 12/7/2003, Jim Sermersheim wrote:
>Since [Protocol] will be recycled, do we want to roll in some of the recent additions?
Well, I'd like answer this question with the "recycled" part.
The key here is that we're 'revising' the LDAP TS, not
'redesigning' it (except in limited areas such as string
preparation). The fact that we will be recycling doesn't
So, the question, to me is "can we consider recent IESG-approved
updates to the existing TS as part of the "core" specification?"
The short answer to this is, "yes".
However, as co-chair, I am reluctant to "roll in" updates
requiring significant amounts of work. We need to wrap things
up. However, given the nature of my involvement in these
RFC-to-be documents, I'll defer all further chair
responsibilities in this matter to Bob.
The following is my personal opinion as to what should or
shouldn't be rolled in:
draft-rharrison-ldap-intermediate-resp - yes As this adds an extension mechanism to the underlying
protocol and it desirable to include it in [Protocol]
so that it will more likely that LDAP libraries and
such will add support for it. I think it can easily
be rolled into [Protocol].
draft-zeilenga-ldap-features - yes
This adds an important discovery capability to LDAP and
can easily rolled into [Models].
draft-zeilenga-ldap-user-schema-mr - (mostly) yes
This document includes the "missing" from the
LDAP TS. Many of them should find there way
into [Syntaxes]. Work here is minimal.
draft-zeilenga-ldap-opattrs - no I view this as an independent extension (not an update
to the core TS) and hence suggest that it remain separately
specified (so that it can be progressed separately).
draft-zeilenga-ldap-subentry - no
Too much work to 'roll in'. Just reference it as needed.
draft-z! eilenga- ldap-collective - no Too much work to 'roll in'. Just reference it as needed.
The other recently approved LDAP documents (component
matching, LCUP, etc.) are, I believe, clearly independent
(from the "core") extensions and hence should not be
Additionally, I think the following existing things I would
like to see rolled in (and can easily be rolled in):
structuralObjectClass from X.5xx into [Models].
governingStructureRule from X.5xx into [Models].
dcObject from RFC 2247 into [Schema].
uidObject from RFC 2377 into [Schema].