[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: models-09 comments

To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: models-09 comments
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Tue, 6 Jan 2004 10:35:57 +0100
Cc: ietf-ldapbis@OpenLDAP.org
In-reply-to: <6.0.0.22.0.20031224110949.041efa60@127.0.0.1>
References: <HBF.20031221t15e@bombur.uio.no> <6.0.0.22.0.20031224110949.041efa60@127.0.0.1>
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.

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

>>Otherwise, these terms should be defined somewhere.
>>
>>> 4.1. Schema Definitions
>>
>>>       xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
> 
> BTW, that should be "X" not X.  Will fix in next revision.

OK.  Then you can delete the definition of X.

>>> 4.1.3. Matching Rules
>>
>>>   A matching rule specifies the syntax of the assertion value.
>>
>>The matching rules in [Syntaxes] also specify the syntaxes of the
>>attribute values they can be used with.
> 
> I assume you mean the technical specification for the matching rule.

Yes.

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

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

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

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

>>> 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).'?

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

>>> 4.4. Subschema Discovery
>>
>>>   To discover the DN of the subschema (sub)entry holding the subschema
>>>   controlling a particular entry, a client reads that entry's
>>>   'subschemaSubentry' operational attribute.  To read schema attributes
>>>   from the subschema (sub)entry, clients MUST issue a base object search
>>
>>..."[Protocol]"...  (as 'base object searches' have not been defined)
>>..."at that DN"...
> 
> I'll reword this:
>  To read schema attributes from the subschema (sub)entry, clients
>  MUST issue a Search operation [Protoco] with baseObject of the
                                        ^^^
                                     missing "l"

>  DN of the subschema (sub)entry, scope of baseObject, filter of
>  "(objectClass=subschema)" [Filters], and the list of attributes
>  includes the names of the desired schema attributes (as they are
>  operational).  Note: the "(objectClass=subschema)" filter allows
>  LDAP servers which gateway to X.500 to detect that subentry
>  information is being requested.

OK.  Though I suggest 'with baseObject of ... scope of ... filter
of' is replaced with 'where baseObject is ... scope is ... filter
is' because of that other 'of' in the sentence.

>>> 6.1. Preservation of User Information
>>
>>>   Where such requirements have not be explicitly stated, servers SHOULD
>>>   preserve the value of user information but MAY return the value in a
>>>   different form.
>>
>>Suggest to add:
>>
>>    (For example, the DN "O=Widget\2C Inc." may be returned as
>>    "o=Widget\, Inc." since "\2C" and "\," are different ways to
>>    represent commas in DNs, and "O" and "o" represent the same
>>    attribute's numericoid.)
> 
> I'll try to add an example, but rather avoid using the DN syntax
> here (as it is rather complex).  Maybe values of objectClass
> would be better.

OK.

>>> 5.1. Server-specific Data Requirements
>>
>>>   (...)
>>>   attributes of the root DSE.  Client SHOULD NOT assume that the
>>>   subschema (sub)entry controlling the root DSE controls any entry held
>>>   by the server.
>>
>>s/Client/Clients/.
>>s/any entry/any other entries/.  It does control the root DSE, after
>>all.
> 
> Well, I think I was referring to any entry DSEs not any DSE.
> The root DSE is not an entry DSE.  I'll change it to "other DSE".

I prefer my version, because I thought it was saying 'A client
SHOULD NOT just assume that one schema controls all entries in the
server and therefore just read one entry's schema' - which I can
well imagine clients doing by reading the root DSE's schema.  It's
the most natural entry to choose.

-- 
Hallvard
Follow-Ups:
- Re: models-09 comments
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
References:
- Re: models-09 comments
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Prev by Date: Re: Protocol: abandoning Bind and Start TLS
Next by Date: Re: Protocol: control specifications.
Index(es):
- Chronological
- Thread