Comment 7 for bug 571286

Well. We just discussed this a bit on IRC and I would like to highlight the following:

a) vCard is an established standard that defines free-form address data without ext
b) as far as we (that is me and a KDE gentoo developer) can see, akonadi will support phone sync via syncml (an established standard), and syncml enforces exchange of contact data via vCard (an even more established standard). (that said I wonder why the fdo spec cant implement vcard to begin with)
c) I do not see how implementations that by design do not have an ext field can support this without actually following the change
d) each mail client and groupware and essentially any addressbook software on the market can handle vcard, and vcard does not have such a silly ext thingy

In a more specific scenario:
http://api.kde.org/4.4-api/kdepimlibs-apidocs/kabc/html/classKABC_1_1Addressee.html
KDE's contact implementation does not implement any kind of ext field so options are:
1. change KDE to support ext
2. not show that data
3. mess with the data to squeeze it into KDE's free-form street label and then extract it again for sync

1 is simply stupid since it basically suggest that every contact application that would want to use coudb/u1 and does not have an ext field, would also have to change around. 2 is really not much different from loss of data. 3 is a major headache and bound to end up in data loss from bugs.

We agreed that the only viable options are:
* Have u1 implement abstraction, instead of doing it for each client - syncml can, so why should u1 not be able to
* fix Funambol