Subject: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 20 Jan 2006 13:51:25 -0800

I don't see way this class would have any MUST/MAY
attributes (other than 'objectClass' as required
by the SUP top).  It seems that it would be more
appropriate to use DIT content rules/auxiliary
object classes (including possibly extensibleObject)
to require/allow any desired attributes, including
those used for naming.

I don't like the name of this class, but the
alternatives don't seem much better (if better
at all),  'unclassifiedObject', 'structurallessObject',
'unstructuredObject' (at present, I prefer the latter).

A few misc. comments (mostly editorial, but some of
substance).
  Reference the revised LDAP TS instead of RFC 3377 for
  LDAP (its nearly all approved now).

  s/'natural'/natural/ so as not to be confused
  to be an descriptor

  Second paragraph of 1 is not only oddly formated,
  but oddly worded.

  Unclear whether [LDAP-NIS] refers to the revised
  NIS/LDAP specification or RFC 2307.  One or the other
  please.

  The example should include the LDIF for an object of  this class.

  "This document raises no known security issues."
  Well, given RFC 2256 discussions security considerations
  for attributes such as CN, I would think there are
  known security issues impacting this specification.
  And even if you were to removal all attributes from
  the class, there would likely still be some generally
  applicable considerations worthy of mention.  I suggest
  the authors read Section 7 of draft-zeilenga-ldap-ext
  and attempt to satisfy its requirements/recommendations
  here.
  
  "[Editor: I don't know if last sentence is necessary.]"
  It's not.  And the OID assigned would not be
  1.3.6.1.1, but some OID under 1.3.6.1.1.  The
  sentence and note should be deleted.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 21 Jan 2006 02:22:00 +0100

Kurt D. Zeilenga writes:

> I don't see way this class would have any MUST/MAY attributes
> (other than 'objectClass' as required by the SUP top).

Well, the rationale is in Appendix A, except:

> It seems that it would be more appropriate to use DIT content
> rules/auxiliary object classes (including possibly extensibleObject)
> to require/allow any desired attributes, including those used for
> naming.

I don't get this.  Plenty of other object classes can be used for a
number of different scenarios and provide a bunch of attributes that
just might be useful, e.g. the MAY attributes to 'person'.  That's
partly what MAY is for in the first place.  How is this different?
The major thing wrong I can see with this class is that it must be
structural but doesn't really deserve to be, not which attributes it
has.

And quite possibly it has too many naming attributes.  I can see
moving the other naming attrs than CN to an aux class which would
also be defined in the draft.

extensibleObject and DIT content rules may both be unsupported.
But it might be an idea to suggest them in the draft, in particular
if most/all attributes are deleted.

> I don't like the name of this class, but the alternatives don't seem
> much better (if better at all), 'unclassifiedObject',
> 'structurallessObject', 'unstructuredObject' (at present, I prefer the
> latter).

