Project Number:	AD1006	
Project Title:	EuroView - X.500 Directory Services for Administrations in Europe	
Deliverable Type:	PU	

Deliverable Number:	D4.1	
 Contractual Date of Delivery:	04	
Actual Date of Delivery:	08	
Title of Deliverable:	Euroview Schema	
Workpackage contributing to the Deliverable:	WP4	
Nature of the Deliverable:	RE	
Author:	Damy Mahl	

Abstract	This document defines the current schema in use, or in planned use, by the EuroView project. The schema is closely aligned to that in use by the NameFlow-Paradise project.	
Keywords		
Classification		

Name of Client:		
Distribution List:		
Authorised by:		
Issue:	1.1	
Reference:		
Total Number of Pages:	18	
Contact Details:		

Table of Contents
PART I	Title Page
Part II	
Document Control	
Executive Summary	
PART III	
1. Introduction	
2. Entry Attributes	
2.1 Attributes	
3. Object Types and Classes	
3.1 Object Classes and Attributes Defined for EuroView	
3.1.1 Mail Addressing for Non-User Entries	
3.2 Common Object Classes	
3.3 Person	
3.4 Organization	
3.5 Organizational Unit	
4. Name Forms	
4.1 Person	
4.2 Organizational Role	
4.3 Organization	
4.4 Organizational Unit	
5. Example Directory Tree	
5.1 Some Concrete Examples	
5.1.1 Organizational Role	
5.1.2 Public Contact	
6. Appendix A - EuroView Object Identifier Branch	
7. Appendix B - EuroView Defined Object Classes	
PART IV	
1. References	

Part II
Document Control
Issue Number	Issue Date	Reason for Change	
1.1	12/08/96		

Executive Summary
This document specifies the current schema specification used by the EuroView X.500 pilot service, the schema being the set of rules which define the structure and content of an X.500 database.
The following pieces of information form the definition:
•	Minimum attribute set to be used in EuroView entries.
•	Minimum object class set to be used in EuroView entries. 
The intention is that the schema will be reasonably minimal to permit flexibility in interpretation and allow for a degree of local variation. Aside from this the main design issue is maintaining compatibility with existing schema, especially as defined by current Commission sponsored X.500 service projects (NameFlow-Paradise in particular) and related Internet standards. The specific schema used as a basis for this document is described in the Internet standard RFC1274.
This document, though an early project deliverable, is expected to evolve and expand considerably during the course of this project, especially as the requirements of a wider range of validation sites are drawn into the EuroView user survey document. The initial version is intended to encompass core White Pages data only. Use of infrastructural, system and other data is not within the scope of the EuroView project and is thus not considered in this document.
This document is based on the 1988 version of the standard, as technology based on X.500/1988 will be used until X.500/1993 implementations mature. This document will evolve as the new technology comes into play. Changes are likely to come about as a result of the additional object classes and attributes available, but also as a result of new functionality, e.g. the access control model.

