moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

typos

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@864 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-05-29 18:35:09 +00:00
parent de51496d09
commit 8bed25d04b
1 changed files with 24 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
xep-0174.xml
View File

@ -25,11 +25,17 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.16</version>
<date>2007-05-24</date>
<initials>psa</initials>
<remark><p>Updated definition of port.p2pj TXT record so that it is not hardcoded to 5298 but instead tracks the port advertised via SRV.</p></remark>
</revision>
<revision>
<version>0.15</version>
<date>2007-05-14</date>
<initials>psa</initials>
<remark><p>Updated IANA Considerations to reflect proposed modification to DNS-SD registration.</p></remark>
<remark><p>Updated IANA Considerations to reflect proposed modifications to DNS-SD registration.</p></remark>
</revision>
<revision>
<version>0.14</version>
@ -124,7 +130,8 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<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. Note well that such communications are 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>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>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -188,7 +195,7 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo
<owner> IN <ttl> TXT "nick=user-nickname"
<owner> IN <ttl> TXT "node=application-identifier"
<owner> IN <ttl> TXT "phsh=sha1-hash-of-avatar"
<owner> IN <ttl> TXT "port.p2pj=5298"
<owner> IN <ttl> TXT "port.p2pj=5562"
<owner> IN <ttl> TXT "status=avail-away-or-dnd"
<owner> IN <ttl> TXT "txtvers=1"
<owner> IN <ttl> TXT "vc=capabilities-string"
@ -197,13 +204,13 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo
</li>
</ol>
<p>The "machine-name" is the name of the computer, the "username" is the system username of the principal currently logged into the computer, the "port" may be any unassigned port number, and the "ip-address" is the physical address of the computer on the local network.</p>
<p>So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5526", the IP address is "10.2.1.187", and the personal information is that associated with the author of this document, the DNS records would be as follows:</p>
<p>So, for example, if the machine name is "roundabout", the username is "stpeter", the chosen port is "5562", the IP address is "10.2.1.187", and the personal information is that associated with the author of this document, the DNS records would be as follows:</p>
<code><![CDATA[
roundabout.local. A 10.2.1.187
_presence._tcp IN SRV 5526 stpeter@roundabout.local.
_presence._tcp IN SRV 5562 stpeter@roundabout.local.
_presence._tcp.local. 5526 IN PTR stpeter@roundabout._presence._tcp.local.
_presence._tcp.local. 5562 IN PTR stpeter@roundabout._presence._tcp.local.
psa IN TXT "1st=Peter"
psa IN TXT "email=stpeter@jabber.org"
@ -214,7 +221,7 @@ psa IN TXT "msg=IETF 66 Montreal"
psa IN TXT "nick=stpeter"
psa IN TXT "node=http://www.apple.com/ichat/caps"
psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
psa IN TXT "port.p2pj=5298"
psa IN TXT "port.p2pj=5562"
psa IN TXT "status=avail"
psa IN TXT "txtvers=1"
psa IN TXT "vc=CA!"
@ -232,7 +239,7 @@ psa IN TXT "ver=524"
</section2>
</section1>
<section1 topic='Discovering Other Users' anchor='disco'>
<p>In order to discover other users, a client sends an mDNS request for PTR records that match "_presence_tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "username@machine-name._presence._tcp.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a link-local "roster" SHOULD be obtained from the &lt;Instance&gt; portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.</p>
<p>In order to discover other users, a client sends an mDNS request for PTR records that match "_presence._tcp.local.". The client then receives replies from all machines that advertise support for link-local messaging. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "username@machine-name._presence._tcp.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a link-local "roster" SHOULD be obtained from the &lt;Instance&gt; portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.</p>
</section1>
<section1 topic='Exchanging Presence' anchor='presence'>
<p>When the _presence._tcp service is used, presence is exchanged via the format described in the <link url='#txt'>TXT Records</link> section of this document. In particular, presence information is not pushed as in XMPP (see &rfc3921;). Instead, clients listen for presence announcements from other local entities. Recommended rates for sending updates can be found in <cite>Multicast DNS</cite>.</p>
@ -256,7 +263,7 @@ psa IN TXT "ver=524"
<example caption="Stream Header Response"><![CDATA[
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
xmlns:stream='http://etherx.jabber.org/streams'
from='hildjj@wolfram'
to='stpeter@roundabout'
version='1.0'>
@ -331,16 +338,8 @@ _presence._tcp.local. IN NULL raw-binary-data-here
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>DNS-SD service type names are not yet managed by &IANA;. Section 19 of <cite>DNS-Based Service Discovery</cite> proposes an IANA allocation policy for unique application protocol or service type names. Until the proposal is adopted and in force, Section 19 points to &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt; regarding registration of service type names for DNS-SD. The current registration is as follows:</p>
<div class='indent'>
<ol>
<li>Short name: presence</li>
<li>Long name: iChat AV</li>
<li>Responsible person: Jens Alfke &lt;jens at apple.com&gt;</li>
<li>Defined TXT keys: txtvers, port.p2pj, phsh, vc, 1st, AIM, msg, status, last </li>
</ol>
</div>
<p>The XMPP Registrar has proposed to the maintainer of &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt; that the registration be changed as follows:</p>
<p>DNS-SD service type names are not yet managed by &IANA;. Section 19 of <cite>DNS-Based Service Discovery</cite> proposes an IANA allocation policy for unique application protocol or service type names. Until the proposal is adopted and in force, Section 19 points to &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt; regarding registration of service type names for DNS-SD.</p>
<p>There is an existing registration for the "presence" service type. The XMPP Registrar has proposed to the maintainer of &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt; that the registration be changed as follows:</p>
<div class='indent'>
<ol>
<li>Short name: presence</li>
@ -461,10 +460,12 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<record>
<name>port.p2pj</name>
<desc>
The (hardcoded) port for link-local communications. Clients MUST use the
port discovered via SRV lookups and MUST ignore the value of this TXT
record, which is included only for backwards-compatibility with some
older, existing implementations.
The port for link-local communications. 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>