Yeah, they are all equally bad:-(  I could go for either.

structurallessObject... hmm, it sounded absolutely wrong at first
glance, but maybe not...

Or namedObject, which this version of the draft steals some text from.
Don't know where the namedObject draft is going or if this would be OK
with the author of that one.

> A few misc. comments (mostly editorial, but some of

Leaving most for Alexey.

>   (...) I suggest

Good tip.

BTW, sorry about dropping this draft some time ago.  Alexey picked it up
again.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Jan 2006 23:45:01 +0000

>also be defined in the draft.
For the purposes I use this Object Class in Isode software I need cn, 
uid and dc.
The description attribute seems to be a good idea for describing why an 
entry of this class is present in DIT.
I don't have strong opinion about other attributes.

>extensibleObject and DIT content rules may both be unsupported.
Right.

>structurallessObject... hmm, it sounded absolutely wrong at first
I like the name Container, which is used by Microsoft AD for similar 
purposes.

>with the author of that one.
I think Luke Howard has agreed to my idea of having a single merged draft.

>>A few misc. comments (mostly editorial, but some of
Yes, comments look straightforward.

>>  and attempt to satisfy its requirements/recommendations
Ok, I will think about Security Considerations for the next revision.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 23 Jan 2006 22:39:52 -0800

>>Well, the rationale is in Appendix A, except:

Yes, I just don't agree with the rationale.  I would rather
the class be defined not to allow any attribute that if
present, irregardless of value, be indicative of a particular
type of object.  That is, the allowed attributes should not
'type' the untyped object.  For instance, the presence of
'dc' implies the object can be typed as being domain related.

You note this in the I-D:
   Use of the [other attributes] may be an indication that the
   entry should have a more descriptive object class
   instead of or in addition to this one.

But I note that as attributes used for naming are also
descriptive of the object, your note should not only
apply to "[other attributes]", but to all attributes
of the class.

Even presence of cn can be viewed as typing the object as
being 'named'.  Instead of dividing the class by presence
of cn, I rather do this by class, either have namedObject
& unnamedObject structural classes, or untypedObject structrual
class and a cnObject auxiliary class.  And given that same
applies many of the other attributes (e.g., (dc=*) => object is
domain related)), the latter is the better choice.

That is, I think it would be better to have
        ( 1.1.1 NAME 'untyped' )
and a set of appropriate AUXILIARY classes for naming
and other uses (such as allowing/requiring attributes which
divide the class).

I'm not even convinced that description, seeAlso, and owner
don't divide the class and might be better brought in by
auxiliary classes, describedObject, relatedObject, ownedObject.

It seems this is more consistent with (my perception of) the
use model for the untypedObject class.  The use model seems
that objects of this class should belong to some number of
auxiliary classes.  This number should be non-zero.

>>structural but doesn't really deserve to be, not which attributes it

I think its a bad idea to include attributes because
they might be used in naming some objects of the class.
I think its far better to use an auxiliary class or DIT
content rule to allow a naming attribute other than those
attributes used to represent the object.  For instance,
use of dcObject to allow 'dc'.

>>also be defined in the draft.

Though I think it would be better to allow no attributes,
I could see an (untyped) object having a (common) name, uuid,
and description.  I could even see owner and seeAlso being
generic enough for to all for a class suitable for holding
any object.

But userid?  If the object has a user id, I would think the object
represents an user entity of some sort.  Adding 'uid' suggests a type of
object, and hence, I think inappropriate for 'untyped' objects.
Likewise for 'dc', 'l', 'o', etc..

>For the purposes I use this Object Class in Isode software I need cn, uid and dc.

What need can you not fulfill by using:
        untypedObject+cnObject
        untypedObject+uidObject
        untypedObject+dcObject
        untypedObject+extensibleObject
        untypedObject+...
        untypedObject+ DIT content rule

where untypedObject has no allowed attributes?

>The description attribute seems to be a good idea for describing why an entry of this class is present in DIT.

Yes, but there always regular auxiliary classes to allow in
desired attributes.  You can argue, I guess, that there might
be implementations that don't support auxiliary object classes.
There might even be such implementations (as LDAP doesn't
require implementation of the X.500 schema model).  But
such implementations should be ignored as you are defining
an X.500 schema element (for use in LDAP).

>I like the name Container, which is used by Microsoft AD for similar purposes.

I dislike the name Container as that implies it represents
objects that contain other objects.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 29 Jan 2006 16:33:47 +0100

OK, I finally got to this...

> 'dc' implies the object can be typed as being domain related.

I've finally realized I left unsaid part of my own reason for including
other naming attributes than "cn":

1) "ou=people", "ou=users" etc is almost a de-facto standard for
   "container" entries, so I wanted to support it.  Just replacing the
   object class so a filter (objectClass=organizationalUnit) will not
   return ou=people, is likely a fairly small fix compared to renaming
   the tree to cn=people and fixing the base DN in a bunch of clients.
   The latter might not get done as quickly in an existing installation,
   if ever.

   Also, I have seen clients that "knew" what naming structure was used
   in the directory even if they didn't know the actual attribute values
   - like "ou" for container objects, and "o" for the top object.  So if
   such a client happens to be the motivation for setting up a quick
   LDAP installation...  That's a while back now though, we have mostly
   played with our own clients lately:-)

