Subject: [.plan] vCard 4.0 und die URIs...
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Fri, 03 Jan 2014 00:01:26 +0100

Eigentlich hatte ich das Thema Kontaktverwaltung fuer mich endgueltig
geklaert: ueber Git versioniertes vCard4. Das Problem dabei war, dass
es momentan noch ziemlich wenig Anwendungen gibt, die vCard4 nativ
sprechen. Also begann ich einen Kontakteditor, den ich vor Urzeiten
mal begonnen hatte, zu erneuern und an den neuen Standard anzupassen.

Leider ist das leichter gesagt, als getan, und mir wurde mal wieder
klar, warum es so viele Programme gibt, die zwar einen Import bzw.
Export anbieten, aber die eigentlichen in einem eigenen Format vor-
halten. Natuerlich sind es auch Performanceueberlegungen, aber es
ist wirklich reines PITA, einen Standard -- fuer den es nichtmal so
etwas wie ein Validator gibt -- richtig und insbesondere komplett
umzusetzen. Der logischer Ausweg ist, dass man nur eine Sparversion
nutzt, d.h. konkret, dass beim Export valides vCard4 rausfaellt,
das eben bestimmte Funktionen nicht nutzt, aber man beim Import die
Ansage macht, dass man fuer nicht unterstuetzte Funktionen eben
nichts garantieren kann -- bei vCard ist es relativ einfach, un-
bekannte Dinge einfach zu ignorieren und trotzdem in der Datei mit-
zuschleifen.

Ich selbst habe mir also erstmal Gedanken gemacht, was fuer mich
wichtig waere zu unterstuetzen und wie ich mit welchen Eigenschaften
umgehe. Dabei sind mir einige Punkte aufgefallen, die einfach nicht
mehr so wirklich einen Sinn machen. Wo z.B. "EMAIL:[email-masked]"
und "TEL:0123456789" zwei absolut nachvollziehbare Elemente waren,
sind deren URI-Varianten (mailto: bzw. tel:) doppeltgemoppelt. Und
so kommt es, dass man zwar alle IM-Programme einheitlich unter dem
Feld "IMPP:" zusammenfasst, die anhand des Schemanamens entsprechend
zugeordnet werden, aber bei alteingebrachten Feldern diese Zusammen-
fassung nicht gemacht hat -- jaja, Kompatibilitaet.

Um mal das Problem zu verdeutlichen das Beispiel SIP. Eigentlich
wird es im RFC unter IMPP abgelegt, aber es heisst auch:

> If this property's value is a URI that can be used for voice
> and/or video, the TEL property (Section 6.4.1) SHOULD be used
> in addition to this property.

D.h. eigentlich werden die Eigenschaftsnamen hier ueberladen. TEL
heisst eben nicht mehr Telefon, sondern "Audio/Video-Synchron-
Uebertragung".

Um noch mehr Verwirrung zu stiften, gibt es zu den Eigenschafts-
feldern auch noch Parameter, mit denen man u.a. die Features eines
Eintrags beschrieben kann -- z.B. "cell" fuer Mobiltelefone. Und
imho gehoert die o.g. Ueberladung der genau hier her, so dass
wir am Ende eine Liste von URIs haben, die der jeweiligen Person
zugeordnet werden, und jeweils mit entsprechenden Verwednungs-
zwecken in den Parametern genauer beschrieben werden, also sowas
wie:

X-COMMUNICATION:TYPE=text:mailto:[email-masked]
X-COMMUNICATION:TYPE=voice,video:sip:[email-masked]
X-COMMUNICATION;TYPE=voice,text:tel:0123456789

Die Frage ist natuerlich, was uebrig bleibt, wenn man vCards auf
so eine Syntax runterkuerzt. Insbesondere wenn man auch Bilder
o.ae. als URI schreibt und darauf baut, dass es auch irgendwann
Zeit- und Postadress-URIs gibt, wird es wohl eher zu...

scheme:uri tag1 tag2 tag3

... mutieren. Im Endeffekt sind es also zwei Neuerungen, die eine
entsprechende Aenderung nahelegen:

 1) URIs geben ein unvierselles Adressierungsschema vor, diese
    Information muss nicht im Property gespeichert werden.
 2) Da es immer mehr multi-purpose Geraete und Protokolle gibt,
    macht es mehr Sinn Faehigkeiten der Adresse zuzuweisen als
    eine Adresse mehrfach unter Properties zu speichern, die
    diese Faehigkeiten abbilden.

Tja, nur schade, dass aufgrund von Kompatibilitaet -- vCard2.1
ist immer noch weitverbreitet (und teilweise gar nicht so falsch)
-- so etwas nicht durchsetzten wird. Aber da ich selbst bei meiner
Nutzung von vCard4 schon massiv ins Leere laufe, muss ich mir mal
ueberlegen, ob ich selbst zu einem eigenen Format konvertiere.