KEP-0007.txt

Jeroen van Meeuwen vanmeeuwen at kolabsys.com
Fri Apr 15 01:48:58 CEST 2011


 KEP-0007.txt |  173 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 173 insertions(+)

New commits:
commit b35e586cf6df11d54d43c8f8a4c0da5ebfd44f3e
Author: Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com>
Date:   Fri Apr 15 00:47:42 2011 +0100

    Add new submitted KEP 0007 titled "Definitions of Kolab Objects"

diff --git a/KEP-0007.txt b/KEP-0007.txt
new file mode 100644
index 0000000..149d836
--- /dev/null
+++ b/KEP-0007.txt
@@ -0,0 +1,173 @@
+{{kep
+ |number=7
+ |ticketnumber=
+ |title=Definitions of Kolab Objects
+ |author=Jeroen van Meeuwen
+ |author_email=vanmeeuwen at kolabsys.com
+ |status=draft
+ |type=informational
+ |creation_date=2011-04-14
+ |obsoletes=
+ |obsoleted_by=
+ |related=
+}}
+
+== Abstract ==
+
+The Kolab Groupware solution is heavily based around LDAP functionality, and more specifically OpenLDAP.
+
+To smooth future integration with other LDAP server technology and to abstract the functionality Kolab Groupware requires from an Authentication and Authorization Database, and to outline the parameters for future development, this Kolab Enhancement Proposal has been created to outline just those parameters by defining the Kolab Objects.
+
+== Object Classification ==
+
+The objects defined in this document are classified to reflect the importance of their existence to a Kolab Groupware environment. In future references, these classifications could be used to, for example, split up mandatory, recommended and optional LDAP schema extensions or SQL database schema definitions.
+
+The classifications are defined as follows;
+
+; '''Primary'''
+: These are the objects without which no Kolab Groupware solution can be deployed.
+; '''Secondary'''
+: These are the objects that make a Kolab Groupware deployment the platform for collaboration, and enrich the user's experience interacting with the Kolab Groupware environment.
+; '''Tertiary'''
+: These are the objects related to larger Kolab Groupware deployments and may or may not apply to a certain implementation scenario.
+; '''Quaternary'''
+: These objects are organization specific.
+
+== Primary Objects ==
+
+The following primary Kolab Objects are defined in this document;
+
+* Account
+* Group
+
+=== Account ===
+
+An account consists of, at the very least, half of a set of authentication credentials, the ''username''. In typical deployments, two parts of the authentication credentials are stored with an account; the ''username'' and ''password''.
+
+An account in itself does not necessarily specify '''what type of account''' the entry represents. Types of accounts may include, but are not limited to;
+
+; Administrator Account
+: For example, ''cn=Directory Manager''
+; External User Account
+: For example, ''bugzilla-user at tailspintoys.com''
+; General User Account
+: For example, ''temp-hire at example.org''
+; Kolab User Account
+: For example, ''employee at example.org''
+; Service Account
+: For example, ''svc-bugzilla''
+
+Certain policies may apply to one type of accounts, most commonly user accounts, such as password expiry, complexity requirements or recipient policies. Additionally, service accounts usually do not use an email address coupled to their service account username.
+
+Accounts associated with persons usually have the following attributes defined as mandatory;
+
+; Given name
+: For example, ''John''
+; Surname
+: For example, ''Doe''
+
+More attributes may be considered, or have been defined as mandatory. These however may be generated using the input on the former mandatory attributes;
+
+; Display name
+: For example ''Doe, John'', ''Doe, J.'', ''John Doe'' or ''J. Doe''. Typically, this is how the user account shows up as a contact in global address book searches.
+; Email address
+: For example ''j.doe at example.org'' or ''john at example.org''
+; Username
+: For example ''jdoe''
+
+=== Group ===
+
+At the very minimum, a group consists of an identifier. In order for it to be eligible as a group, it probably allows members to be added and removed from the group.
+
+Different types of groups may include;
+
+; Distribution Group
+: This is the type of group that is used for distribution of information. In a typical user interaction flow, upon selection from an address book, a distribution group expands to the addresses of the actual members of the group.
+; Security Group
+: A security group on the other hand is used for access control and authorization purposes.
+
+In some deployment scenarios, members have security group membership levels allowing them to add, modify or remove other members to, in or from the security group, respectively.
+
+A group is not necessarily of one type '''or''' the other. A security group may very well also be used as a distribution group. However, by their very nature, security groups are not supposed to show up in address books '''unless''' they are also distribution groups.
+
+The use of either type of groups is different, however. For a distribution group, typically the email address attribute for the member of the group is used, whereas with a security group, the authorization typically uses the username for the member of the group.
+
+== Secondary Objects ==
+
+The following secondary Kolab Objects are defined in this document;
+
+* Distribution List
+* Resource
+
+=== Distribution List ===
+
+A stub address book entry for mail-enabled processing software, such as mailing list software ''mailman'' or ''majordomo''. Not to be confused with a ''Contact'' defined as a quaternary object, as Distribution Lists tend to be for internal use only, but even in cases they are not, have submission access policies.
+
+=== Resource ===
+
+An object representing an object such as a beamer, conference room or a car.
+
+{{note|A Shared Folder is NOT an Object|A shared folder is not a Kolab Object, because it does not require an entry in the authentication and authorization database in order for it to exist.}}
+
+== Tertiary Objects ==
+
+The following tertiary Kolab Objects are defined in this document;
+
+* Class of Service
+* Domain
+* Host
+
+=== Class of Service ===
+
+A CoS may be used to define a set of common settings for users and/or groups. Such CoS may define default values for other objects, such as quota or recipient policies.
+
+=== Domain ===
+
+A domain -not to be confused with a realm defined as a quaternary object- as is used in relation to Kolab Groupware actually represents a mail domain, and implicitly refers to a domain name space rather then a domain.
+
+=== Host ===
+
+A host is a node, or ''operating system instance''. In relation to Kolab Groupware, nodes participate in the Kolab Groupware environment.
+
+== Quaternary Objects ==
+
+The following quaternary Kolab Objects are defined in this document;
+
+* Calendar
+* Contact
+* Contact List
+* Mail Accounts
+* Realm
+* Miscellaneous
+
+=== Calendar ===
+
+Used to refer to an external (non-Kolab) calendar.
+
+=== Contact ===
+
+A mail or instant messaging contact. Usually refers to an entity external to the organization.
+
+=== Contact List ===
+
+A list of contacts used as a permanent filter or search, for example ''All Kolab Users'', or ''All Receptionists''.
+
+=== Mail Accounts ===
+
+Mail accounts external to the organization, to be polled for new email that may or may not be fetched and delivered locally.
+
+=== Realm ===
+
+A realm, not to be confused with a domain, is an authentication and authorization namespace. Applicable to deployment scenarios implementing Kerberos authentication.
+
+=== Miscellaneous ===
+
+Any other object type, for example, ''kolabGermanBankArrangement''
+
+== References ==
+
+{{Reflist}}
+
+== Copyright ==
+
+This document is placed in the public domain.





More information about the commits mailing list