Subject: Protocol: Rolling in recent updates

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Dec 2003 20:17:18 -0700

Since [Protocol] will be recycled, do we want to roll in some of the
recent additions? I'm thinking specifically of intermediate extended
operations.
 
Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Dec 2003 11:22:02 -0800

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
change this.

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-zeilenga-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
rolled in.

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].

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 16 Dec 2003 20:03:36 +0100

>   into [Syntaxes].  Work here is minimal.

Work on implementation is not minimal.

[Syntaxes] 4.1 (General Considerations) says:

   Servers SHOULD implement all the matching rules in Section 4.2.

SHOULD they implement the new matching rules too?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Dec 2003 12:05:00 -0800

>Work on implementation is not minimal.

I meant LDAP work, not implementor work.  Assuming we
don't change the elective status of the features we
roll in, the impact to implementors is the same:
        Those who choose to implement do.
        Those who choose to implement don't.

>SHOULD they implement the new matching rules too?

I'd like to see most be SHOULD implement, but think it
reasonable that some being MAY implement.  I'd even be
fine with all being SHOULD or MAY.  I recommend:

  SHOULD     booleanMatch
  SHOULD     caseExactMatch
  SHOULD     caseExactOrderingMatch
  SHOULD     caseExactSubstringsMatch
  SHOULD     caseIgnoreListSubstringsMatch
  SHOULD     directoryStringFirstComponentMatch
  SHOULD     integerOrderingMatch
  MAY        keywordMatch
  SHOULD     numericStringOrderingMatch
  SHOULD     octetStringOrderingMatch 
  MAY        storedPrefixMatch
  MAY        wordMatch

Kurt