Application Working Group                               Bruce Greenblatt
Internet Draft
<draft-greenblatt-ldap-applusers-00>
Expires in six months


                LDAP Object Class for Application Users


Status of this Memo


        This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   andits working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or made obsolete
   by other documents at any time. It is not appropriate to use
   Internet-Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

        To learn the current status of any Internet-Draft, please check
   the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

        Distribution of this document is unlimited.

        Abstract

        This draft describes a means for an Application Server to indi-
   cate in a directory entry that the directory object specified is a
   user of that application server.

   1.  Mechanism

        In working with various directory enabled applications and ser-
   vices, it has been noticed that several of them presume the existence
   of an auxiliary object class with no attributes that is used to
   detect "their" users.  For example, the foo application service will
   use the fooUser object class, and attach this object class to all of
   its user objects in the directory in order that it may later on
   easily detect "its" users, by virtue of the fact that those users are
   members of the fooUser object class. This fooUser object class is a
   subclass of top with no additional attributes.  This specification



Greenblatt                                              FORMFEED[Page 1]

Internet Draft                                                 July 1997


   intends to head off the day when a user would get one of these appli-
   cationUser object class things attached to its directory object for
   each application that it uses.  This would mean that that object's
   object class attribute would eventually have dozens of values, which
   would in turn lessen the value of this attribute.

        If numerous application services are going to want to do this
   type of thing (which is perfectly valid), a general solution in the
   schema should be provided.  The following solution is given:

        Use this auxiliary class to indicate that an object in the
   directory is a user of your application that is identified by the
   applicatioOID attribute.

   ( 1.3.6.1.4.1.250.3.16 NAME 'applicationUserObject' SUP top AUXILIARY
   MUST applicationOID )


   This multi-valued attribute holds the list of applications of which
   the directory object is a user.

   (  1.3.6.1.4.1.250.3.17 NAME 'applcationOID' EQUALITY objectIdentifi-
   erMatch SYNTAX 'OID' )

   Applications that wish to indicate that a directory object is a user
   of their application should use the applicationUserObject and not
   create a new auxiliary object class with no attributes for this indi-
   cation.  The use of auxiliary object classes without attributes is
   deprecated.

        Author's Address

           Bruce Greenblatt
           Novell
           2180 Fortune Drive
           San Jose, CA 95131
           USA
           Phone: +1-408-577-7688
           Fax: +1-408-577-7605
           Email: bgg@novell.com











Greenblatt                                              FORMFEED[Page 2]