Re: Surnames and indexing white pages

Andrew Findlay <Andrew.Findlay@brunel.ac.uk> Tue, 17 August 1993 11:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01174; 17 Aug 93 7:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01170; 17 Aug 93 7:30 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03674; 17 Aug 93 7:30 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02891-0@haig.cs.ucl.ac.uk>; Tue, 17 Aug 1993 11:58:41 +0100
Via: uk.ac.brunel; Tue, 17 Aug 1993 11:58:27 +0100
Received: from molnir.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) id <11996-0@sirius.brunel.ac.uk>; Tue, 17 Aug 1993 11:57:22 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Findlay <Andrew.Findlay@brunel.ac.uk>
Message-Id: <23484.9308171057@molnir.brunel.ac.uk>
Subject: Re: Surnames and indexing white pages
To: john@citr.uq.oz.au
Date: Tue, 17 Aug 1993 11:57:05 +0100 (BST)
Cc: osi-ds@cs.ucl.ac.uk
In-Reply-To: <8362.9308170205@lemon> from "john@citr.uq.oz.au" at Aug 17, 93 12:05:17 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2890
X-Orig-Sender: Andrew.Findlay@brunel.ac.uk

>The problem is that while the Person object class contains the Surname
>as a mandatory attribute, in some cultures there is no concept of a surname, 
>and therefore there will be some difficulty in getting acceptance of the
>directory by people of these cultures.

Problems like this are almost inevitable in any international standard
that relates to people. It is impossible to get knowledge of all
cultures into every standards committee.

A reasonable solution in this case might be to have a NULL value for
the surname attribute, or to put in the most commonly-used name
component (as in your example below)

>His full name (the common name attribute) consists of five components. 
>Some components are taken from names in the Koran (he is Islamic), some
>are taken from names of significant people among his family and friends.
>Although one of the components in his name is also one of the components
>in his father's name (in honour of his father), none of the five components 
>are consistently handed down from one generation to the next.

>The first step to solving the mandatory surname problem, is to change the
>Person object class so that Surname is optional. Has anybody thought
>about this? It would sure make the X.500 standard more acceptable to 
>people of some cultures.

It would also break a lot of existing implementations. Far better to
go along with the standard that exists but to use a null value or
follow som other convention (like the `single space' convention for
ADMDs in X.400).

>The next issue is the construction of white pages directories when there
>is no surname. Does anybody know how the telephone white pages are organised
>in countries with these types of people? 
>
>I think that my friend said that the telephone book contained the person's 
>full name (or subsets of it as he, for example, rarely uses all five of his 
>components). I pointed out to him that his preferred name (i.e. the component 
>that he prefers friends to use on a daily basis) is the part known to most of 
>his friends, but is not the first component in his name, 
>therefore it would be hard to find his entry in the telephone book. He replied 
>that the telephone subscriber simply requested an order of the names 
>(components) so that people were most likely to find their entry, and could 
>have multiple listings with different orderings if they wished.

That is no problem with X.500 as CommonName would hold the complete
name as one of its values and user-agents could locate the entry by
substring searches.

>					-- regards, John Gottschalk

Andrew

----------------------------------------------------------------------------
|      From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK     |
| Andrew.Findlay@brunel.ac.uk       +44 895 203066 or +44 895 274000 x2512 |
----------------------------------------------------------------------------