PART III
1.	Introduction
This document specifies the current schema specification used by the EuroView X.500 pilot service, the schema being the set of rules which define the structure and content of an X.500 database.
The following pieces of information form the definition:
•	Minimum attribute set to be used in EuroView entries.
•	Minimum object class set to be used in EuroView entries. 
The intention is that the schema will be reasonably minimal to permit flexibility in interpretation and allow for a degree of local variation. Aside from this the main design issue is maintaining compatibility with existing schema, especially as defined by current Commission sponsored X.500 service projects (NameFlow-Paradise in particular) and related Internet standards. The specific schema used as a basis for this document is described in the Internet standard RFC1274.
This document, though an early project deliverable, is expected to evolve and expand considerably during the course of this project, especially as the requirements of a wider range of validation sites are drawn into the EuroView user survey document. The initial version is intended to encompass core White Pages data only. Use of infrastructural, system and other data is not within the scope of the EuroView project and is thus not considered in this document.
This document is based on the 1988 version of the standard, as technology based on X.500/1988 will be used until X.500/1993 implementations mature. This document will evolve as the new technology comes into play. Changes are likely to come about as a result of the additional object classes and attributes available, but also as a result of new functionality, e.g. the access control model.
2.	Entry Attributes
The attributes specified in this section are pulled from two standard documents:
•	ITU X.520/ISO 9594-6 “Selected Attribute Types” (1988 Version).
•	RFC 1274 “The COSINE and Internet X.500 Schema”.
The initially defined group of attributes can be regarded as a set of basic requirements for a White Pages service. The emphasis is on attributes used to describe person and role type entries, and to a lesser degree on other entry types, such as organizational unit and organization entries.
2.1	Attributes
This section describes the attributes comprising the core of the EuroView attribute schema. Not all attributes used in the specification are listed here, with the aim being to incorporate widely used attributes.
Detailed technical descriptions for any referenced attribute can be found in the documents cited above.
commonName
The commonName attribute is a generic naming attribute and is used, in particular, to name person type entries. The name (i.e. RDN value) for person entries should be initials followed by surname, e.g. A J Findlay.
surname
The surname of a person. Some specification work may have to be undertaken to standardize on the handling of “complex” surnames, e.g. O’ Brien, in order that search algorithms used by EuroView DUAs will find entries correctly and as expected.
localityName 
Entries representing localities are not considered in this document. This attribute maybe used to indicate the locality of an organization or organizational unit.
stateOrProvinceName 
This attribute specifies a state (not a country) or province. When used as a component of a directory name, it identifies a geographical subdivision in which the named object is physically located or with which it is otherwise associated. An example of this is when organizational units in an organization are distributed across a number of locations.
organizationName
This attribute is used in the directory name of organization entries.
organizationalUnitName
This attribute is used in the directory name of organizationalUnit entries. Can also be used to further describe other types of entry, for example this attribute could be used to indicate a person’s sub-group with a department.
title
The title attribute specifies the designated position or function of the object within an organization.
personalTitle
The personalTitle attribute type specifies a personal title for a person. Examples of personal titles are "Ms", "Dr", "Mlle" and "Rev".
description
The description attribute contains an informal description of the owning entry.
businessCategory
This attribute describes the type of work undertaken by an organization. A number of default values may be defined for sectoral descriptions of EuroView organizations. 
postalAddress
This attribute specifies the address of an entity as required for physical delivery of postal mail. Values of this attribute are limited to six lines of, at most, thirty characters.
telephoneNumber 
The telephoneNumber attribute type specifies a telephone number associated with a directory entry. Attribute values should follow the E.123 format for international telephone numbers, i.e., "+44 171 123 4567". Extension number may be shown suffixed to the switchboard number, e.g. +44 1895 274000 ext. 2391.
facsimileTelephoneNumber 
Contains the FAX telephone number associated with a directory entry. Attribute values should follow the E.123 format for international telephone numbers, i.e., "+44 171 123 4567".
mobileTelephoneNumber
The telephone number of a person’s mobile phone. Attribute values should follow the E.123 format for international telephone numbers, i.e., "+44 171 123 4567".
pagerTelephoneNumber
The telephone number for a pager associated with a person or role entry. Attribute values should follow the E.123 format for international telephone numbers, i.e., "+44 171 123 4567".
preferredDeliveryMethod 
This attribute states a directory entity’s preferred method of receiving communication. Typical values are MHS, physical, G3FAX, etc..
roleOccupant 
The role occupant of an entry is the person (or people) who fulfils the role defined by the owning entry. The value of this attribute must be one or more directory names.
seeAlso 
The seeAlso attribute is used to name related directory entries. An example would be a seeAlso attribute in a personal entry pointing back to an organizational role entry. 
secretary
The secretary attribute is used to name the directory entry of the secretary related to a person or other entity.
userPassword 
The userPassword attribute contains the password that the associated user uses to bind to the directory. If access control is in place then users may have certain restricted operations (e.g. the ability to modify his or her own directory entry) available to them. 
mhsORAddresses 
This attribute contains the X.400 O/R address corresponding to the owning directory entry.
userid 
The identifier used by a person to log on to the local system.
rfc822Mailbox 
The Internet mail address associated with an entry.
uniqueIdentifier 
The uniqueIdentifier attribute type specifies a "unique identifier" for an object represented in the directory.  The domain within which the identifier is unique, and the exact semantics of the identifier, are for local definition.  For a person, this might be an institution-wide payroll number. For an organisational unit, it might be a department code.
organizationalStatus 
The organizationalStatus attribute type specifies a category by which a person is often referred to in an organisation. Examples of usage in academia might include undergraduate student, researcher, lecturer, etc.
mailPreferenceOption 
This attribute is used to express a person’s policy on e-mail use by external parties, i.e. for inclusion on a mailing list. The set of values for this attribute are:
•	No list inclusion.
•	Any list inclusion.
•	Professional list inclusion.

