Remove quotes from TYPE for better external platforms compatibility

[ghost]

This is a resubmit as I ended up doing more investigation following a switch to using Google Contacts due to this problem - during the switch, I had to manually edit the VCF file to get it to work with Gmail.

The VCF file produced by Contacts doesn't use fields recognised by other applications and appears to be non-standard. As it currently stands, it appears Contacts is incompatible with all other major platforms.

Nextcloud 16.0.1, Contacts 3.1.1

Example:

1. New contact created in the web app, with a phone number and email. The type (e.g. home, office) is left on the defaults.

2. The contact is downloaded through the web app (.VCF file).

3. The file is opened in Outlook, revealing a missing phone number.

4. The file is imported to gmail, again revealing a missing phone number.

5. Sync to iOS also reveals a missing phone number.

6. Opening the VCF in ATOM reveals the field names. You can see email has the type HOME but phone has (quotes included as in the file) "HOME,VOICE".

7. Removing ,VOICE and the quotation marks to leave the type as HOME results in Gmail and Outlook now seeing the phone number.

[skjnldsv]

Right, we should remove the quotations for compatibility. :)

Thanks for reporting!

[giddyhup]

This is also happening with the popular productivity/email program eM Client.

[giddyhup]

If I read it correctly, there were fixes to https://github.com/mozilla-comm/ical.js/issues/343 but that issue hasn't been closed yet. Is there hope that the fixes find their way to Nextcloud Contacts?

[skjnldsv]

@giddyhup Maybe, but we really need https://github.com/mozilla-comm/ical.js/issues/343

[giddyhup]

ACK. Understood.

[giddyhup]

I looked into the topic again and would like to share my observations. According to RFC 6350 section 6.4.1 both ways to represent phone number types are okay:

The default type is "voice". These type parameter values can be specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a value list (e.g., TYPE="text,voice").

In my tests my clients support parameter lists and have problems with value lists. The issue occurs since the Contacts app changes the parameter representation. Also, something like TEL;type=CELL;type=VOICE;type=pref: 555 1234 appears as undefined phone number in the web interface. When there are modifications to the address via the web interface in the synced VCard we only find TEL;TYPE=pref:555 1234.

[skjnldsv]

Yes, because the library we're using does not understand multiple parameters

[giddyhup]

Sorry, I now have the whole picture. I just went down the rabbit hole and and also found the pull request from April 5 which probably would fix it. : (

[giddyhup]

The pull request has been merged! Yay!

[ghost]

@giddyhup Do you know when it will be released?

[giddyhup]

@a1pilot nope. One needs to watch the respective repository. The last release was in 2018 and the one before that was in 2016. Then it is up to the Nextcloud/contacts maintainers to include it in their release. I assume that together can take some months.

[Timokirch]

Hey, there was a new release :) That‘s the best easter present this year.

[giddyhup]

In this repository, package.json references ical.js v1.4 (Mozzilla's recently released version with the fix). Does this mean version 3.2.0 of the Nextcloud contacts already includes the fix? Can we close the issue?

[Timokirch]

For me there are still errors if i modify a contact on an ios device and looking at the object over the web browser.

[skjnldsv]

In this repository, package.json references ical.js v1.4 (Mozzilla's recently released version with the fix). Does this mean version 3.2.0 of the Nextcloud contacts already includes the fix? Can we close the issue?

no it means I need to release a new version :) Would you be willing to test it here?

[skjnldsv]

Please help test the new release (link in first post): https://github.com/nextcloud/contacts/pull/1579

[giddyhup]

Is there a testing procedure? Can the respective existing app folder simply renamed and the new folder put in its place instead?

[skjnldsv]

You can replace the app with this archive. If anything happens, delete it and reinstall contacts through the appstore as usual :)

[giddyhup]

Ok, I am testing. I can't tell if it is related to this release and to this issue but here it goes (just tell me if I should open a new issue).

