Subject: Re: subschema clarifications (Was: I-D ACTION:draft-ietf-ldapbis-models-01.txt)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 Jun 2002 08:57:50 -0700

At 08:57 PM 2002-05-31, Jim Sermersheim wrote:
>We would also have to state that an operational attribute cannot be
>added to the MUST or MAY list of any objectclass when it is known that
>the attribute has semantic meanings when paired with certain object
>classes (i.e. ref and referral).

Yes, an object class which MUST or MAYs an operational attribute
type is presumed to have operational semantics associated with it
and hence should not be published in the subschema unless the
server supports those semantics.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 3 Jun 2002 16:37:15 +1000

Kurt,

Kurt D. Zeilenga wrote:
> At 12:23 PM 2002-05-31, Timothy Hahn wrote:
> 
> >Kurt,
> >
> >I agree with you.
> >
> >I was thinking of things like "pwdPolicy" in
> >draft-behera-ldap-password-policy-05.txt where the schema 
> for that object
> >class is all userApplication, but the implication is that 
> the server is
> >going to do something with the information.
> 
> I think it can (and should be) argued that password policy
> attribute types should be defined as operational.

I agree.

> >I would like to see the general guidelines you noted below 
> (not allowing
> >non-userApplication attribute types to be added, only 
> syntaxes/matching
> >rules that are supported, and don't publish operational 
> attributes that
> >aren't supported) be further detailed and published.  
> Perhaps as a best
> >practice?
> 
> Well, I'm treating this as a 'core' technical specification.
> In draft-ietf-ldapbis-models, we need to either:
>   1) clarify subschema publication so that its useful for
>      capability discovery, or

From the perspective of the X.500 administration model, the subschema
subentry is a bad place to be advertising server capabilities.
A subschema administrative area can span multiple naming contexts, and
can also be partially or wholly replicated to other servers. The
capabilities of the server mastering the subschema subentry are not
necessarily the same as the capabilities of the other servers mastering
or shadowing other parts of the subschema administrative area to which
the subentry applies.

The root DSE is the most appropriate place to be putting information
about server capabilities.

>   2) state that it is not intended for server capability
>      discover (that is, intended only to provide schema
>      definitions to clients without indication of support).

I vote for 2.

Regards,
Steven

---

From: Ludovic Poitou <[email-masked]>
Date: Mon, 03 Jun 2002 10:27:07 +0200

Timothy Hahn wrote:

>draft-behera-ldap-password-policy-05.txt where the schema for that object
>class is all userApplication, but the implication is that the server is

One can consider the pwdPolicy objectclass as a Configuration entry that 
the server is using for himself. I don't think that all configuration 
entries of a directory server should only contain operational attributes 
because the server is using them.  Operational attributes are more 
attributes that the server is maintaining itself, ie a user does not 
control the values.

Typically, all attributes used to control and enforce the password 
policy in the draft-behera-ldap-password-policy-05.txt are defined as 
operational attributes.

Regards,

Ludovic.