buildingName 
The name of a building in which an organization or organizational unit is based.
accessControlList
This attribute defines the limits placed on access control for reading and update of a given entry. This attribute is specific to the Quipu implementation of X.500. This attribute will become obsolescent when implementations of the 1993 standard, and its associated access control scheme, mature.
3.	Object Types and Classes
The initial schema revision will be based on a small, but extensible, set of object types. The object type of an entry is the type of entity that the entry represents, e.g. an organization. This simple categorization is then used to define the object classes that entries of a given type should possess and thus, in turn, the set of attributes supported. 
Object types currently defined are:
•	Organizational Role
•	Person
•	Organization
•	Organizational Unit
The following sections list object classes specified for supported entry types. Attributes permitted by each object class are flagged as being “mandatory”, forced by the object class, “recommended”, a value should be provided though this is not mandatory, or “permitted” a value may be provided for the attribute. 
3.1	Object Classes and Attributes Defined for EuroView
Deviation from the standard set of object classes or attributes is inadvisable. There are two reasons for this:
•	Use of locally defined attributes especially can result in interoperability problems as remote systems will be unable to determine the syntax or semantics of the new attributes.
•	Local definitions are likely to be repeated many times in connected systems.
New definitions can however be necessitated in cases where real world data models do not fit into existing schema. Object classes and attributes so defined by EuroView are listed and justified in this section.
Attributes and objects defined for EuroView will be submitted for addition to the Internet schema.
3.1.1	Mail Addressing for Non-User Entries
The standard schema does not address the requirement for mailboxes in entries that do not have the person object class value (this only holds true for Internet style mail addresses). Organizational role entries, which may not be associated with a single person, but may require a mailbox are an illustration of this. Specific examples are entries representing help or sales desks.
A project specific object class euroviewMailUser is defined to allow the use of Internet mailboxes in such entries.
Object Class	Mandatory	Recommended	Optional	
euroviewMailUser		rfc822mailbox		
Table 1. Object Class euroviewMailUser
3.2	Common Object Classes
Four object class values are common to all EuroView data entries. The value top is fundamental to the X.500 system. Access control, with the accessControlList attribute, is included in every entry via the quipuObject object class. Each entry is also permitted to contain a WorldWideWeb URL through use of the labeledURIObject object class. Further miscellaneous attributes (jpegPhoto, audio and information) are included through the pilotObject object class value.
Object Class	Mandatory	Recommended	Optional	
top	objectClass			
labeledURLObject		labeledURL		
quipuObject	accessControlList			
pilotObject		uniqueIdentifier	jpegPhoto
audio	
Table 2. Common Object Classes and Attributes 

Organizational Role
Organizational Role entries represent a job or task performed by one or more people. The entry may contain a roleOccupant attribute containing the distinguished names of the people performing the task.
Entries of this type should be named using commonName.

Object Class	Mandatory	Recommended	Optional	
organizationalRole	commonName	roleOccupant
telephoneNumber
postalAddress
postOfficeBox 
facsimileTelephoneNumber

	seeAlso
userPassword
postOfficeBox
physicalDeliveryOfficeName
internationalISDNNumber
teletexTerminalIdentifier
telexNumber
preferredDeliveryMethod
organizationalUnitName	
euroviewMailUser		rfc822mailbox		
Table 3. Organizational Role Object Classes and Attributes
3.3	Person
Person type entries should be named using the commonName attribute.
Object Class	Mandatory 	Recommended	Optional	
person	commonName
surname	telephoneNumber
userPassword	seeAlso
	
organizationalPerson		postalAddress
facsimileTelephoneNumber
telephoneNumber
title	organizationalUnitName
physicalDeliveryOfficeName
postOfficeBox
internationalISDNNumber
preferredDeliveryMethod
teletexTerminalIdentifier
telexNumber	
newPilotPerson		rfc822mailbox
roomNumber
secretary
personalTitle
organizationalStatus
	userid
userClass
preferredDeliveryMethod
businessCategory
mobileTelephoneNumber
pagerTelephoneNumber
mailPreferenceOption	
Table 4 . Person Object Classes and Attributes

3.4	Organization
Organizations are named using the organizationName attribute.
Object Class	Mandatory	Recommended	Optional	
organization	organizationName	description
physicalDeliveryOfficeName
postalAddress
facsimileTelephoneNumber
telephoneNumber
businessCategory	stateOrProvinceName
preferredDeliveryMethod
internationalISDNNumber
teletexTerminalIdentifier
telexNumber
postOfficeBox
seeAlso
localityName	
Table 5. Organization Object Classes and Attributes

