From f5517dcd64bd4ff6106fd4048eb99d0151123bc1 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 27 Dec 2007 21:15:26 +0000 Subject: [PATCH] typos git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1494 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0174.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xep-0174.xml b/xep-0174.xml index c638ae68..a2eef99f 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -147,7 +147,7 @@

XMPP as defined in &rfc3920; 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 once it has authenticated with a server, and the server must 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 without first authenticating with a server.

However, it is possible to establish an XMPP-like communications system on a local network using 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 link-local communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas.

Link-local messaging is restricted to the local network because of how zero-configuration networking works. It is impossible for clients that communicate via link-local addresses to insert messages into an XMPP network, which is why this kind of local "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 local mesh to an XMPP network or vice-versa).

-

Such a local "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 link-local messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode. Because it is desirable for other Jabber clients to support such functionality, this document describes how to use zero-configuration networking as the basis for link-local communication.

+

Such a local "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 link-local 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 clients to support such functionality, this document describes how to use zero-configuration networking as the basis for link-local communication.

This section provides a friendly introduction to link-local messaging.

@@ -165,7 +165,7 @@ pronto.local. A 10.2.1.187
  • The SRV record (see &rfc2782;) maps the service instance "juliet@pronto" to the machine "pronto.local." on port 5562.
  • The A record specifies the IP address 10.2.1.187 at which the "pronto" machine will listen for connections.
    • -

    Your chat client also wants to advertise some information about you (subject to your control so that you don't divulge private information), so it invokes the mDNS daemon to also stores some DNS TXT records (see &rfc1464;):

    +

    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 &rfc1464;):

    -

    Other people at the hotspot may 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 link-local multicast 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 link-local messaging we are interested only in the "presence" service, but many other services could exist on the local link.

    +

    Other people at the hotspot may 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 link-local multicast 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 link-local 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 link-local multicast queries for link-local services of type "presence" (i.e., PTR records that match "_presence._tcp.local.", followed by appropriate SRV, A, and TXT record queries to discover detailed information about those services). His client will then discover (among others) a service named "juliet@pronto" at IP address 10.2.1.187 and port 5562, with some intriguing TXT records. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.

    ]]> -

    Finally you decides to head home so your mDNS daemon sends a Multicast DNS "Goodbye" packet for the 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.

    +

    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.