From: Boris Kraut Date: Fri, 03 Jan 2014 00:01:26 +0100 Category: Message-ID: <20140103000126.uLh9wQ@trauerweide> Organization: Keywords: Comments: To: undisclosed-recipients: ; Subject: [.plan] vCard 4.0 und die URIs... Reply-To: Boris Kraut 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:mail@foo.local" 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:foobar@foo.local X-COMMUNICATION:TYPE=voice,video:sip:foobar@foo.local 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.