XEP-0174: Serverless Messaging

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Copyright

Permissions

Disclaimer of Warranty

Limitation of Liability

IPR Conformance

1. Introduction
    1.1. Motivation
    1.2. How It Works
2. Glossary
3. DNS Records
    3.1. TXT Records
4. Discovering Other Users
5. Exchanging Presence
6. Discovering Capabilities
7. Initiating a Messaging Session
8. Exchanging Messages
9. Ending a Messaging Session
10. Going Offline
11. Implementation Notes
    11.1. Multiple Network Interfaces
    11.2. Buddy Icons
    11.3. Port
    11.4. Wide-Area Networks
12. Internationalization Considerations
13. Security Considerations
    13.1. Authentication and Encryption
    13.2. Stanza Injection
    13.3. TXT Record Data
    13.4. Private Information
14. IANA Considerations
15. XMPP Registrar Considerations
    15.1. Link-Local Messaging TXT Records Registry
       15.1.1. Registration Process
       15.1.2. Initial Registration
16. Acknowledgements
Notes
Revision History

1.1 Motivation

The Extensible Messaging and Presence Protocol (XMPP) as defined in RFC 3920 [1] does not support direct client-to-client interactions, since it requires authentication with a server: an XMPP client is allowed access to the network only after it has authenticated with a server, and the server will not grant access if authentication fails for any reason. If an unauthenticated client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through one or more servers and a client cannot inject messages onto the network unless it first authenticates with a server.

However, it is possible to establish an XMPP-like communication system on a local (or even wide-area) network using the principles of zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish serverless communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are able to negotiate an XML stream between themselves (as generalized in End-to-End XML Streams [2]) and then exchange messages and other structured data using the XMPP <message/> and <iq/> stanzas.

Serverless messaging is typically restricted to a local network (or ad-hoc wide-area network) because of how zero-configuration networking works. It is impossible for clients that communicate via this serverless mode to insert messages into an XMPP network, which is why this kind of "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the Security Considerations regarding the ability to "forward" messages from a serverless mesh to an XMPP network or vice-versa).

Such a "mesh" can be quite valuable in certain circumstances. For instance, participants in a trade show or conference, users of the same wifi hotspot, or employees on the same local area network can communicate without the need for a pre-configured server. For this reason, support for serverless messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode for many years. Because it is desirable for other Jabber/XMPP clients to support such functionality, this document describes how to use zero-configuration networking as the basis for serverless communication, mainly for use on local links (although the protocol can also be used on ad-hoc wide-area networks).

1.2 How It Works

This section provides a friendly introduction to serverless messaging. The examples show usage on a local link using dynamically configured link-local addresses as described in RFC 3927 [3] (see the Wide-Area Networks section of this document regarding non-local usage).

Imagine that you are a Shakespearean character named Juliet. You are are using your laptop computer (a machine named "pronto") at a wifi hotspot in downtown Verona and you want to find other people to chat with on an ad-hoc basis (i.e., not people in your normal XMPP roster). Therefore your chat client advertises a serverless address of "juliet@pronto" so that other people can dynamically find you at the hotspot. Your client does this by invoking a daemon on your machine that supports DNS-based Service Discovery ("DNS-SD") as defined in DNS-Based Service Discovery [4] and Multicast DNS ("mDNS") as defined in Multicast DNS [5]. As a result, the daemon stores the following DNS records and listens for multicast DNS queries asking for them:

pronto.local. A 10.2.1.187

juliet@pronto._presence._tcp.local. SRV 5562 pronto.local. 

_presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
    

The meaning of these records is as follows:

• The A record specifies the IP address 10.2.1.187 at which the "pronto" machine will listen for connections.
• The SRV record (see RFC 2782 [6]) maps the presence service instance "juliet@pronto" to the machine "pronto.local." on port 5562.
• The PTR ("pointer") record (see RFC 2317 [7] and RFC 1886 [8]) says that there is a service of type "presence" on the local subnet (".local.") called "juliet@pronto" and that the service communicates over TCP.

