Link-Local Messaging TXT Record Parameters

This is the official registry of Link-Local Messaging TXT Record Parameters as maintained by the XMPP Registrar and authorized by XEP-0174: Link-Local Messaging. Note: For historical reasons this registry refers to "Link-Local Messaging" even though the name of the authorizing specification has been changed to "Serverless Messaging".

Last Updated: 2008-11-26

XML: https://xmpp.org/registrar/linklocal.xml


ParameterDescriptionStatus
1stThe given or first name of the user.optional
email The email address of the user; can contain a space-separated list of more than one email address. optional
ext A space-separated list of extensions; the value of this parameter MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ext' attribute specified in Entity Capabilities (XEP-0115). optional
hash The hashing algorithm used to generated the 'ver' attribute in Entity Capabilities (XEP-0115) and therefore the ver parameter in Link-Local Messaging. recommended
jid The Jabber ID of the user; can contain a space-separated list of more than one JID. recommended
lastThe family or last name of the user.optional
msg Natural-language text describing the user's state. This is equivalent to the XMPP <status/>; element. optional
nickA friendly or informal name for the user.recommended
node A unique identifier for the application; the value of this parameter MUST be the same as that provided via normal XMPP presence (if applicable) in the 'node' attribute specified in Entity Capabilities (XEP-0115). recommended
phsh The SHA-1 hash of the user's avatar icon or photo. This SHOULD be requested using mDNS in unicast mode by sending a DNS query to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB). The client SHOULD keep a local cache of icons keyed by hash. If the phsh value is not in the cache, the client SHOULD fetch the unknown icon and then cache it. Implementations SHOULD also include logic for expiring avatar icons. optional
port.p2pj The port for serverless communication. This MUST be the same as the value provided for SRV lookups. Clients MUST use the port discovered via SRV lookups and MUST ignore the value of this parameter. However, clients SHOULD advertise this parameter if it is important to ensure backwards-compatibility with some existing implementations. (Note: In some existing implementations this value was hardcoded to "5298".) deprecated
status The presence availability of the user. Allowable values are "avail", "away", and "dnd", which map to mere XMPP presence (the user is available) and the XMPP <show/> values of "away" and "dnd", respectively; if the status parameter is not included, the status SHOULD be assumed to be "avail". recommended
txtvers The version of the TXT record supported by the client. For backwards compatibility this is hardcoded at "1". This parameter SHOULD be the first one provided, in accordance with the DNS-SD specification. deprecated
vc A flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial. NOTE: This flag is included only for backwards-compatibility; implementations SHOULD use the node, ver, and ext parameters for more robust capabilities discovery as described in the Discovering Capabilities section of XEP-0174. optional
ver A hashed string that defines the XMPP service discovery (XEP-0030) identity of the application and the XMPP service discovery features supported by the application; the value of this parameter MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ver' attribute specified in Entity Capabilities (XEP-0115). recommended

Revision History

2008-11-26 Harmonized with version 2.0 of XEP-0174. (psa)

2008-03-05 Corrections per version 1.5 of XEP-0115. (psa)

2007-06-12 Initial version (populated from XEP-0174, version 1.0). (psa)