One contact renders my Windows client (EM client) unresponsive when I try to add the downloaded vcf file manually (it won't get synced automatically).

An address appears in the web form in one field, in the vcf it appears like this: item2.ADR;type=HOME;type=pref:;;STREET;TOWN;;ZIP;COUNTRY Phone number entries appear like this: TEL;TYPE="HOME,VOICE";VALUE=UNKNOWN:+1 555 1234567

Again, I don't know if this is related to the fix. Also, the entries have also been edited under iOS and the changes may come from there.

[skjnldsv]

item2.ADR;type=HOME;type=pref:;;STREET;TOWN;;ZIP;COUNTRY

We don't support type pref, so it's not coming from nextcloud here. :/

Phone number entries appear like this: TEL;TYPE="HOME,VOICE";VALUE=UNKNOWN:+1 555 1234567

Same for this one, but that might be a bug, no idea. What happen if you open the contact on nextcloud? And edit it maybe?

Though this was supposed to fix the multiple types like TYPE=HOME,VOICE => TYPE=HOME,TYPE=VOICE, any similar contacts?

[giddyhup]

I'm directly downloading VFC files from the Contacts interface, I don't see the fixes in the raw file: TEL;TYPE="IPHONE,CELL,VOICE":

in eM Client's GUI this turns into

Here, I have to assume that is also related to the "pref":

ITEM1.EMAIL;TYPE="INTERNET,pref":jane_doe@example.com
ITEM1.X-ABLABEL:_$!<Other>!$_

[skjnldsv]

It looks like your em client is not compatible with new vcards syntax :/

[giddyhup]

Yeah, you are right. I'll take that out of the equation. (And, as a paying customer, ask the eM people to fix it.)

[giddyhup]

With eM client out of the picture, this (TEL;TYPE="CELL,VOICE";VALUE=UNKNOWN:...) still appears and I have troubles understanding what goes on during syncing between an iPhone and Nextcloud. I wonder what others are experiencing.

[Timokirch]

Hi and sorry for the delay in testing. With Version 3.3.0 my contact looks better, but still not ideal. The contact shows now correcty "Work" , "Home" or "Mobile" on the numbers or addresses. Anyhow the anniversary will displayed as invalid date and the address is separated by multiple ";" in the web interface. Actual iOS and Thunderbird cardbook shows the information right.

[skjnldsv]

Can you post the date of your vcard?

[Timokirch]

sure :)

[skjnldsv]

This is another issue then :) Please open a new one, and fill the report template. Make sure to also include your browser log :hugs:

[Timokirch]

OK, i will find out how to do that and will create a new issue. Also for the address?

[skjnldsv]

Yes, open one for the two issues, we'll debug further :)

[Timokirch]