Your chat client also wants to advertise some information about you (subject to your control so that you don't divulge private information). Therefore it invokes the mDNS daemon to also store some DNS TXT records (see RFC 1464 [9]):

juliet IN TXT "txtvers=1"
juliet IN TXT "1st=Juliet"
juliet IN TXT "email=juliet@capulet.lit"
juliet IN TXT "hash=sha-1"
juliet IN TXT "jid=juliet@capulet.lit"
juliet IN TXT "last=Capulet"
juliet IN TXT "msg=Hanging out downtown"
juliet IN TXT "nick=JuliC"
juliet IN TXT "node=http://www.adiumx.com"
juliet IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
juliet IN TXT "port.p2pj=5562"
juliet IN TXT "status=avail"
juliet IN TXT "vc=CA!"
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
    

Other people at the hotspot can also advertise similar DNS records for use on the local link. Essentially, the mDNS daemons running on all of the machines at the hotspot collectively manage the ".local." domain, which has meaning only at the hotspot (not across the broader Internet). Queries and responses for services on the local link occur via multicast DNS over UDP port 5353 instead of via normal DNS unicast over UDP port 53. When a new machine joins the local link, it can send out queries for any number of service types, to which the other machines will reply. For the purpose of serverless messaging we are interested only in the "presence" service, but many other services could exist on the local link (see dns-sd.org for a complete list).

Now let us imagine that a fine young gentleman named Romeo joins the hotspot and that his chat client (actually his mDNS daemon) sends out multicast DNS queries for services of type "presence". To do this, his client essentially reverses the order of DNS record publication (explained above) by asking for pointers to presence services (i.e., PTR records that match "_presence._tcp.local."), querying each service for its service instance and port (i.e., SRV record), mapping each service instance to an IP address (i.e., A record), and finding out additional information about the entity using the service (i.e., TXT records). As a result, Romeo's client will discover any number of local presence services, among them a service named "juliet@pronto" (with some intriguing TXT records) at IP address 10.2.1.187 and port 5562. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.

<stream:stream 
        xmlns='jabber:client' 
        xmlns:stream='http://etherx.jabber.org/streams'
        from='romeo@forza'
        to='juliet@pronto'
        version='1.0'>
    

Your client then responds with a response stream header (perhaps subject to user approval -- it's not always safe to chat with strangers!).

<stream:stream 
        xmlns='jabber:client' 
        xmlns:stream='http://etherx.jabber.org/streams'
        from='juliet@pronto'
        to='romeo@forza'
        version='1.0'>
    

Romeo then sends you an XMPP message.

<message from='romeo@forza' to='juliet@pronto'>
  <body>M'lady, I would be pleased to make your acquaintance.</body>
</message>
    

And you reply.

<message from='juliet@pronto' to='romeo@forza'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>
    

You chat with Romeo for a while, then your client closes the stream.

</stream:stream>
    

And Romeo's client does the same.

</stream:stream>
    

Finally you decide to head home, so your mDNS daemon sends a Multicast DNS "Goodbye" packet for your PTR record. As a result, everyone else at the hotspot receives a Multicast DNS "Remove" event, at which point they cancel any outstanding A, SRV, TXT, or NULL record queries related to your presence service.

Table 1: Terminology

_presence._tcp.local. PTR juliet@pronto._presence._tcp.local.

juliet@pronto._presence._tcp.local. SRV 5562 pronto.local. 

pronto.local. A 10.2.1.187

juliet IN TXT "txtvers=1"
juliet IN TXT "1st=Juliet"
juliet IN TXT "email=juliet@capulet.lit"
juliet IN TXT "hash=sha-1"
juliet IN TXT "jid=juliet@capulet.lit"
juliet IN TXT "last=Capulet"
juliet IN TXT "msg=Hanging out downtown"
juliet IN TXT "nick=JuliC"
juliet IN TXT "node=http://www.adiumx.com"
juliet IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
juliet IN TXT "port.p2pj=5562"
juliet IN TXT "status=avail"
juliet IN TXT "vc=CA!"
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="

  

3.1 TXT Records

DNS-SD enables service definitions to include various TXT records that specify parameters to be used in the context of the relevant service type. The XMPP Registrar [10] maintains a registry of TXT records for use with the _presence._tcp service type, as specified in the XMPP Registrar Considerations section of this document.

It is OPTIONAL to include any of these TXT records, and an implementation MUST NOT fail (i.e., MUST enable serverless messaging) even if none of the TXT records are provided by another entity.

Most of the registered TXT records relate to human users, in which context certain records are of greater interest than others, e.g. "msg", "nick", and "status"; however, serverless messaging can be used by non-human entities (e.g., devices).

Note: See the Security Considerations section of this document regarding the inclusion of information that can have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" records).

<stream:stream 
        xmlns='jabber:client' 
        xmlns:stream='http://etherx.jabber.org/streams'
        from='romeo@forza'
        to='juliet@pronto'
        version='1.0'>
  

<stream:stream 
        xmlns='jabber:client' 
        xmlns:stream='http://etherx.jabber.org/streams'
        from='juliet@pronto'
        to='romeo@forza'
        version='1.0'>
  

<stream:features>
  <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:features>
  

<message from='romeo@forza' to='juliet@pronto'>
  <body>M'lady, I would be pleased to make your acquaintance.</body>
</message>
  

<message from='juliet@pronto' to='romeo@forza'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>
  

</stream:stream>
  

</stream:stream>
  

11.1 Multiple Network Interfaces

Devices that use serverless messaging can have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the serverless roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communication when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.

11.2 Buddy Icons

If an entity has an associated icon (e.g., a user avatar or photo), its client SHOULD publish the raw binary data for that image via a DNS NULL record of the following form:

_presence._tcp.local. IN NULL raw-binary-data-here
    

Note: In accordance with RFC 1035 [15], the data MUST be 65535 octets or less.

After retrieving the "phsh" value from a Buddy's TXT record, a client SHOULD search its local picture database to learn the last recorded picture hash value for an entity and then compare it to the "phsh" value in the TXT record. If the values are equal, the client SHOULD use the local copy of the icon. If the picture hash values are not equal, the client SHOULD issue a Multicast DNS NULL record query to retrieve the new icon. After retrieving the NULL record, the client SHOULD replace the old "phsh" value in the picture database with the new "phsh" value and save the icon to disk. If the client needs to send a Multicast DNS query in order to retrieve the icon, it MUST cancel the NULL record query immediately after receiving a response containing the new picture data.

If a user changes their picture, the user's client MUST update the NULL record with the contents of the new picture, calculate a new picture hash, and then update the "phsh" value in the TXT record with the new hash value. Since all users "logged into" serverless presence are monitoring for TXT record changes, they will see that the "phsh" value was changed; if they wish to view the new icon, their clients SHOULD issue a new Multicast DNS query to retrieve the updated picture.

11.3 Port

The port used for serverless messaging MAY be any unassigned port number, as determined by the messaging application on the device. The chosen port MUST be specified in the SRV record and applications MUST use the port specified in the SRV record. However, the chosen port SHOULD also be specifed in the "port.p2pj" TXT record for backwards-compatibility with older implementations, and if included the port specified in the TXT record MUST be the same as the port specified in the SRV record.

11.4 Wide-Area Networks

Serverless messaging via the _presence._tcp DNS SRV service type is not limited to local networks, since it is possible to advertise this service type via Wide-Area DNS-SD as described at <http://www.dns-sd.org/iChatWideArea.html>. Although the protocol is most commonly used on local networks, there is nothing intrinsic to the protocol that limits its use to peers on the same link, and it also works between any two peers that can discover each other via any profile of DNS-SD (whether local or wide-area). Naturally, the DNS records used in Wide-Area DNS-SD will not contain the ".local." domain, since the records are not intended for use over a local link.

13.1 Authentication and Encryption

XMPP networks use TLS (RFC 4346 [17]) for channel encryption, SASL (RFC 4422 [18]) for authentication, and the Domain Name System (RFC 1034 [19]) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.

There are two potential solutions to this problem:

1. Negotiate the use of TLS and SASL for the XML stream as described in RFC 3920.
2. Negotiate encryption with identity checking for the message exchange using Encrypted Session Negotiation [20].

It is RECOMMENDED to use one of these methods to secure communications between serverless entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client SHOULD warn the human user that the channel is unauthenticated and unencrypted.

13.2 Stanza Injection

Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 3920. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).

13.3 TXT Record Data

Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).