2) Since I included ou, it seemed reasonable to be a little consistent
   about it, and include other "official" naming attributes as well.

While I don't know what Alexey's reasons for wanting dc and uid, I
prefer to have at least "cn" and "description".  Still, auxiliary
classes would work fine for me as well - as long as we define and
publish them.  The reason ou did become widely used is probably just
that there wasn't a more suitable standard class.

> apply to "[other attributes]", but to all attributes

Well, the attribute used for naming might just be descriptive in the
sense "we once used organizationalUnit for this object, lacking a better
class".

> and other uses (such as allowing/requiring attributes which

Here I disagree.

One purpose of this class is to satisfy a requirement of the X.500/LDAP
model, that entries need a structural class, even when there is no
interesting type to assign the object.

The purpose of a class with naming attributes will also be to satisfy
requirements of the model, that the RDN must have an attribute and the
entry must have an object class which allows that attribute.
(Unless a DIT content rule is used.)

In this sense, the structural class and the class which allows the
naming attribute really has the same function - just to satisfy the
model's reqirement.  The person who inserts the attribute and the
class(es) does not intend to convey anything interesting in doing so.
At least with attribute "cn" or a backwards-compatibility "ou", I don't
know about other cases.  Why add two uninteresting classes to the entry
instead of one?

That said, I don't feel all that strongly about it.

> auxiliary classes.  This number should be non-zero.

Well, I disagree there too, but could go either way.  Except I'm still
wondering about one detail, see below:-)

(..snipping, would just repeat stuff..)

> where untypedObject has no allowed attributes?

Why a bunch of classes that just allow one attribute, instead of one
that allows several - even for auxiliary classes?  Same with your
describedObject, relatedObject, ownedObject.

In particular for this purpose - an ouObject class in the entry would
actually look to someone reading the directory like intended to be
informative - that the entry is some kind of organizational unit.  A
more general class, auxiliary or structural, would not imply that.

>>>> I don't like the name of this class, but the alternatives don't
>>>> seem much better (if better at all), 'unclassifiedObject',
>>>> 'structurallessObject', 'unstructuredObject' (at present, I prefer
>>>> the latter).
>>>

Metoo, though not more than the other names.

I kind of like namedObject, actually.
Or uninterestingObject:-)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 29 Jan 2006 21:48:20 -0800

>interesting type to assign the object.

That purpose is met by the above.  The object has the structural
class untyped.

>entry must have an object class which allows that attribute.

Yes, but nothing in the model as that the attribute must
be allowed directly by the structural object class of the
attribute type.

>(Unless a DIT content rule is used.)

Well, since you assuming use of auxiliary classes to allow
other attributes, you are (in the X.500 model) assuming use
of a DIT content rule.  

>model's reqirement. 

Again, the X.500 model doesn't require the structural
class to directly allow the naming attribute.  The
model allows these to be allowed through use of a
DIT Content Rule (allowing the particular attribute,
or allowing an auxiliary class that allows the attribute).

>The person who inserts the attribute and the

My understanding of your intent is to use one structural
and some non-zero number of auxiliaries.

If you want to make it usable without a DIT content rule
(hence no additional attributes, no auxiliaries allowed),
then yes you would need at least one attribute type.

As I noted before, I could see allowing 'cn'... but I see
no reason to add 'all common naming attributes'.

>That said, I don't feel all that strongly about it.

Well, as I don't intend to use this class, I certainly don't
feel strongly about this either.  You could say I am just
playing the devil's advocate.

>that allows several - even for auxiliary classes?
>Same with your describedObject, relatedObject, ownedObject.

Because each of these auxiliaries defines a distinct interface.

Of course, if you just want to allow everything, you only need
one class, it's called extensibleObject.

>I kind of like namedObject, actually.

If you define namedObject consistent with its current use in the
wild, no problem...