>
>
>I would like to see the general guidelines you noted below (not allowing
>non-userApplication attribute types to be added, only syntaxes/matching
>rules that are supported, and don't publish operational attributes that
>aren't supported) be further detailed and published.  Perhaps as a best
>practice?
>
>Regards,
>Tim Hahn
>
>Internet: [email-masked]
>Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
>phone: 607.752.6388     tie-line: 8/852.6388
>fax: 607.752.3681
>
>
>
>                                                                                                                                       
>                      "Kurt D.                                                                                                         
>                      Zeilenga"                To:       Timothy Hahn/Endicott/IBM@IBMUS                                               
>                      <[email-masked]        cc:       [email-masked]                                                     
>                      g>                       Subject:  Re: subschema clarifications (Was: I-D                                        
>                                                ACTION:draft-ietf-ldapbis-models-01.txt)                                               
>                      05/31/2002 11:39                                                                                                 
>                      AM                                                                                                               
>                                                                                                                                       
>                                                                                                                                       
>
>
>
>At 06:43 AM 2002-05-31, Timothy Hahn wrote:
>
>>I think that this issue of "server capabilities" is becoming more and more
>>important.  I also think it extends beyond what schema elements are or
>>aren't supported by the server.
>>
>
>There certainly are server capabilities not directly associated
>with schema elements which the client might desire to discover
>support for (without resorting to trail and error).
>
>>I agree (in principle) with the notion that a server should not
>>include/advertise schema elements that it does not support all the
>>"semantics" of ... but this can get "dicey" in practice with deployments
>>adding schema elements (a server can't know what new schema elements MIGHT
>>be defined in the future that bring along other "semantic" requirements
>>
>...
>
>>thus a server would hard-pressed to disallow the schema elements from
>>
>being
>
>>added into the server's "advertised" schema.)
>>
>
>I think its fairly straight forward for a server to determine
>if there is an element specific semantic to be implemented and
>to disallow such from being added if it doesn't implement that
>semantic.  For example, any non-userApplication attribute type
>has, by definition, a semantic to be implemented.  And, of course,
>any ldapSyntax or matchingRule has a semantic to be implemented.
>
>In the latest version of OpenLDAP, we allow administrators to
>only add (using a non-LDAP mechanism) userApplication attributes
>and object class composed only of userApplication attributes.
>This keeps administrators from doing stupid things, like adding
>some not implemented operational attribute to the subschema (and
>then to entries).
>
>We also don't publish operational attribute types definitions
>we know of unless we support that operational attribute type.
>For example, our server knows the definition for ditContentRule,
>but we don't publish it because we don't implement it.
>
>>I would like to see some "standard" way for servers to identify the set of
>>features/functions that they support - e.g.: acl model, replication model,
>>password policy, alias support, etc.  Some of these imply server-based
>>processing that is "over and above" just allowing the associated schema
>>elements to be stored/retrieved to/from the server.
>>
>>More and more reasons for looking hard at some "admin model" so that these
>>features can be constrained to "areas of the namespace" rather than
>>focussed on server instances.
>>
>>Regards,
>>Tim Hahn
>>
>>Internet: [email-masked]
>>Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
>>phone: 607.752.6388     tie-line: 8/852.6388
>>fax: 607.752.3681
>>
>>
>>
>>
>
>>                     "Kurt D. Zeilenga"
>>
>
>>                     <[email-masked]>         To:
>>
>[email-masked]
>
>>                     Sent by:                    cc:
>>
>
>>                     owner-ietf-ldapbis@O        Subject:  subschema
>>
>clarifications (Was: I-D  ACTION:draft-ietf-ldapbis-models-01.txt)
>
>>                     penLDAP.org
>>
>
>
>
>>                     05/31/2002 01:36 AM
>>
>
>
>>
>>
>>At 07:47 AM 2002-05-30, Kurt D. Zeilenga wrote:
>>
>>>Summary of technical changes made:
>>> - clarified schema publishing / discovery;
>>>
>>A little elaboration...
>>
>>This revision includes clarifications aimed at resolving a
>>couple of subschema discovery issues.
>>
>>Over the years, a number of questions have been raised
>>regarding how clients determine that a server supports
>>capabilities associated with elements of schema, in
>>particular, operational attributes.  For example, how
>>does a client determine whether a server supports
>>DIT Content Rules.
>>
>>I've taken statements in Section 4.1.4 of RFC 2251 that
>>the attributeTypes attribute is used to indicate "support"
>>for an attribute type.  In -00 revision of the I-D, a
>>server indicated support for a number of capabilities
>>(such as DIT Content Rules) by publishing the definition(s)
>>of attribute type(s) associated with the capability.
>>
>>But for this to be a clear indication of support, it is
>>necessary to disallow servers which don't support the feature
>>
>>from publishing the defintions associated with that feature.
>
>>Hence, the -01 revision includes the statement:
>>
>>  A server SHALL only publish schema definitions for
>>  elements it supports.
>>
>>Without this, the discovery mechanism would be fundamentally
>>broken.
>>
>>However, the added statement can be viewed as inconsistent
>>with other statements made in existing "core" technical
>>specification.  So, it might be appropriate to clarify
>>that the subschema mechanism is not capability discovery
>>mechanism.  If so, do we need one or can we live with
>>trial and error discovery mechanism?  (Personally, I can
>>live with trail and error, that's what most clients will
>>do anyways.)
>>
>
>
>
>
>
>

-- 
Ludovic Poitou
Sun Microsystems Inc.
Sun ONE products - Directory Server Group - Grenoble - France