Read IMPP fields in a vcard

[Lertsenem]

IMPP (Instant Messaging and Presence Protocol) addresses fields are defined by
RFC4770. In particular, Android default contacts manager implements them.

This small patch allows to read (and print) the IMPP addresses
informations stored in a vcard.

Of course there's much more to do to fully support IMPP addresses, such as take
into account standard types, and allow khard to write them, but this is a
start.

[scheibler]

Thanks. I didn't implement support for the impp attribute yet, because I had the impression, that it's not consistently supported and widely used by other contact management tools. For example when I add a Skype user name to the contact profile, the contacts app on Android 7 creates the following two lines: ``` X-SKYPE:USERNAME IMPP;X-SERVICE-TYPE=skype:skype:USERNAME ``` If I create an entry with khard instead, it still works on Android although the impp line is entirely missing. Therefore I used the private object X-SKYPE for simplicity and leave the second line untouched. If we want to use the impp attribute, we also have to check for that duplicates. I also found no list of allowed protocols. So it's unclear if the definition of the custom protocol (X-SERVICE-TYPE=skype) really is required or if IMPP:skype:USERNAME would be enough. If the latter is the case, could we use everything we want (for example IMPP:twitter:USERNAME)? If not, I don't see a very big benefit of the impp attribute (unless the majority of contact applications doesn't understand the self-defined attributes like x-skype at all).

[Lertsenem]

Damn, I didn't realize the standards implementations were so bad. :/

I did some testing with an earlier version of Android (Lollipop) and it could not see the self-defined attribute X-SKYPE I wrote with khard. Doing some test with the IMPP field, I figured the correct way was to write IMPP:Skype:Username (and indeed, writing IMPP:Twitter:@Username totally worked for me). I just supposed the TYPE=personal,... part of the RFC was not implemented yet and went on.

What I think happend, is that Android tried to follow (partially at least) the RFC, but on later versions realized everyone but them was using self-defined attributes and decided to do both, figuring that at least one field would work with any app.

So maybe it's not a good idea to let khard write such IMPP fields after all, at least until a well-defined and well-implemented standard emerge. Nevertheless I think my patch is still kind of relevant (with some adjustments), as a way to read IMPP fields (even badly formatted ones). As I said, earlier Android versions only use those fields, and a way to read them on my computer would be nice.

I'll leave the decision to you. :]

[DamienCassou]

I face a similar problem. If I use X-JABBER with khard, I won't see the field on Android and the conversations app won't see it either. When I set the IMPP:XMPP field from android, I won't see it in khard.

Which workaround do you propose so I see the XMPP addresses of my contacts on both android and khard?

[ghost]

My Android 9 completely ignores the X-SKYPE field, and almost all X-* fields altogether. So does Google Contacts. The server does not erase them from vcards synchronized, but does not use either.

It does use the "item1.IMPP;X-SERVICE-TYPE=Skype:skype:from-phone-skype" format, where X-SERVICE-TYPE apparently is something Google-specific.

[sylph1o]

I also use frequently the IMPP field and was surprised that khard did not display it. The format is defined in RFC 6350, § 6.4.3 (it replaces RFC 4470 mentioned above), e.g.

IMPP:xmpp:[email protected]

My experience is that it is well supported on Android with both the stock 'Contacts' application and 'Simple Contacts' by SimpleMobileTools. I synchronise the address book with Nextcloud via DAVx⁵ without issue. This works with any attribute that I define (in place of 'xmpp' in the example above).

For example, Simple Contacts uses the ez-vcard library for its vCard exports. The wiki of this library gives the same definition of the IMPP field format (and refers to the same RFC for vCard 4.0).

It would be a useful feature for me if khard could support that field as well (at least displaying it). Could this PR be re-considered? What kind of help is wanted?

[lucc]

@sylph1o in order to bring this forward somebody has to fix the code that it is merge conflict free, and also make it conform with rfc 6350.

The second step are tests for reading and writing the attribute.