[ldapext] Object class for untyped objects

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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 ietf-ldapbis@openldap.org.)

-- 
Hallvard

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext