Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting to switch on vCard 4 production #334

Open
spoorun opened this issue Feb 6, 2021 · 1 comment
Open

Setting to switch on vCard 4 production #334

spoorun opened this issue Feb 6, 2021 · 1 comment

Comments

@spoorun
Copy link

spoorun commented Feb 6, 2021

Currently rcmcarddav produces vCard 3 cards, could there be a setting or simple way to turn on vCard 4 support (for example in our case we only use vCard 4 syncing via DAVx5 to Android and Nextcloud all using vCard 4 properties and cards.

@mstilkerich
Copy link
Owner

Hello,

is there anything that is currently not working for you with the v3 cards produced by RCMCardDAV? RCMCardDAV should import and update v4 vcards just fine, although it might ignore / not properly update some properties that did not exist in v3 and where RCMCardDAV relies on X- non-standard properties rather than the v4 standard properties (see below).

The reason why RCMCardDAV still uses v3 is simply because it has the best operability with other applications and servers. v3 is the version that any CardDAV server must support. Sabre/DAV based servers (Baïkal, Nextcloud, Owncloud) are the only ones that advertise support for v4.

From what I currently know, everything that can be entered in roundcube for a VCard can be represented in a v3 VCard. Some of the more special (by special I mean rarely used) properties like gender and anniversary have been added in v4, and RCMCardDAV maps them to the corresponding X- properties. From what I have observed, however, these X- properties tend to be as well if not better supported by addressbook applications than the standard properties in v4.

The most interesting feature from my point of view in v4 is the standardized support for KIND=group vcards. However, those appear to be only used in Apple ecosystems, and Apple still uses its custom extension predating the adaption by vcard v4 and does not understand the standardized properties in v4, so at this point moving to v4 would break group interoperability with apple clients. You can find a detailed writeup on that in #331. The rest of the world seems to use the CATEGORIES property to represent groups, whether they use v4 cards or not (this includes Nextcloud), so they would not benefit from the v4 groups either.

So yeah, in general of course I would be open to add support for v4 if it brings some benefit, but at the moment I mostly see added complexity and things that will not work anymore, whereas I see little that would work which now does not. It would require to be an optional setting (because of interoperability issues with other applications not supporting v4), so it means an additional variant to maintain. It is also one of those settings (similar to KIND=group vcard style groups vs CATEGORIES-style groups) that most users will not know what the right choice for them would be. Many would probably check v4 because it's the newer version, albeit from what I currently know v3 offers the better interoperability with other applications.

However, if you really have a use case, I'd be willing to go down that road. (As a side note, I'm not an Android user, and so I have specifically no own experiences with Android addressbook applications and DAVx5)

@mstilkerich mstilkerich added this to the 5.1.0 milestone Dec 27, 2022
@mstilkerich mstilkerich removed this from the 5.1.0 milestone Aug 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants