Subject: Summary of [Models] issues from WG Last Call

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Feb 2003 14:22:48 -0800

Here is a list of issues raised and my (as editor) suggested resolution.

1) objectIdentifierMatch on ambiguous name
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00044.html

   Replace last paragraph of 1.3 with:
        While the <descr> form is generally preferred, the <numericoid>
        form should be used when an unambiguous short name (descriptor)
        is not available.  See Section 6.2 for additional discussion
        of Short Names (descriptors).

2) Naming Contexts (and Models: naming contexts and the root DSE)
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00053.html

   Replace first paragraph of 5.1.2 with:
    The 'namingContexts' attribute lists the context prefixes of the
    naming contexts the server masters or shadows (in part or in whole).
    If the server is a first-level DSA [X.501], it should list (in
    addition) an empty string (indicating the root of the DIT).
    If the server does not master or shadow any information (e.g. it
    is an LDAP gateway to a public X.500 directory) this attribute will
    be absent.  If the server believes it masters or shadows the
    entire directory, the attribute will have a single value, and
    that value will be the empty string (indicating the root of the
    DIT).  This attribute allows a client to choose suitable base
    objects for searching when it has contacted a server.

  and then noting in Changes the change to first-level DSA case.

3) Structural Object Class (and governingStructureRule)
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00055.html

   Request to LDAP descriptions of 'structuralObjectClass'
   and, subsequently, 'governingStructureRule' descriptions.
   Beyond scope.  No action.  (Note: author considers the lack
   of these descriptions a technical omission and will re-raise
   issue at a more appropriate time.)

4) Subclassing (attribute list inheritance)
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html

   It was requested that Section 2.4 be clarified as to
   effects of subclassing on MUST/MAY lists.  As Section 2.4
   already includes the statement
        As an entry of a class must meet the requirements of
       each class it belongs to, it can be said that an object
       class inherits the sets of allowed and required attributes
       from its superclasses.
   No action.

5) Subclassing (additional subclassing imperatives)
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html

  It was noted that Section 2.4.2 and 2.4.3 includes restrictions
  up subclassing not explicitly stated in X.501.  The author
  considers the lack of such statements in X.501 as a technical
  omission as such subclassing makes little sense.  No action.

6) aliases
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00075.html

  Clarification was requested regarding whether naming attributes
  of an alias entry must be present in the alias entry and, if so,
  what schema mechanism allows them to be present.  The following
  clarification and example are to be added:

7) preservation of user information
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00078.html
   A request was made to change the value preservation requirement
   to bit perfect.  The current requirement is believed to be
   technically sound and is supported by consensus.  No action.

8) unnecessary numericoids
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00080.html
   A request was made to change <numericoid> to <oid> in a
   number of productions as the <descr> form is already
   known.  The current approach is not "broken".  No action.

9) matching rule uses
   http://www.openldap.org/lists/ietf-ldapbis/200301/msg00083.html
   Request to add comment to 4.1.4.  Comment may confuse
   implementors.  No action.

10) Approx Matching rules
    http://www.openldap.org/lists/ietf-ldapbis/200301/msg00099.html
    Request to extend Attribute Types to include explicit
    specification of approximate matching rule.  X.500
    uses implication specification. No action.

11) Schema references to undefined entries
    http://www.openldap.org/lists/ietf-ldapbis/200301/msg00110.html
    Request to clarify whether published schema needs to be complete.
    Add to 4.2: "LDAP clients SHOULD NOT assume a published
    subschema is complete."

12) DIT Content Rules and AUX object classes
    http://www.openldap.org/lists/ietf-ldapbis/200301/msg00103.html
    Request to add support for a mechanism to specification
    of a DIT content rule to allow any auxiliary class.
    Beyond scope.  No action.

13) Change of Structural Object Class
    http://www.openldap.org/lists/ietf-ldapbis/200301/msg00111.html
    Request to remove statements considered redundant.  No action.

14) Subschema Semantics
    http://www.openldap.org/lists/ietf-ldapbis/200302/msg00008.html
    Request to change subschema semantics from "publish what
    you know" to "publish what you support".  Consensus believed
    to support current semantics.  No action.

Please let the WG know (within the next few days) if I've missed
any issue or if you disagree with the suggested action so that
Bob can declare consensus (or lack thereof).

Kurt (as Editor)

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 10 Feb 2003 15:04:10 -0800 (PST)

On Mon, 10 Feb 2003, Kurt D. Zeilenga wrote:

> Please let the WG know (within the next few days) if I've missed any
> issue or if you disagree with the suggested action so that Bob can
> declare consensus (or lack thereof).

Thanks, Kurt.

Note that I'm on vacation 2003-02-13 thru 2003-02-24, so any official
action on my part that doesn't happen in the next couple of days will have
to wait until after the 24th.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Feb 2003 15:08:50 -0800

>  clarification and example are to be added: 

        Every 'alias' object class must also belongs to object
        classes which allow suitable naming attributes to be
        present.  These object classes may be subclasses of
        'alias' or auxiliary classes (including 'extensibleObject').

        Example: 
        dn: cn=bar,dc=example,dc=com
        objectClass: top
        objectClass: alias
        objectClass: extensibleObject
        cn: bar
        aliasedObjectName: cn=foo,dc=example,dc=com

sorry, Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 11 Feb 2003 11:18:23 +1100

Kurt,

Kurt D. Zeilenga wrote:
>         present.

A more accurate wording would be:

	An entry with the 'alias' object class must also belong to
	an object class (or classes), or be governed by a content rule,
	which allows suitable naming attributes to be present.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 11 Feb 2003 08:45:51 -0800

>        which allows suitable naming attributes to be present.

This wording is much better than mine.  It should be used instead.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Feb 2003 11:30:22 +0100

Kurt D. Zeilenga writes:
> any issue

This one.  Couldn't find it in the archive:

>From: Hallvard B Furuseth <[email-masked]>
>Message-Id: <[email-masked]>
>Date: Mon, 10 Feb 2003 16:29:26 +0100
>Subject: Re: Models: Detail with Object Class Definitions
> 
>Kurt D. Zeilenga writes:
>>At 02:42 PM 1/30/2003, Hallvard B Furuseth wrote:
>>> I suggest the following addition to [Models] 4.1.1 (Object
>>> Class Definitions):
>>>
>>> "Note that the MUST and MAY lists may be modified by DIT
>>> Content Rules (see 4.1.6)."
>> 
>> I think that might actually lead to confusion as one might
>> think that the DIT content rule is "modifying" the object
>> class definition.  
> 
> True.  How about
> 
>    "Note that which attributes MAY and MUST be present in an
>    entry is also affected by DIT Content Rules (see 4.1.6)."

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 07:37:36 -0800

>>    entry is also affected by DIT Content Rules (see 4.1.6)."

I think that the statements in Section 2.4:
        - regulating, in conjunction with DIT content rule
        specifications, the attributes that are contained in entries;

and Section 2.4.2:
        - the structural object class of an entry is used, along
        with an associated DIT content rule, to control the content
        of an entry

and Section 4:
    c) DIT Content Rule definitions that extend the
    specification of allowable attributes for entries
    beyond those indicated by the structural object classes
    of the entries;

as well as those in Section 4.1.6 are quite sufficient.

Kurt