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

["Steven Legg" <steven.legg@adacel.com.au>]

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