title: "IM Service Type Registry for vCard" abbrev: "vCard IM Service Types" category: std ipr: trust200902 submissiontype: IETF docname: draft-kisst-calext-im-service-type-00 date: 2026-04-07 area: ART workgroup: calext keyword:
- vCard
- instant messaging
- IMPP
- SERVICE-TYPE
author:
- fullname: KissT country: CH
normative: RFC6350: RFC8126: RFC9554:
informative:
--- abstract
This document defines an IANA registry for Instant Messaging (IM) service type tokens for use with the vCard IMPP property and its SERVICE-TYPE parameter. The registry provides a canonical, deduplicated set of identifiers for instant messaging services and protocols, enabling interoperable exchange of IM contact details in vCard objects. An initial set of 106 service type values is registered.
--- middle
The vCard format {{RFC6350}} defines the IMPP property for representing instant messaging and presence protocol contact information. {{RFC9554}} introduced the SERVICE-TYPE parameter, which may be applied to both IMPP and SOCIALPROFILE properties to name the online service associated with a contact address.
However, no registry exists to govern the values used with SERVICE-TYPE when applied to instant messaging services. In practice, implementations have invented their own ad-hoc identifiers, leading to inconsistency, duplication, and interoperability failures. For example, one application may use "WhatsApp" while another uses "whatsapp" or "wa" for the same service.
This document establishes an IANA registry of IM service type tokens. Each token is a short, lowercase, ASCII string that uniquely identifies an instant messaging service or protocol. The registry provides:
- A canonical identifier for each IM service
- A reference URL for the service or its defining specification
- A suggested URI format for addressing contacts on that service
- Registration policies that allow the registry to grow as new services emerge
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they appear in all capitals, as shown here.
IM service type tokens registered in the registry defined by this document MUST conform to the following ABNF {{!RFC5234}}:
im-service-type = 1*( ALPHA / DIGIT )
Tokens MUST consist solely of lowercase ASCII letters (a-z) and digits (0-9). Tokens MUST NOT contain hyphens, underscores, spaces, or other punctuation. This constraint ensures tokens are unambiguous, easy to compare, and safe for use in URIs and structured data formats.
Tokens MUST be compared case-insensitively for lookup purposes, but MUST be stored and transmitted in their registered lowercase form.
When the SERVICE-TYPE parameter is used on an IMPP property, its value SHOULD be a token from the IM Service Type Registry defined in this document.
The IMPP property value SHOULD be a URI that can be used to initiate communication via the identified service. Where no standard URI scheme exists for a service, an HTTPS URL to the user's profile or a service-specific deep link MAY be used.
Examples:
IMPP;SERVICE-TYPE=xmpp:xmpp:alice@example.com
IMPP;SERVICE-TYPE=signal:tel:+15551234567
IMPP;SERVICE-TYPE=matrix:matrix:u/alice:example.com
IMPP;SERVICE-TYPE=telegram:https://t.me/alice
IMPP;SERVICE-TYPE=discord:https://discord.com/users/123456789
IMPP;SERVICE-TYPE=irc:irc://irc.libera.chat/alice
IMPP;SERVICE-TYPE=simplex:https://simplex.chat/contact#...
IMPP;SERVICE-TYPE=threema:https://threema.id/ABCD1234
IMPP;SERVICE-TYPE=whatsapp:https://wa.me/+15551234567
IMPP;SERVICE-TYPE=sip:sip:alice@example.com
While the registry itself is a flat list, implementations may find it useful to understand the general categories of services represented. These categories are informational and are not part of the registry data:
-
Open protocols: Services based on open, standardized protocols (e.g., xmpp, matrix, sip, irc, activitypub)
-
Commercial platforms: Proprietary messaging services (e.g., whatsapp, signal, telegram, discord, slack)
-
Mesh/offline-capable: Services designed for communication without internet infrastructure (e.g., meshtastic, briar, bridgefy)
-
Enterprise: Workplace collaboration platforms (e.g., microsoftteams, slack, mattermost, rocketchat)
The presence of IMPP properties with SERVICE-TYPE parameters in a vCard reveals which messaging services a contact uses. This metadata may be sensitive, as it can indicate security practices, political affiliations, or geographic location. Implementations SHOULD treat IM service type information with the same privacy considerations as other contact details.
A vCard containing multiple IMPP entries with different SERVICE-TYPE values effectively provides a messaging service fingerprint of the contact. Parties handling such vCards SHOULD be aware that this information could be used for profiling or correlation across services.
The registration of a service type token in this registry does not constitute an endorsement of the service's security properties. Implementations MUST NOT infer security guarantees (such as end-to-end encryption) from the presence of a SERVICE-TYPE token alone.
When no standard URI scheme exists for a service, HTTPS URLs or service-specific deep links are used as IMPP values. Implementations MUST validate and sanitize such URIs before use to prevent injection attacks or unintended navigation.
IANA is requested to create a new registry titled "vCard IM Service Type Tokens" within the "vCard Elements" registry group.
New registrations in this registry are subject to Expert Review {{RFC8126}}. The designated expert(s) SHOULD verify that:
- The token conforms to the format defined in Section 2.1.
- The service or protocol is a real, operational instant messaging system or protocol with text-based messaging as a primary feature.
- The entry represents a service or protocol, not a client application that connects to another protocol.
- The token does not duplicate an existing entry (including equivalent services under different names).
- The reference URL points to a legitimate, publicly accessible resource describing the service or protocol.
- Defunct or abandoned services SHOULD be marked as deprecated rather than removed, to prevent token reuse.
Each entry in the registry contains the following fields:
- Token: The service type identifier (lowercase ASCII)
- Name: Human-readable name of the service
- Reference URL: URL to the service or its specification
- Suggested URI: Example URI format for addressing users
- Status: "active" or "deprecated"
- Change Controller: Entity authorized to update the entry
The following table contains the initial set of IM service type tokens. All entries have Status "active".
--- back
The initial service list was compiled as a community effort to create a comprehensive, deduplicated inventory of instant messaging services and protocols.
- Initial version
- Validated all entries: removed clients, defunct services, non-IM platforms, and hardware devices
- Added suggested URI formats for each service