Phone numbers in tag 'ITEMTEL' get discarded without notice

[xss]

Example entry (anonymized):

BEGIN:VCARD
VERSION:3.0
ITEMTEL4915731234567.TEL:+49 1573 1234567
ITEMTEL4915731234567.X-ABLABEL:Mobil
N:(hint);Someone;Lastname;;
FN:Someone Lastname (hint)
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:20180905T220043Z
UID:d776a1c9-08df-4270-8816-74866a3092f6
END:VCARD

...will be saved without any of the ITEMTEL lines:

BEGIN:VCARD
VERSION:3.0
N:(hint);Someone;Lastname;;
FN:Someone Lastname (hint)
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:2018-09-06T00:00:43Z
UID:d776a1c9-08df-4270-8816-74866a3092f6
END:VCARD

Quite a bummer, as you might lose quite a lot of numbers without noticing.

Affected version: 0.4.0.20880

EDIT 2023-04-12: I originally thought the numbers were lost due to spaces in them. However, the apparently non-standard ITEMTEL tag seems to be the culprit (see comments below). Description and title adjusted accordingly.

[abdelkader]

Hi,

I don't seem to find any info on the "ITEMTEL" tag. I even searched for this on the RFC standard with no success. It seems that the library (I use in vcard editor) don't handle this tag, and will ignore this..

Do you happen to know which phone, or software generate this vCard?

[xss]

Hi,

oh, I didn't realize that this kind of entries had another format or special tags as compared to the others: I exported my whole contact list from NextCloud via the export functionality of its web GUI. Several hundred contacts in one vcf file. Most of them looked ok in vCardEditor and, as far as I know until now, were written back to disk fine.

I will check again and compare the other entries' format once I get back to my computer later today.

Thank you for your reply! :)

[xss]

Hi again,

I looked into this more thoroughly and you are right: It seems only those entries are affected that have a phone number in these ITEMTEL tag. Other entries with the normal TEL tags are ok, even with spaces or other characters in the phone number. I will change this issue's description accordingly.

In my original NextCloud export, I even found entries that have both ITEMTEL and TEL tags, with different numbers in each, like this, with a German number in TEL and a Mexican number in ITEMTEL:

BEGIN:VCARD
VERSION:3.0
ITEMTEL5215512345678.TEL:+52 1 55 1234 5678
TEL;TYPE=VOICE,CELL:0171 9876543
ITEMTEL5215512345678.X-ABLABEL:Mobil
FN:Ana Ejemplo (cel) MX
UID:e131f81c-3d75-4213-a8b4-e1f1e05536ef
N:MX;Ana Ejemplo;(cel);;
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:20210221T165214Z
END:VCARD

I think I narrowed down when these ITEMTEL tags are being used: For most of my contacts, the phone number type is annotated as TEL;TYPE=VOICE,CELL:<number here>. I assume this is the default syntax that gets displayed as type "Mobile", on the phone as well as in NextCloud as "Mobile":

The corresponding vCard will be exported by NextCloud like this:

BEGIN:VCARD
VERSION:3.0
TEL;TYPE=VOICE;TYPE=CELL:0171 1234567
FN:Testkontakt Drei
N:Drei;Testkontakt;;;
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:20230412T125017Z
UID:a6f6686c-731b-4569-a0f9-a7f8e5f7f6aa
END:VCARD

However, on my phone's contacts app ("True Phone", for the sake of completeness), I can define a custom type label, in this example it was named "Mobil" (note the "missing" e):

Depending on the situation, it is made clear that this is a Custom type label.

This gets displayed as "Mobil" in NextCloud's GUI, as well. However, here there seems to be no hint to the type being a custom type:

The resulting vCard export produces the ITEMTEL lines:

BEGIN:VCARD
VERSION:3.0
FN:Testkontakt
itemtel015731234567.TEL:01573 1234567
itemtel015731234567.X-ABLABEL:Mobil
N:;Testkontakt;;;
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:20230412T122127Z
UID:f9c9cb91-0861-4dd0-9ab1-7f81f7d9eab7
END:VCARD

(Curious that NextCloud will name the tag itemtel (lower-cased) for exporting a single contact, but ITEMTEL (upper-cased) when exporting the whole contact list...)

I tested exporting the same entries from my default phone app to vcf. That app does not use the ITEMTEL tag. Instead it will annotate the type label like this (though, it says vCard version 2.1 instead of 3.0 as opposed to what NextCloud would use):

BEGIN:VCARD
VERSION:2.1
N:;Testkontakt;;;
FN:Testkontakt
TEL;X-Mobil;PREF:015-731-234567
END:VCARD

In this last vCard, vCardEditor cannot display the phone number, as well, as it doesn't fit in any of the designated boxes. Which would probably be similar for some of the other possible types my phone proposes for a contact's number, such as "Main" or "Other". However, here it seems to retain the number upon saving to disk, merely discarding the type. So the number will not be lost here:

BEGIN:VCARD
VERSION:3.0
N:;Testkontakt;;;
FN:Testkontakt
TEL;TYPE=PREF:015-731-234567
END:VCARD

Truth be told, I really would not bother to manually set a custom type "Mobil" for every single phone number when I could simply choose the existing "Mobile". That's why I looked for another way how I might have ended up with those custom types. And I'm pretty sure all of the affected contacts were actually sent to me via vCard through messengers like WhatsApp, and from phones that have their device language set to something other than English.

In fact, I was able to reproduce this effect: I set my phone's language to German. All "Mobile" number types would be displayed as "Mobil" in German (confirmed on Android 13). Then I opened WhatsApp and shared a contact which originally definitely had TEL;TYPE=VOICE;TYPE=CELL before. Afterwards, I set my phone's language back to English and added the vCard I had just shared as a new contact. Et voilà: The new contact's number type would be displayed as "Custom: Mobil", and its NextCloud export resulted in these ITEMTEL lines.

So, these seem to be two reproducible ways to end up with those ITEMTEL lines in a NextCloud export.

[abdelkader]

I'm ok that that every vendor can add other tags.. Perhapas in the futur, I will handle incorrect vcf, and will try to preserve fields that are not standard.