3.5	Organizational Unit
Organizational Unit entries are named using the organizationalUnitName attribute.
Object Class	Mandatory 	Recommended 	Optional	
organizationalUnit	organizationalUnitName	description
physicalDeliveryOfficeName
postalAddress
postOfficeBox
facsimileTelephoneNumber
telephoneNumber
businessCategory	stateOrProvinceName
preferredDeliveryMethod
internationalISDNNumber
teletexTerminalIdentifier
telexNumber
postOfficeBox
seeAlso
localityName	
Table 6. Organizational Unit Object Classes and Attributes
4.	Name Forms
In general entries should be named using a recognized or official form. Alternative names should be supplied, for the purposes of searching, as separate attribute values of the naming attribute. Where appropriate it is recommended that alternative language values be supplied.
The following sections associate entries with a recommended naming attribute.
4.1	Person
Person entries should be named by the commonName attribute.
The format of the name value should be the sequence of initials and then surname. Alternative values may contain the full name and, if appropriate, any other common nicknames.
In cases where names clash a multi-valued relative distinguished name should be used. A suitable attribute is uniqueIdentifier.
4.2	Organizational Role
Role entries should be named using the commonName attribute.
The name value should be the full title ascribed to the role.
4.3	Organization
Organization entries are named by the organizationName attribute. 
National entities usually have an official organization name registered with a national name registration body. The official name must be used as the naming value. Alternative names, i.g. commonly used abbreviations, may be listed as extra values.
4.4	Organizational Unit
Departmental entries should be named using the organizationalUnitName attribute.
The name value should be the full name of the department. 
5.	Example Directory Tree
This section describes a useful DIT serving an organization with the following requirements:
•	A comprehensive White Pages database, i.e. a directory entry for all computer users.
•	A functional or task mapping.
•	A list of public contacts.
So, in effect, three different views of the organization are available in one directory tree, with public availability possibly being limited by access control.
The structure depicted in Figure 1 is suggested. Any given DIT has its pros and cons, though the following issues should be considered when designing the tree structure:
Data Management In large or distributed organizations local manageability of data can be an important issue, for example a department may be in a better position to maintain data relating to its own people. This is closely related to the access control management issue described below.
Access Control The access control model is flexible enough to cater for most situations. However the shape of a local DIT can go a long way to simplifying the complexity, and therefore manageability, of an access control scheme. This is particularly true of the model suggested in the 1993 version of the X.500 standard.
Searchability In the Quipu implementation used by EuroView subtree searches are demonstrably faster in DITs with fewer levels of hierarchy.
Browsability This is of importance to organizations that wish to reflect an internal hierarchy that is easily navigable by external data users.
Database Size The amount of data will, usually for management and efficiency reasons, reflect on the data hierarchy used. In cases where there a large number of people exist in an organization, a departmental layer may be deemed necessary.

Figure 1. Example Directory Information Tree

5.1	Some Concrete Examples
This section outlines a few example entries that illustrate the above scheme.
5.1.1	Organizational Role
This is an internal entry (i.e. not publicly visible). The example in Figure 2 depicts a role entry that points to the role occupant’s personal entry using the roleOccupant attribute. The personal entry points back to the role entry via the seeAlso attribute.
In this example the role entry is held under a placeholder entry, cn=Roles. This has the advantage of simplifying access control for the complete set of role entries, though has the disadvantage of reducing ‘searchability’, as users may search for the cn=Head of Networking role in its ‘logical’ position below the ou=Computing and Media Services entry.

Figure 2. Example of an Organizational Role Entry

5.1.2	Public Contact
This entry is intended for the consumption of external directory users. In this example the contact entry has a roleOccupant attribute that points to a personal entry within the organization. Access control may, of course, limit external access to the personal entry, according to local policy.

Figure 3. Example of a Public Contact Entry

6.	Appendix A - EuroView Object Identifier Branch
New attributes and object classes defined by the EuroView project will be defined as a sub-branch of the Brunel University Computer Centre object identifier branch. The numeric representation of the EuroView branch is then:
euroView	1.2.826.0.1051.0.2	
Attributes and object classes will be placed under sub-branches:
euroViewAttribut	euroView.1	
euroViewObjectClass	euroView.2	
7.	
Appendix B - EuroView Defined Object Classes

euroviewMailUser OBJECT-CLASS ::= {
	SUBCLASS OF	{ top }
	KIND	auxiliary
	MAY CONTAIN	{ rfc822mailbox }
	ID	euroviewObjectClass.1
}

PART IV
1.		References

ITU X.500/ISO 9594 “The Directory - Overview of Concepts, Models and Services”.
RFC 1274 “The COSINE and Internet X.500 Schemas” P. Barker, S. Kille. University College London. November 1991.