Subject: Re: Models: Schema references to undefined entities

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 Feb 2003 16:35:45 +0100

Kurt D. Zeilenga writes:
>At 01:24 PM 1/31/2003, Michael Ströder wrote:
>>Hallvard B Furuseth wrote:

> Note that I use the term "published" here.  Schema is "defined"
> in technical specifications, servers publish descriptions they
> know (if they so choose).

Oh, right.  That was in a previous draft of [Models], but it's not in
version 06.  Could you put it back?

>>> For example, an attribute type defined by the server's standard
>>> setup may have to be omitted because of a name conflict with a
>>> locally defined attribute type.  One could edit the attribute out of
>>> the object class which uses it as well, but that's uglier since
>>> clients would receive an incorrect definition of that object class.
>>
>> If the object class references the attribute type by name isn't there
>> still a naming conflict? IMHO the 'locally defined attribute type'
>> gets referenced thus changing the object class definition. Maybe it's
>> me but this sounds rather strange to me.

Sorry, I forgot to mention that I thought of replacing the attribute's
name, if any, with its OID in the object class description.

-- 
Hallvard

---

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

title changed to separate issues

>version 06.  Could you put it back?

I assume you are asking to revert the I-D to "servers publish
schema what they support" semantics.

Last spring we had a discussion of these issues last spring.
Here is the start of the thread:
  http://www.openldap.org/lists/ietf-ldapbis/200205/msg00034.html

Steven Legg raised a concern about this
  http://www.openldap.org/lists/ietf-ldapbis/200206/msg00002.html

which lead to the I-D having its current wording.  I (as Editor)
believe the current language in this area reflects WG consensus.
Of course, the purpose of this WG Last Call is to confirm WG
consensus. I suggest you review the above referenced messages
as well as other messages you might find on this subject in the
archives.  After doing so, if you have concerns, make a specific
suggestion (change X to Y) for the WG to consider.

(I'll respond to rest of your post in a separate post)

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Feb 2003 09:11:53 -0800

>name, if any, with its OID in the object class description.

I think this is just another facet of the "short names are
ambiguous" issue.  Does the current text, in particular 6.2,
adequately address this issue?  If not, what changes do you
suggest?

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Feb 2003 22:28:37 +0100

> schema what they support" semantics.

No, this part of 4.4 (Subschema Discovery), which disappeared at the
same time.  Sorry, I should have tracked it down before posting:

  Clients SHOULD NOT assume that server supports all referenced elements
  of a particular definition.  For example, a client is not to assume
  the server supports the EQUALITY matching rule of a listed attribute
  unless the server publishes a definition for that matching rule.

It doesn't quite fit the messages below, though.

> suggestion (change X to Y) for the WG to consider.

My concern, in light of that discussion, is that the current text can
lead a reader to assume that if a server only publishes schema elements
it supports.  If I understand that discussion correctly, adding this to
4.4 should cover it:

  Clients SHOULD NOT assume that server supports all published or
  referenced elements of a particular definition.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Feb 2003 23:11:50 +0100

Kurt D. Zeilenga writes:
> How about dropping the 4.2 addition suggestion (I
> made in the summary (item 11) and instead add the
> following to 4.4?
> 
>         Clients SHOULD NOT assume a published subschema is
>         complete nor assume the server supports all schema
>        elements it publishes.

Fine.
(I'd prefer 'publishes or references', but that's no big deal.)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 Feb 2003 14:08:34 -0800

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Feb 2003 23:14:16 +0100

> adequately address this issue?  If not, what changes do you

None.  I wasn't talking about changes in the drafts here, but
how to change the text of the object class description in a server
without changing its semantics.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 22:17:08 -0800

The [Models, Section 4.2.5] sentence:
	This attribute holds definitions of LDAP syntaxes
	supported in the subschema.

is not aligned with the position that server publishes
what it knows, not what it supports.  A number of other
subschema attributes sections have similar sentences.
I suggest deleting all occurrences of the phrase
"supported in the subschema" in the I-D.

Kurt