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. _______________________________________________ Evolution-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-list