Sorry to bother again, but i can‘t help myself :(

Today i noticed that contacts on my iPhone and iPad will display an additional ‚“‘. Within the Webinterface and in Thunderbird these informations are shown with the correct description.

[GRaptor]

Yes, same with me. When I create a new contact in Nextcloud, it shows like that on my iPhone.

[skjnldsv]

I guess we fixed the first part, but because apple is not compatible with the quote-formatted types, we should try to see if we can enforce their removal :thinking:

[mhbates]

I am experiencing this as well on iOS. Has anyone found a workaround until this is fixed?

[TimHalvorsen]

The comment made by 'skjnldsv' earlier in this discussion seem to imply that VCF allows a syntax like ..;TYPE="WORK,VOICE":.. My reading of RFC5545 Section 3.1 and Section 3.1.1 seems to indicate that this is not true. Section 3.1.1 says that some Properties (e.g. TYPE) can have multiple values separated by a COMMA. Section 3.1.1 further states that "For those parameter values that are specified in quoted-strings, the individual quoted-strings are separated by a COMMA character".

Thus, the proper way to enclose (if needed) parameter values of TYPE is: TYPE="WORK","VOICE". Of course, the quoted-strings in this example are not necessary, since the parameter values have no special characters, and thus, serialization of this parameter should be done as TYPE=WORK,VOICE, which is very compatible with other VCF apps such as iOS Contacts app and others.

I also am experiencing the behavior of seeing "WORK as the label in iOS Contacts app for contacts coming from Nextcloud. Clearly this is because the iOS Contacts app stupidly separates the values by splitting the string on COMMA without regard to the double-quote characters. So, it probably doesn't support the syntax TYPE="WORK","VOICE" either. However, if the code could be changed to avoid enclosing the TYPE parameter list with the outer double-quotes (an incorrect behavior), and avoid using double-quotes unless required by special characters in the value, then it would maximize compatibility with other apps like iOS Contacts and others.

[skjnldsv]

@TimHalvorsen https://tools.ietf.org/html/rfc6350#page-35 EDIT: corrected wrong link

[TimHalvorsen]

Ah, my mistake. The RFC 5545 (iCalendar, 2009) I was using for reference is 2 years older than RFC 6350 that you cited (vCard, 2011). The later RFC clearly states that TYPE="WORK,VOICE" is legal syntax, so I withdraw my comment above indicating the opposite.

However, it still would increase compatibility if the serialized output wound up as TYPE=WORK,VOICE rather than TYPE="WORK,VOICE". The sabre/vobject "serialize" routine (module Parameter.php lines 304-316) adds double-quotes if a comma appears in any parameter value, but it will NOT add double-quotes if the value is passed as a list (e.g. ['WORK', 'VOICE'] rather than a single string (e.g. 'WORK,VOICE').

If there was a way to coerce the Contacts app to store the parameter values as a list rather than a single comma-separated string, then you would wind up with more-compatible serialization like TYPE=WORK,VOICE rather than TYPE="WORK,VOICE" in the output VCF.

[skjnldsv]

If there was a way to coerce the Contacts app to store the parameter values as a list rather than a single comma-separated string, then you would wind up with more-compatible serialization like TYPE=WORK,VOICE rather than TYPE="WORK,VOICE" in the output VCF.

Currently, not that I'm aware of, need to dig deeper. We're not managing this part. Our vCard javascript reader is Mozilla's ical.js library. They're the one doing the quoting and stuff, so it needs to be investigated. https://github.com/mozilla-comm/ical.js

[giddyhup]

The topic about allowed formats has also been discussed in the issue about the underlying library, ical.js.

It took several months for a fix there to come about but apparently it still doesn't help when Apple's implemenation is wrong.

[skjnldsv]

This one is just about multiple parameters :) Not about quotes or not. But to b honest, this is indeed an apple issue :(

[giddyhup]

I have the impression that one of the latest iOS updates fixed the iOS-specific display issue. @Timokirch, if you are on 13.5.1, do you still see it?

[Timokirch]

Hi @giddyhup, yes, something has changed but my newly created test contacts (webfrontend NC 19, FF & Chrome) still shows with "HOME on my ios devices.

Kind Regards Timo

[giddyhup]

Thanks @Timokirch for the feedback. You are right, on deeper inspection the issue on the iOS side is still there.

[superhero1]

This issue still exists for me in iOS 13.6 with Nextcloud 19.0.1 running Contacts 3.3.0. When I edit existing contacts from my phone in the web gui it changes Home to "HOME, Work to "WORK and Mobile to "CELL

[Silvernerd1]

Same problem here with eM Client 8.0.3385 and Nextcloud 19.0.3 / Contacts 3.3.0.

When I create a contact with eM Client, the VCF-file looks like this:

BEGIN:VCARD VERSION:4.0 PRODID:-//MailClient.VObject/8.0.3385.0 UID:urn:uuid:ba7b423b-43fa-45e4-ac6a-9cd60e878151 REV:20200915T121621Z N;SORT-AS=1-Test-Contact:1-Test-Contact;;;; FN:1-Test-Contact EMAIL;PREF=1:test@test.de TEL;TYPE=CELL:+49 123 456789 TEL;TYPE=WORK,VOICE:+49 30 987654 TEL;TYPE=HOME,VOICE:+49 1234 987654 END:VCARD

When I open it in Nextcloud / Contacts, the following error message appears: This contact was broken and received a fix. Please review the content and click here to save it.

When I save it, the VCF looks like this:

BEGIN:VCARD VERSION:3.0 PRODID:-//Sabre//Sabre VObject 4.3.0//EN UID:urn:uuid:ba7b423b-43fa-45e4-ac6a-9cd60e878151 N;SORT-AS=1-Test-Contact:1-Test-Contact;;;; FN:1-Test-Contact EMAIL;TYPE=PREF:test@test.de TEL;TYPE=CELL:+49 123 456789 TEL;TYPE="WORK,VOICE":+49 30 987654 TEL;TYPE="HOME,VOICE":+49 1234 987654 REV;VALUE=DATE-AND-OR-TIME:20200915T122216Z END:VCARD

And when eM Client synchronizes this contact, the labels of the eM Clients contact screen appear as "Work,voice" / "Home,voice" instead of Work / Home.

[giddyhup]

I have a lifetime EM Client license and reported this issue twice. No reaction.

[Silvernerd1]

I have lifetime EM Client license and reported this issue twice. No reaction.

Seems for me, that this is not an eM Client issue. Many other platforms (see above) have also problems with Nextcloud-Contacts' behaviour, to quote WORK,VOICE or HOME,VOICE.

[skjnldsv]

Seems for me, that this is not an eM Client issue

It totally is. Having quotes is 100% considered as valid by the vcard rfc.

[UrbaneChimp]

Seems for me, that this is not an eM Client issue

It totally is. Having quotes is 100% considered as valid by the vcard rfc.

Nevertheless, this "incompatibility" results in Nextcloud users with iOS devices (for example) having an inferior user experience compared to users of competing projects such as ownCloud.

[skjnldsv]

Seems for me, that this is not an eM Client issue

It totally is. Having quotes is 100% considered as valid by the vcard rfc.

Nevertheless, this "incompatibility" results in Nextcloud users with iOS devices (for example) having an inferior user experience compared to users of competing projects such as ownCloud.

Yes, this is why there is this issue opened? I'm missing your point I think 🤔