Introduction

Entries in KDE address databases are stored in key-value-pairs with different data types. Every part of an address or personal in general is mapped to such a key-value-pair. For inter-application portability, the valid keys in such a key-value-map need to be defined. This page gives an overview over all field names and types used by KDE address book entries:
Field Key
Literal Field Name
Field Meaning
Data Type
Encoding
X-First_Name First Name The first name of the person. kde-string Unicode string
X-Middle_Name Middle Name The middle name of the person. kde-string Unicode string
X-Last_Name Last Name The last name of the person. kde-string Unicode string
X-Org Organization
X-Department Department
X-OfficeLocation Office
X-Role Role
X-Headline_1 (none) The description for the address ("Home", "Weekend", whatever).
X-Street_1 Street Street for the first address.
X-ZIP_1 Zip/Postal Code
X-City_1 City/Town
X-Country_1 Country
X-State_1 State/Province
(repeat X-Headline to X-State 4 times to get five addresses)
X-Title Title Titles are academic degrees, for example.
X-Rank Rank Military or police officers ranks, also used on ships.
X-Birthday Birthday
X-Comment (None) An optionally free-form note about the person.
X-Email_1 Email Address 1 The first email address. Up to 5 are supported.
(repeat X-Email _X four times)
X-Talk_1 Talk Address 1 The first email address. Up to 5 are supported.
(repeat X-Talk_X four times)
X-URL_1 Home Page Address 1
(repeat X_URL_X four times)
X-Telephone_1 Telephone Number 1
(repeat X-Telephone_X four times)
The following notes should guide through the columns of the table.

Field Key

The field key is used to find the value. Thus, it needs to be identifying. In every entry, all keys may be inserted only one time (in STL terms, the entries are maps, not sets). As a guideline, all valid C++ identifiers may be used as field keys.

Literal field Name

This values have been defined to make sure each application uses the same names for different fields. This should make it easier for the applications users to find what they look for.

Some Notes

This notes might be removed after the field names are standardized.

Number of Addresses

In this overview, the number of addresses is no more fixed by a special value (like MAX_ADDRESSES in the former class "Entry"). There are simply (currently) 3 fields named X-Street_1, X-Street_2, and X-Street_3.
Also, addresses, by now, do not have types like business, home, or other. It would probably be a good idea to give some patterns when entering the headline, but allow the user to select other names, too. This way addresses may be sorted in other categories than the programmer is able to anticipate :-)

Telephone Numbers

I would opt for the following way to store telephone (and related) numbers: The apps would have to parse this and find the type.

The very special Fields

It is a matter of agreement what fields are declared to be a standard and what would be application-specific extensions.
I chose it the following way: Everything that is part of the persons attributes and that we already thought of is a standard field, and everything completely unusable by other applications must be an application-specific extension.
The reason is explainable by the following examples: As a consequence, we will have to add more attributes that we currently not think of later. But this should be no problem.