KEP-0013.txt

[Georg Greve]

 KEP-0013.txt |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

New commits:
commit 72d8338488cc8937ea22a361914e7a498cb7278b
Author: Georg Greve <greve at kolabsys.com>
Date:   Mon Aug 29 15:15:20 2011 +0200

    One riddle solved, x-kde-type now known thanks to Alec

diff --git a/KEP-0013.txt b/KEP-0013.txt
index a0e9da5..a319bcb 100644
--- a/KEP-0013.txt
+++ b/KEP-0013.txt
@@ -108,8 +108,7 @@ with the following specification of field values:
 
 ==== TODO: Need definition / clarification ====
 * fields referring to other people - ideally linking to other records, how? use email as identifier?
-* find out what the x-kde-type means (see example in [[#Issues|Issues]])
-
+* '''x-kde-type''' was introduced as part of a hotfix for Issue #1706<ref name="x-kde-type">Kolab Issue #1706: [https://issues.kolab.org/issue1706 addressbook: real address type is broken)]</ref> and thus found its way into the KDE SVN<ref name="x-kde-type-svn">KDE: [http://websvn.kde.org/branches/kdepim/enterprise/kdelibs/kabc/address.h?view=markup#l78 WebSVN]</ref> but was never documented. Question: Do we still need this?
 
 == Upgrade Path ==
 
@@ -220,7 +219,7 @@ Apparent issues when comparing this to the specification of version 1.0 Kolab XM
 * Kolab Format 2.0 does not foresee that many people have multiple roles & affiliations;
 * Kolab Format 2.0 only allows a single instance of the 'mobile' phone type. Kontact has ignored this to save three mobile phone numbers, which is a good thing to do, because having more than one mobile phone number is quite common these days;
 * Kolab Format 2.0 states: ''"The Kontact and Horde address books have the notion of a preferred email address. This could be done by a bool on the emails or a separate tag like for preferred address."'' While clients '''could''' have done it this way, Kontact clearly did not. Instead it resorted the email addresses to put the preferred one on top. There should be a clear and canonical way of handling this;
-* Kolab Format 2.0 is not explicit on whether or not multiple addresses of one type, e.g. 'home' are allowed or forbidden, so Kontact allows to create and store them. The 'preferred-address' field then refers to the '''type''' of address, which would suggest that only one address per type was foreseen because like this it is not clear '''which''' home address is preferred. And finally there is a field 'x-kde-type' which is undefined in the Kolab Format 2.0 and thus cannot be supported by other clients;
+* Kolab Format 2.0 is not explicit on whether or not multiple addresses of one type, e.g. 'home' are allowed or forbidden, so Kontact allows to create and store them. The 'preferred-address' field then refers to the '''type''' of address, which would suggest that only one address per type was foreseen because like this it is not clear '''which''' home address is preferred. And finally there is a field 'x-kde-type'<ref name="x-kde-type" /><ref name="x-kde-type-svn" /> which is undefined in the Kolab Format 2.0 and thus cannot be supported by other clients;
 * Kolab Format 2.0 does not know crypto preferences even though cryptography is one of the unique advantages that the Kolab Groupware Solution has to offer;
 * Kolab Format 2.0 only supports one web page field even though most people have multiple profiles & pages;
 * The fields referring to other people, possibly other records in the address book, are string fields only and thus fail to semantically link the data;