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

text tweaks

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2408 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-10-20 02:35:06 +00:00
parent b625cf91d9
commit 4f5a4e3387
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
xep-0174.xml
View File

@ -60,7 +60,7 @@
<version>0.14</version>
<date>2007-05-11</date>
<initials>psa</initials>
<remark><p>Specified that email and jid TXT values may contain a space-separated list of addresses; clarified roster display rules; clarified rules for handling presence name collisions; added security consideration about lack of validation for TXT record data.</p></remark>
<remark><p>Specified that email and jid TXT values can contain a space-separated list of addresses; clarified roster display rules; clarified rules for handling presence name collisions; added security consideration about lack of validation for TXT record data.</p></remark>
</revision>
<revision>
<version>0.13</version>
@ -84,7 +84,7 @@
<version>0.10</version>
<date>2007-03-13</date>
<initials>psa</initials>
<remark><p>Added nick TXT key; added note about use of AAAA records with IPv6; specified that from and to addresses are recommended for stream headers; specified that stream features should be sent.</p></remark>
<remark><p>Added nick TXT key; added note about use of AAAA records with IPv6; specified that from and to addresses are recommended for stream headers; encouraged implementations to send XMPP stream features.</p></remark>
</revision>
<revision>
<version>0.9</version>
@ -150,7 +150,7 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='motivation'>
<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>The Extensible Messaging and Presence Protocol (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 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.</p>
<p>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 &xep0246;) and then exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas.</p>
<p>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 <link url='#security'>Security Considerations</link> regarding the ability to "forward" messages from a serverless mesh to an XMPP network or vice-versa).</p>
<p>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).</p>
@ -188,7 +188,7 @@ juliet IN TXT "status=avail"
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 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 <link url='http://www.dns-sd.org/'>dns-sd.org</link> for a complete list).</p>
<p>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 <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 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.</p>
<code><![CDATA[
<stream:stream
@ -297,11 +297,11 @@ _presence._tcp <ttl> SRV <priority> <weight> port-number machine-name.local.
<owner> IN <ttl> TXT "vc=capabilities-string"
<owner> IN <ttl> TXT "ver=entity-capabilities-identity"
]]></code>
<p>Note: In accordance with Section 6.7 of <cite>draft-cheshire-dnsext-dns-sd</cite>, the "txtvers" record should be the first record specified.</p>
<p>Note: In accordance with Section 6.7 of <cite>draft-cheshire-dnsext-dns-sd</cite>, the "txtvers" record SHOULD be the first record specified.</p>
</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 "pronto", the username is "juliet", 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>
<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" can 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 "pronto", the username is "juliet", the chosen port is "5562", the IP address is "10.2.1.187", and the personal information is that plausibly associated with a certain Shakespearean character, the DNS records would be as follows:</p>
<code><![CDATA[
_presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
@ -325,14 +325,14 @@ juliet IN TXT "vc=CA!"
juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
]]></code>
<p>The IPv4 and IPv6 addresses associated with a machine may vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See <cite>RFC 3927</cite> for details.</p>
<p>The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See <cite>RFC 3927</cite> for details.</p>
<p>If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.</p>
<p>If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.</p>
<section2 topic='TXT Records' anchor='txt'>
<p>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 &REGISTRAR; maintains a registry of TXT records for use with the _presence._tcp service type, as specified in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
<p>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.</p>
<p>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).</p>
<p>Note: See the <link url='#security'>Security Considerations</link> section of this document regarding the inclusion of information that may have an impact on personal privacy (e.g., the "1st", "last", "nick", "email", and "jid" records).</p>
<p>Note: See the <link url='#security'>Security Considerations</link> 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).</p>
</section2>
</section1>
@ -411,7 +411,7 @@ juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Multiple Network Interfaces' anchor='impl-network'>
<p>Devices that use serverless messaging may 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.</p>
<p>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.</p>
</section2>
<section2 topic='Buddy Icons' anchor='impl-icons'>
<p>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:</p>
@ -500,10 +500,10 @@ _presence._tcp.local. IN NULL raw-binary-data-here
</status>
</record>
]]></code>
<p>The registrant may register more than one TXT record at a time, each contained in a separate &lt;record/&gt; element.</p>
<p>The registrant can register more than one TXT record at a time, each contained in a separate &lt;record/&gt; element.</p>
</section3>
<section3 topic='Initial Registration' anchor='registrar-linklocal-reg'>
<p>The following submission registers TXT records in use as of June 2007. Refer to the registry itself for a complete and current list of TXT records (this specification may or may not be revised when new TXT records are registered).</p>
<p>The following submission registers TXT records in use as of June 2007. Refer to the registry itself for a complete and current list of TXT records (this specification might or might not be revised when new TXT records are registered).</p>
<code><![CDATA[
<record>
@ -515,7 +515,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<record>
<name>email</name>
<desc>
The email address of the user; may contain a space-separated list
The email address of the user; can contain a space-separated list
of more than one email address.
</desc>
<status>optional</status>
@ -544,7 +544,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<record>
<name>jid</name>
<desc>
The Jabber ID of the user; may contain a space-separated list of
The Jabber ID of the user; can contain a space-separated list of
more than one JID.
</desc>
<status>recommended</status>
@ -587,9 +587,9 @@ _presence._tcp.local. IN NULL raw-binary-data-here
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
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>
@ -614,7 +614,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
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
respectively; if the status record is not included, the status SHOULD
be assumed to be "avail".
</desc>
<status>recommended</status>
@ -624,7 +624,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<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
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>