VCard 3.0 support

[rfc2822]

By RFC 6352 6.2.2 “CARDDAV:supported-address-data Property”, CardDAV servers MUST accept VCard 3.0 and only MAY accept 4.0. However, DAVdroid always sends VCard 4.

Strictly speaking this is a bug, but I will consider it as an enhancement to detect whether the server is VCard 4-capable and then choose the right format because most servers/clients understand VCard 4 today.

[AutoImport-jtru]

Is there a technical reason/design decision for DAVdroid to send/store V4 only? I was bitten by that yesterday, as another client I use to access my CalDAV/CardDAV (CardDavMATE) server of choice (radicale 0.8) would only handle VCard version 3. The on-disk data radicale generates from DAVdroid’s requests doesn’t look like it would require any VCard 4-specific features, though.

[rfc2822]

The reason is that I didn’t find a good iCal/VCard library (I tried several ones) until I found iCal4j. iCal4j, originally for iCal only, has a VCard plugin that works the same way and provided good results, so I decided to use it. Unfortunately, it only speaks VCard 4 and when I realized that VCard 3 was required (3 days ago), iCal4j-vcard was already completely integrated. So, the solution will be to either add another library or replace iCal4j-vcard by another library or extend iCal4j-Vcard to parse/generate VCard 3, but I will do so when other things are going round. This is why I consider this as an enhancement although it is, as by RFC 6352, a bug (standards violation) to not support VCard 3.

[AutoImport-jtru]

What I also noticed yesterday while hacking on radicale and CardDavMATE in regard to VCard 3.0:

When a client stores a record of the <b>EMAIL</b> type in a VCard , it might supply some kind of qualifier (I’m not familiar with the VCard lingo, so that’s probably named differently in the standard :)) like <b>TYPE=INTERNET</b>. If that’s the case, DAVdroid loses any such association like “work” or “home” for that record when syncing.

[rfc2822]

@jtru The VCard/Android translation is not 1:1 because of the different storage schemes (database column vs type list). See https://github.com/rfc2822/davdroid/blob/1e00ed217fcc8dab1244ea7e39a6f1d2c9f29c5c/src/at/bitfire/davdroid/resource/LocalAddressBook.java#L166 for Android → VCard and https://github.com/rfc2822/davdroid/blob/1e00ed217fcc8dab1244ea7e39a6f1d2c9f29c5c/src/at/bitfire/davdroid/resource/LocalAddressBook.java#L405 for VCard → Android. I think the translation should make sense in most cases, but I’m also sure that there’s much room for optimisation

Edit: wrong line numbers

[rfc2822]

VCard 3 will come soon By using ez-vcard (again)

[AutoImport-phsc]

Just out of curiosity:
With release 0.3 of DAVdroid you replaced ez-vcard with ical4j-vcard. Now you switch back to ez-vcard.
Why did you replace ez-vcard in release 0.3? Does ez-vcard have some disadvantages compared to ical4j-vcard?

[rfc2822]

I wasn’t aware that VCard 3 would be needed and felt better with only “one” dependency (ical4j + ical4j-vcard) instead of two (ical4j + ez-vcard).

[AutoImport-phsc]

Ok, thank you for clarification.

Can’t wait to test it…