Skip to content

Latest commit

 

History

History
167 lines (144 loc) · 8.55 KB

IMPP.md

File metadata and controls

167 lines (144 loc) · 8.55 KB

Support for Instant Messaging Fields

The standardized way of storing instant messaging contact data inside a VCard is the IMPP property, which has been specified as an extension to VCard 3 by RFC 4770 and is included in VCard 4. According to the specification, the property looks like this:

IMPP;TYPE=personal,pref:im:[email protected]

The TYPE parameter is used in the same way as for other multi-value properties like EMAIL to store the communication purpose (e.g. home, work). The value of the property should be a URI that indicates the type of messaging service as the scheme part of the URI (e.g. im in the example above). Unfortunately, the RFC does not define any of these schemes, and so different clients use different ways of storing the IM type with the IMPP property, resulting in interoperability problems.

As if that wasn't enough, there exist non-standard properties that may come from a pre RFC 4770 time, but are still being used, by some addressbook applications exclusively. Examples for these properties are X-MSN and X-ICQ.

A check of different addressbook applications yielded the following:

Import into roundcube

In roundcube, we cannot separately display a type label (like home, work) and the messaging service type. Therefore, we can only support displaying the type of messaging service. From the above, the following import approach can be used to provide maximum interoperability:

For IMPP:

  • If an X-SERVICE-TYPE parameter exists, it is preferred. If it does not contain a known service, we will create one from the contained value (to support custom service types specified by iOS addressbook app).
  • If the IMPP value includes a scheme part, we use that if it corresponds to a known service (we may see schemes like x-apple here that we should not accept for display).
  • Otherwise, we check the TYPE parameter for known instant messaging services. Again, we cannot accept unkown values here, as the type parameter may contain other values like home or pref that do not indicate the messaging service.
  • Eventually, fall back to other.

For the non-standard X-* properties:

  • Import these as well, but check for already known values from the IMPP property. Duplicates are skipped. This is to allow interoperability with apple products that add both properties for the same contact information.
  • Obviously, only hard-coded known properties can be supported here.

Storing to CardDAV

Storing is more difficult than importing, since we should store VCards that are correctly interpreted by other clients whose behavior widely differs. In addition, while considering issues of interoperability, we still want to stay compliant with RFC 4770.

We adapt the following approach:

  • Add the IMPP attribute. We add the messenger service to the parameter X-SERVICE-TYPE and TYPE. Because we cannot have more than one subtype selected in roundcube, no other TYPE values are preserved anyway (this limitation is already present concerning the other multi-value properties as well).
  • In the value of the IMPP property, we store the messenger handle as an URI prefixed with a scheme as required by RFC 4770. Since RFC 4770 defines no URI schemes, we choose schemes in the following order (prio decreasing):
    • As listed at Wikipedia
    • As observed in use by other clients.
    • Lower case spelling of the service, if it contains no characters that must not be part of an URI scheme
    • Fallback to x-unknown

In addition, we add the old non-standard properties for those messenger services where such a property is known; this is what Apple does and allows clients relying on the legacy properties to display the information.

Results observed / known caveats:

  • Generally: When a card is edited in a client that does not know a property, it will leave those properties untouched. With IM properties where the information is stored twice (one time in an XMPP property, and another time in a non-standard X-* property), it is likely that upon edit only one property will be adapted and the other will be retained with the old information.
  • iCloud addressbook shows all types correctly. When editing the card, however, all service types are emptied and would have to be edited by the user again.
  • Evolution shows the IM fields properly for that an X-* property exists. Services that are only available in an IMPP property are not shown.
  • KAddressbook shows all entries, but services that KAddressbook does not know are displayed without a label. KAddressbook interprets both the IMPP as well as the X-* headers with the result that the contact data is shown twice where both properties exist.
  • Google shows the data correctly (no duplicates, all service types shown).
  • Nextcloud shows all data properly, but as expected includes the URI scheme in the displayed messenger handle.
  • Owncloud behaves like nextcloud.
  • eMClient shows all entries properly, but lists services it does not know of as unkown instead of showing the label. GaduGadu, MSN and Google Talk are shown as unknown because eMClient uses different URI schems than rcmcarddav, but I preferred the schemes listed at Wikipedia.