* mutable
/ multivalued
DNs:
	Personal
		DN   arbitrarily formed from unique value data base index.
		*CN  Different name than HEPPS/Li
		uid  from Li (means e.e.g., "donn", "fox")
		*/OU
		*/Street
		*/Phone
		*/URL
	Institutional
		DN   Owner's choice
		same with attributes

Some of this data has been going through payroll coordinators and HEPPS.
Does all of it have to?  I mean, suppose we start ignoring their PHONE1
and PHONE2 fields, is that just a burden off their back?  If they consider
the phone data critical for other purposes, would there be any way to push
back changes applied to the LDAP side?

The paper directory is obviously an issue too.  If the data published online
contains some authoritative data, Directory Services will probably want it,
or to look at it the other way, Directory Services may want to get into this
business even more directly than that.  Would they consider taking on the
administrative support, like the channel that now exists between payroll
coordinators and IS,  maybe with us like Sid's group is with IS in technical
support.

Basic LDAP data structure problems.  What if I have two appointments?
The LDIF load doesn't seem to allow multiple values unless they're
consecutive, which doesn't work out very well here.  Separate DNs
for each appointment isn't the answer, because then if you hit me by
searching for one of my OUs, you get only that DN.  (Not to mention
that it's ugly anyway.)