1 From: Boris Kraut <krt@nurfuerspam.de>
\r
2 Date: Fri, 03 Jan 2014 00:01:26 +0100
\r
4 Message-ID: <20140103000126.uLh9wQ@trauerweide>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: [.plan] vCard 4.0 und die URIs...
\r
10 Reply-To: Boris Kraut <krt@nurfuerspam.de>
\r
12 Eigentlich hatte ich das Thema Kontaktverwaltung fuer mich endgueltig
\r
13 geklaert: ueber Git versioniertes vCard4. Das Problem dabei war, dass
\r
14 es momentan noch ziemlich wenig Anwendungen gibt, die vCard4 nativ
\r
15 sprechen. Also begann ich einen Kontakteditor, den ich vor Urzeiten
\r
16 mal begonnen hatte, zu erneuern und an den neuen Standard anzupassen.
\r
18 Leider ist das leichter gesagt, als getan, und mir wurde mal wieder
\r
19 klar, warum es so viele Programme gibt, die zwar einen Import bzw.
\r
20 Export anbieten, aber die eigentlichen in einem eigenen Format vor-
\r
21 halten. Natuerlich sind es auch Performanceueberlegungen, aber es
\r
22 ist wirklich reines PITA, einen Standard -- fuer den es nichtmal so
\r
23 etwas wie ein Validator gibt -- richtig und insbesondere komplett
\r
24 umzusetzen. Der logischer Ausweg ist, dass man nur eine Sparversion
\r
25 nutzt, d.h. konkret, dass beim Export valides vCard4 rausfaellt,
\r
26 das eben bestimmte Funktionen nicht nutzt, aber man beim Import die
\r
27 Ansage macht, dass man fuer nicht unterstuetzte Funktionen eben
\r
28 nichts garantieren kann -- bei vCard ist es relativ einfach, un-
\r
29 bekannte Dinge einfach zu ignorieren und trotzdem in der Datei mit-
\r
32 Ich selbst habe mir also erstmal Gedanken gemacht, was fuer mich
\r
33 wichtig waere zu unterstuetzen und wie ich mit welchen Eigenschaften
\r
34 umgehe. Dabei sind mir einige Punkte aufgefallen, die einfach nicht
\r
35 mehr so wirklich einen Sinn machen. Wo z.B. "EMAIL:mail@foo.local"
\r
36 und "TEL:0123456789" zwei absolut nachvollziehbare Elemente waren,
\r
37 sind deren URI-Varianten (mailto: bzw. tel:) doppeltgemoppelt. Und
\r
38 so kommt es, dass man zwar alle IM-Programme einheitlich unter dem
\r
39 Feld "IMPP:" zusammenfasst, die anhand des Schemanamens entsprechend
\r
40 zugeordnet werden, aber bei alteingebrachten Feldern diese Zusammen-
\r
41 fassung nicht gemacht hat -- jaja, Kompatibilitaet.
\r
43 Um mal das Problem zu verdeutlichen das Beispiel SIP. Eigentlich
\r
44 wird es im RFC unter IMPP abgelegt, aber es heisst auch:
\r
46 > If this property's value is a URI that can be used for voice
\r
47 > and/or video, the TEL property (Section 6.4.1) SHOULD be used
\r
48 > in addition to this property.
\r
50 D.h. eigentlich werden die Eigenschaftsnamen hier ueberladen. TEL
\r
51 heisst eben nicht mehr Telefon, sondern "Audio/Video-Synchron-
\r
54 Um noch mehr Verwirrung zu stiften, gibt es zu den Eigenschafts-
\r
55 feldern auch noch Parameter, mit denen man u.a. die Features eines
\r
56 Eintrags beschrieben kann -- z.B. "cell" fuer Mobiltelefone. Und
\r
57 imho gehoert die o.g. Ueberladung der genau hier her, so dass
\r
58 wir am Ende eine Liste von URIs haben, die der jeweiligen Person
\r
59 zugeordnet werden, und jeweils mit entsprechenden Verwednungs-
\r
60 zwecken in den Parametern genauer beschrieben werden, also sowas
\r
63 X-COMMUNICATION:TYPE=text:mailto:foobar@foo.local
\r
64 X-COMMUNICATION:TYPE=voice,video:sip:foobar@foo.local
\r
65 X-COMMUNICATION;TYPE=voice,text:tel:0123456789
\r
67 Die Frage ist natuerlich, was uebrig bleibt, wenn man vCards auf
\r
68 so eine Syntax runterkuerzt. Insbesondere wenn man auch Bilder
\r
69 o.ae. als URI schreibt und darauf baut, dass es auch irgendwann
\r
70 Zeit- und Postadress-URIs gibt, wird es wohl eher zu...
\r
72 scheme:uri tag1 tag2 tag3
\r
74 ... mutieren. Im Endeffekt sind es also zwei Neuerungen, die eine
\r
75 entsprechende Aenderung nahelegen:
\r
77 1) URIs geben ein unvierselles Adressierungsschema vor, diese
\r
78 Information muss nicht im Property gespeichert werden.
\r
79 2) Da es immer mehr multi-purpose Geraete und Protokolle gibt,
\r
80 macht es mehr Sinn Faehigkeiten der Adresse zuzuweisen als
\r
81 eine Adresse mehrfach unter Properties zu speichern, die
\r
82 diese Faehigkeiten abbilden.
\r
84 Tja, nur schade, dass aufgrund von Kompatibilitaet -- vCard2.1
\r
85 ist immer noch weitverbreitet (und teilweise gar nicht so falsch)
\r
86 -- so etwas nicht durchsetzten wird. Aber da ich selbst bei meiner
\r
87 Nutzung von vCard4 schon massiv ins Leere laufe, muss ich mir mal
\r
88 ueberlegen, ob ich selbst zu einem eigenen Format konvertiere.
\r
projects / krt-msg / blob