Re: [Evolution] names change using LDAP

[Adam Tauno Williams <awilliam opengroupware us>]

On Sun, 2009-10-11 at 23:52 -0430, Patrick O'Callaghan wrote:
> On Sun, 2009-10-11 at 20:46 +0200, Lars Schade wrote:
> > To illustrate the issue I start with a local addressbook and add a new
> > contact using the evolution GUI say for the Berlin Office of a company
> > called "The Big Wheel", and I fill in the name dialog as given name
> > "Berlin Office" and as family name "The Big Wheel". It is displayed as
> > "The Big Wheel, Berlin Office" exactly what I want. I can use the this
> > information to automatically generate address labels with openoffice,
> > everything perfect.
> I'm not very knowledgable about LDAP, but it looks to me like you're
> using it incorrectly. Using the Name subfields (First, Middle, Last,
> Suffix) to stand for Office/Company is bound to lead to trouble, if not
> within Evo then elsewhere you might want to use LDAP records. The field
> names are there for a reason and some apps attach semantic meaning to
> them. For example a Name with a space in it can legitimately be
> interpreted as two names, where the second one can be represented by an
> initial. This makes perfect sense for given names and makes no sense for
> the name of a company.
> You should reconsider how you're using LDAP. The key thing to remember
> is that a "contact" is meant to represent a person, not a company.

All this is true - as a user you are over a barrel however.  I spend a
lot of time working with vCard data - to be blunt: the vCard (RFC2426)
spec is lame.  But it is everywhere and what we [sadly] have to live
with.  A vCard represents a *PERSON*,  there isn't any good [or
standard] way to represent an Enterprise (company, organization, ....).
The "FN" is the name of the vCard and corresponds to the "CN" (common
name) attribute in LDAP.  That is OK.  *BUT* the spec also *requires*
"N" which is a composite value of "Family Name, Given Name, Additional
Names, Honorific Prefixes, and Honorific Suffixes"  Of course that makes
no sense for a vCard that isn't a contact - but the client *must* shove
something in at least on of those fields.  This isn't Evolution's fault
- the spec is retarded.  [The required attributes for a vCard are: FN,
N, and VERSION.  Many implementations have a tacit requirement for UID
as well].  Evolution's internal data model is [reasonably] based on the
vCard spec as is that of Thunderous Crap, KDE's PIM (is it still called
Kontact?) , as well as most other PIMs.  Outlook has the same problem.
You need to use a "real" groupware client to avoid this lameness.