13.4 Private Information

The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).

1. Short name: presence
2. Long name: iChat AV
3. Responsible person: Jens Alfke <jens at apple.com>
4. Defined TXT keys: txtvers, port.p2pj, phsh, vc, 1st, AIM, msg, status, last

1. Short name: presence
2. Long name: Link-Local Messaging
3. Responsible person: XMPP Registrar <registrar at xmpp.org>
4. Protocol URL: http://www.xmpp.org/extensions/xep-0174.html
5. Primary transport protocol: _tcp
6. TXT keys URL: http://www.xmpp.org/registrar/linklocal.html

15.1 Link-Local Messaging TXT Records Registry

The XMPP Registrar [22] maintains a registry of TXT records advertised in the context of serverless messaging (see <http://xmpp.org/registrar/linklocal.html>).

<record>
  <name>The attribute name of the TXT record.</name>
  <desc>A natural-language description of the record.</desc>
  <status>
    The requirements status of the record. Should be one of: 
      - required
      - recommended 
      - optional
      - deprecated
      - obsolete
 </status>
</record>
      

<record>
  <name>1st</name>
  <desc>The given or first name of the user.</desc>
  <status>optional</status>
</record>

<record>
  <name>email</name>
  <desc>
    The email address of the user; can contain a space-separated list 
    of more than one email address.
  </desc>
  <status>optional</status>
</record>

<record>
  <name>ext</name>
  <desc>
    A space-separated list of extensions; the value of this record MUST 
    be the same as that provided via normal XMPP presence (if applicable) 
    in the 'ext' attribute specified in Entity Capabilities (XEP-0115).
  </desc>
  <status>optional</status>
</record>

<record>
  <name>hash</name>
  <desc>
    The hashing algorithm used to generated the 'ver' attribute in 
    Entity Capabilities (XEP-0115) and therefore the ver TXT record
    in Link-Local Messaging.
  </desc>
  <status>recommended</status>
</record>

<record>
  <name>jid</name>
  <desc>
    The Jabber ID of the user; can contain a space-separated list of 
    more than one JID.
  </desc>
  <status>recommended</status>
</record>

<record>
  <name>last</name>
  <desc>The family or last name of the user.</desc>
  <status>optional</status>
</record>

<record>
  <name>msg</name>
  <desc>
    Natural-language text describing the user's state. This is 
    equivalent to the XMPP &lt;status/&gt;; element.
  </desc>
  <status>optional</status>
</record>

<record>
  <name>nick</name>
  <desc>A friendly or informal name for the user.</desc>
  <status>recommended</status>
</record>

<record>
  <name>node</name>
  <desc>
    A unique identifier for the application; the value of this record MUST 
    be the same as that provided via normal XMPP presence (if applicable) 
    in the 'node' attribute specified in Entity Capabilities (XEP-0115).
  </desc>
  <status>recommended</status>
</record>

<record>
  <name>phsh</name>
  <desc>
    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.
  </desc>
  <status>optional</status>
</record>

<record>
  <name>port.p2pj</name>
  <desc>
    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 TXT record. However, 
    clients SHOULD advertise this TXT record if it is important to ensure
    backwards-compatibility with some existing implementations. (Note: In
    some existing implementations this value was hardcoded to "5298".)
  </desc>
  <status>deprecated</status>
</record>

<record>
  <name>status</name>
  <desc>
    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 &lt;show/&gt; values of "away" and "dnd", 
    respectively; if the status record is not included, the status SHOULD 
    be assumed to be "avail".
  </desc>
  <status>recommended</status>
</record>

<record>
  <name>txtvers</name>
  <desc>
    The version of the TXT records supported by the client. For backwards 
    compatibility this is hardcoded at "1". This TXT record SHOULD be the
    first one provided, in accordance with the DNS-SD specification.
  </desc>
  <status>deprecated</status>
</record>

<record>
  <name>vc</name>
  <desc>
    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 records for more robust capabilities discovery as described 
    in the Discovering Capabilities section of XEP-0174.
  </desc>
  <status>optional</status>
</record>

<record>
  <name>ver</name>
  <desc>
    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 record MUST be the 
    same as that provided via normal XMPP presence (if applicable) in 
    the 'ver' attribute specified in Entity Capabilities (XEP-0115).
  </desc>
  <status>recommended</status>
</record>

      

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. XEP-0246: End-to-End XML Streams <http://xmpp.org/extensions/xep-0246.html>.

3. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses <http://tools.ietf.org/html/rfc3927>.

4. DNS-Based Service Discovery <http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd>. Work in progress.

5. Multicast DNS <http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns>. Work in progress.

6. RFC 2782: A DNS RR for specifying the location of services (DNS SRV) <http://tools.ietf.org/html/rfc2782>.

7. RFC 2317: Classless IN-ADDR.ARPA delegation <http://tools.ietf.org/html/rfc2317>.

8. RFC 1886: DNS Extensions to support IP version 6 <http://tools.ietf.org/html/rfc1886>.

9. RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes <http://tools.ietf.org/html/rfc1464>.

10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

11. The replies will include a record corresponding the client itself; the client MUST filter out this result.

12. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

13. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

14. The to and from addresses MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

15. RFC 1035: Domain Names - Implementation and Specification <http://tools.ietf.org/html/rfc1035>.

16. Coded Character Set - 7-bit American Standard Code for Information Interchange (American National Standards Institute X3.4, 1986).

17. RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1 <http://tools.ietf.org/html/rfc4346>.

18. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.

19. RFC 1034: Domain Names - Concepts and Facilities <http://tools.ietf.org/html/rfc1034>.

20. XEP-0116: Encrypted Session Negotiation <http://xmpp.org/extensions/xep-0116.html>.

21. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

22. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

23. SIP URI Service Discovery using DNS-SD <http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri>. Work in progress.

Version 1.2 (2008-09-03)

Version 1.1 (2008-03-05)

Version 1.0 (2007-06-12)

Version 0.16 (2007-05-30)

Version 0.15 (2007-05-14)

Version 0.14 (2007-05-11)

Version 0.13 (2007-03-28)

Version 0.12 (2007-03-26)

Version 0.11 (2007-03-14)

Version 0.10 (2007-03-13)

Version 0.9 (2006-12-22)

Version 0.8 (2006-07-31)

Version 0.7 (2006-06-06)

Version 0.6 (2006-06-05)

Version 0.5 (2006-04-14)

Version 0.4 (2006-03-16)

Version 0.3 (2006-02-23)

Version 0.2 (2006-02-22)

Version 0.1 (2006-02-09)

Version 0.0.1 (2006-02-07)