moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

typos 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1494 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-12-27 21:15:26 +00:00
parent a0985ca5bc
commit f5517dcd64
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0174.xml
View File

@ -147,7 +147,7 @@
<p>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.</p>
<p>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.</p>
<p>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 <link url='#security'>Security Considerations</link> regarding the ability to "forward" messages from a local mesh to an XMPP network or vice-versa).</p>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='How It Works' anchor='howitworks'>
<p>This section provides a friendly introduction to link-local messaging.</p>
@ -165,7 +165,7 @@ pronto.local. A 10.2.1.187
<li>The SRV record (see &rfc2782;) maps the service instance "juliet@pronto" to the machine "pronto.local." on port 5562.</li>
<li>The A record specifies the IP address 10.2.1.187 at which the "pronto" machine will listen for connections.</li>
</ul>
<p>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;):</p>
<p>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;):</p>
<code><![CDATA[
juliet IN TXT "txtvers=1"
juliet IN TXT "1st=Juliet"
@ -183,7 +183,7 @@ juliet IN TXT "v=1.1.4"
juliet IN TXT "vc=CA!"
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
]]></code>
<p>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.</p>
<p>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 <link url='http://www.dns-sd.org/'>dns-sd.org</link> for a complete list).</p>
<p>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.</p>
<code><![CDATA[
<stream:stream
@ -216,7 +216,7 @@ juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
<code><![CDATA[
</stream:stream>
]]></code>
<p>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.</p>
<p>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.</p>
</section2>
</section1>