Subject: [ldapext] Object class for untyped objects

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 31 May 2004 17:44:42 +0200

I'd like to publish an RFC for a structural object class which can be
used (at least) for entries with no 'natural' choice of a structural
object class, typically because the entry must exist even though its
contents are uninteresting.

For example, our directory ended up with entries like this, because no
such object class existed:

       uid=<user name>,ou=people,dc=uio,dc=no
   cn=<group name>,ou=filegroups,dc=uio,dc=no

That 'ou' (organizationalUnit) is silly, but it was the best existing
object class to use.  The entries can end up as useless garbage in
response to searches for org.units.  One might think others who want a
similar structure would be less lazy and define a proper object class,
but I keep seeing this mis-design in other places too.

So I'm thinking of an object class like this:

 ( <OID> 'untypedObject'
   DESC 'Object of no particular type'
   SUP top STRUCTURAL
   MAY ( c $ cn $ dc $ l $ o $ ou $ st $ street $ uid # naming
         $ description $ owner $ seeAlso              # general info
         $ enhancedSearchGuide $ searchGuide ) )      # subtree bases

Do you think such an object class is too general, and I should rename it
to something like 'subtreeBase' instead?

Or is it not general enough for an object class as general as this, and
should include what Luke Howard's upcoming 'namedObject' offers?  "May
be used when no other structural object class is available" - in the
case of namedObject, the rationale is entries whose function is supplied
by an auxiliary object class like posixGroup.  See the expired I-D
<http://www.watersprings.org/pub/id/draft-howard-namedobject-01.txt>.
Currently I avoided that in order to not step on Luke's toes.

Notes on untypedObject's attributes:

- The c through uid attributes are for naming of entries; they are not
  supposed to be used for anything else (unless the entry has other
  object classes as well).  I took them from the table in rfc2253 (UTF-8
  String Representation of Distinguished Names), in case the entry's RDN
  needs to match the RDN of something else.  Though possibly only cn
  should be there, or cn, dc and uid.

- Description, owner and seeAlso seems good to offer for 'nothing in
  particular'-kind of objects, since they may not contain anything else
  which indicates what they are for and who is responsible for them.

- EnhancedSearchGuide and searchGuide are for entries used as
  base objects of subtrees.

Finally, I'm not sure if the proper way to get an OID for such an object
class is to use our own OID space or to get one from IANA.  BCP64
(RFC3383) section 3.1 says

   For IETF developed elements, specifications SHOULD use OIDs under
   "Internet Directory Numbers" (1.3.6.1.1.x).

but maybe that doesn't apply to an informational RFC developed on an
expired IETF working group's mailing list.  (Kurt, maybe you could add
something to bcp64bis about that?  And maybe the reply to that should go
to [email-masked].)

-- 
Hallvard

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 31 May 2004 18:22:08 +0200

>    "Internet Directory Numbers" (1.3.6.1.1.x).

Um.  Maybe I should add that the reason I think this might apply at all
is because I'll be develop it through Internet-Drafts in order to become
an RFC, not just to publish an already existing schema element.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 31 May 2004 10:31:07 -0700

>an RFC, not just to publish an already existing schema element.

A couple of notes regarding this BCP 64 text...

First note that text says "For IETF developed elements" as opposed
to "elements described in IETF documents".  This because IETF
documents often describe elements developed by others (e.g.,
other SDOs, individuals).  Second note that IETF work can be done
by individuals as well as by working groups.

That said, I don't think this sentence was intended to exclude
others from requesting assignment of an Internet Directory
Number for use in an LDAP specification.  This is evident
because the assignment practice is "Expert Review
with Specification Required" and not "IETF Consensus". 
A simple rewording/reordering of the section would likely be
more clear here.  I intend to incorporate such a change in
the next revision of the BCP64bis I-D.

Kurt