VCard 3.0 support


  • developer

    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.



  • 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.


  • developer

    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.



  • 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.


  • developer

    @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


  • developer

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



  • 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?


  • developer

    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).



  • Ok, thank you for clarification.

    Can't wait to test it... :-)


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.