Re: models-09 comments

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:35 AM 1/6/2004, Hallvard B Furuseth wrote:
>A partial reply follows.  Further replies come in separate threads.
>I'll need to chew on some of them for a while first.
>
>Kurt D. Zeilenga writes:
>>At 08:45 AM 12/21/2003, Hallvard B Furuseth wrote:
>>>draft-ietf-ldapbis-models-09.txt says:
>>
>> ABNF literal text strings are case insensitive.
>
>Oh my...  I did look at [ABNF], but i never noticed that.

I forget this fact myself occasionally myself (e.g., X).

>>>> 3.2. Subentries
>>>
>>>>   The term "(sub)entry" in this specification indicates that servers
>>>>   implementing X.500(93) models are, in accordance with X.500(93), to
>>>>   use a subentry and that other servers are to use an object entry
>>>>   belonging to the appropriate auxiliary class normally used with the
>>>>   subentry (e.g., 'subschema' for subschema subentries) to mimic the
>>>>   subentry.  This object entry's RDN SHALL be formed from a value of the
>>>                    ^^^^^^^^^^^^
>>>>   'cn' (commonName) attribute [Schema].
>>>
>>>Only if it is an object entry?  True subentries need not have a CN for
>>>RDN?
>> 
>> As detailed in X.500(93) recommendations, the X.500 subentries must
>> be named with CN.  I'll add a comment to the end of this paragraph:
>>   (as all subentry DSEs are named with 'cn')
>
>I think it's enough to delete 'object' from the text I underlined.

Let me think about this a bit.  I'm trying to avoid specifying how (X.500)
subentries are represented in LDAP as well as requirements upon (X.500)
subentries.  Hence, the qualification.

>> The rule definition, a matchingRuleDescription, does not
>> specify syntaxes of attribute values.
>> 
>>>Should all matching rules be required to do that?
>> 
>> No.  But the technical specification should make it clear what
>> the semantics of an assertion of this matching rule are.
>> 
>> Actually, I think the sentence is confusing and could simply
>> be deleted.  The following paragraph details precisely what
>> the matchingRuleDescription is.
>
>OK if you clarify that 'assertion syntax' means 'syntax of the
>assertion value' as mentioned elsewhere in my comments.

I may instead rewrite the sentence for additional clarify.

>>>> 4.2. Subschema Subentries
>>>
>>>What is 'subschema' as opposed to 'schema'?
>> 
>> Sub in subschema, like sub in subentry, refers to a subtree
>> (or subtree refinement).  That is, a subschema is the schema
>> that controls a particular subtree (or subtree refinement).
>
>OK.  Please mention that in the draft.

Then you'll ask me to define "subtree refinement".  I'd like to
avoid that.

>> BTW, now that LDAP has true subentries, it may be appropriate
>> to include a reference to their technical specification (RFC 3672)
>> (instead of just "future documents").
>
>I don't think servers should have to implement all of RFC 3672 just
>because they implement subentries-that-are-not-object-entries,
>but otherwise I'm fine with that.
>>>> 4.2.6. 'dITContentRules'
>>>>   This attribute lists DIT Content Rules which are in force.
>>>> 4.2.7. 'dITStructureRules'
>>>>   This attribute lists DIT Structure Rules which are in force.
>>>> 4.2.8 'nameForms'
>>>>   This attribute lists Name Forms which are in force.
>>>
>>>Does 'in force' mean that OBSOLETE rules/forms are not listed?
>> 
>> 'in force' here is probably not the appropriate.  Probably
>> should be replaced with "present in the subschema".  (Suggestions
>> for a better term than 'present' are quite welcomed.)
>
>'present' sounds fine to me.  Or you could say 'This attribute lists
>the Name Forms in the subschema.', but there is something about that
>sentence which is bugging me.

I like 'present' better.

>> extensibleObject is actually quite broken
>> as clients can cause havoc by adding the class to servers which don't
>> support the associated semantics...
>
>I don't see what you mean here.  They can't add any attributes.

I thinking of the havor caused by a client which adds 'extensibleObject'
to the subschema of a server which doesn't support 'extensibleObject'.
Another client, seeing 'extensibleObject', is likely to make an
incorrect assumption.  In the revised TS, we've now say that mere listing
of schema elements does not indicate support.  Of course (as previously
discussed), that leaves a big hole in client's ability to discover support
for features associated with elements of schema.

>If you are thinking of replicating from that server to a server which
>supports extensibleObject, well - while extensibleObject may allow
>'havoc' in general by allowing any attribute, if that's what you
>mean, that applies if the user adds the object class directly on
>the server which supports it too.  I'd just trust the user to
>mean what he says when he adds it.
>
>> of course, same can be said of
>> many "operational" object classes (classes which have special
>> "operational" semantics).
>
>You mean when replicating to a server which supports them?

No.  I mean problems caused by publishing elements of schema for
which the server doesn't support.

>>>> 5.1.4. 'supportedExtension'
>> (...)
>>
>>>The term PDU is not defined in [Models]. I hope it can be avoided
>>>without complicating the above text, though I have no suggestion at
>>>the moment.
>> 
>> I'll just spell the term out.  It doesn't need to be more
>> precisely defined.
>
>Oh... you are right, "PDU" is just an acronym, not a word!  I never
>noticed that:-)
>
>>>> 6.3. Cache and Shadowing
>>>
>>>>   Some servers may hold cache or shadow copies of entries,
>>>
>>>Please define 'shadow copy'.
>> 
>> I think the new text in section 5 addresses this well enough.
>
>Yes.  Though perhaps you should add a reference to section 5.
>
>>>> 3.4. Operational attributes
>
>>>>   A DSA-specific operational attribute is
>>>
>>>..."also"...
>>>
>>>(To emphasize that this is no different from DSA-shared.)
>> 
>> okay.
>> 
>>>>   used to represent information
>>>>   of the DSA Information Model.  Its values, if shared between DSAs
>>>>   (servers), need not be identical.
>>>
>>>Suggest to add "(E.g. 'supportedLDAPVersion'.)".
>> 
>> I'll use 'altServer' instead (because its values would be more
>> reasonably shared between DSAs).
>
>Or reword 'Its values, if shared between DSAs (servers), need not be
>identical.'.  The whole point is that the values _aren't_ shared.
>'Its values may be different in different DSAs (servers).'?

Yeah, the more I think about this, the more I dislike the wording of
this and the preceding paragraph.  How about:

 A DSA-shared operational attribute is used to represent information
 of the DSA Information Model which is shared between servers (DSAs).  
                  
 A DSA-specific operational attribute is also used to represent
 information of the DSA Information Model which is specific to each               
 server (DSA) (though, in some cases, may be derived from information
 shared between servers) (e.g., 'namingContexts').

>I suggested 'supportedLDAPVersion' because its meaning is obvious
>even if one has not read section 5.1 yet.

I used 'namingContexts' as, though the precise meaning is not obvious,
even a novice reader should see that different servers like do support
different naming contexts (a term previously used).