From 117ca176c93ecb655a9c98a59f58c8a1006ec917 Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Thu, 20 Aug 2015 09:48:26 +0200 Subject: [PATCH] Add '' to XEP-174 examples --- xep-0174.xml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xep-0174.xml b/xep-0174.xml index 4902726a..b11f1461 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -197,6 +197,7 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=

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 record parameters). As explained in the DNS-SD specification, these queries might all be returned in the same answer. 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 record parameters) 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.

Your client then responds with a response stream header.

In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from RFC 6120.

First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:

+ Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in RFC 6120, then it SHOULD include the version='1.0' flag as shown in the previous example.

The recipient then responds with a stream header as well:

+

As with Entity Capabilities over native XMPP networks, a client might not know the &xep0030; features associated with the 'ver' value advertised by another entity. However, in the case of serverless messaging there is no way for the client to discover the entity's supported features without initiating an XML stream to that entity and then sending a Service Discovery information ("disco#info") request over the negotiated stream.

Unfortunately, full stream negotiation (including TLS and SASL if appropriate) can require a large number of packets. Therefore, as an optimization, it is RECOMMENDED for the receiving entity in a serverless XML stream negotiation to include its disco#info data (including node) as a stream feature, as shown in the following examples.

+ ]]> +