SCOPE
o Let's assume that we're limiting our discussion to a single server, and that we'll deal with federations of servers in a future discussion.

USER DATABASE ASSUMPTIONS
o I'm assuming that for each ESME server there will be one and only one user directory server (such as an LDAP server).

[Daniel] In my opinion we should allow more sources as a user database: jdbc, ldap, active directory also in combination.

o I'm assuming that an ESME server will only recognize users listed in the directory server.

o I'm assuming that the directory server is managed by organization-level administrators, and that only these administrators can add, edit and delete users.

IMPLICATIONS OF THE USER DATABASE ASSUMPTIONS
o WHO can use a given ESME server is thus out of control of the ESME server, and in control of the user directory administrator(s).

o Since the ESME server will have to keep track of a number of ESME-specific data for each user (e.g. "who do I follow?"), the ESME server will have to maintain a database of "preferences" that are keyed to each user in the directory server.

[Daniel] The ESME server should use an user identifier (from a directory), but should keep the preferences in an own data store independent from the directoy.
(--> I am thinking a environments, where ESME can read/use the directory, but not modify it) 

o Within the ESME end-user UI, this results in there being some info that comes from the directory server and thus that the end user CAN'T change (e.g. name, work phone, department, mailstop, etc.) and info that only applies within the ESME context and that the end user CAN change (e.g. nickname, maybe his/her picture or icon, list of people he/she follows, etc.).

QUESTIONS, ISSUES
o Are the above assumptions and implications correct?

o Do we want to allow the administrator of an ESME server to be able to create and maintain it's own private database of authorized users in addition to those provided by the organization's directory server?

     PROs: Makes it easy to set up a test/evaluation ESME server. Makes it possible for small organizations (those without corporate LDAP, etc. directories) to use ESME.

     CONs: Introduces the possibility of duplicate user entries.  If used extensively makes synchronization with the organizational directory impossible.  Provides an end run around policies that the organization is counting on the organizational directory to enforce.

o What ESME-specific, end-user-defined, user-profile data do we want to support?

     ESME Nickname? -- But what if organizational policy dictates the use of only a person's "official" user name?

[Daniel] We should support an ESME specific nicknames, because username policy might also mean that I am "Z000EC1G", which is ok for windows domains, but not for
a microblogging tool. 

     Picture/Icon? -- But what if the organizational directory server supplies one?  Do we use the "official" image by default, and let any user-defined image override it?

[Daniel] If you let the image_url property be either editable or not, this topicshould be solved. 

o Would our strategy be that the ESME administrator could enable/disable any of these user-profile-customization fields as required by organizational policy, that we use the organizational-server-supplied data by default, but override it with the user-supplied values (if any)?

[Daniel] Good point.