moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

0.14

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@833 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-05-12 02:05:07 +00:00
parent 1574fe49f2
commit a9720bf277
1 changed files with 40 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
xep-0174.xml
View File

@ -25,6 +25,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<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>
</revision>
<revision>
<version>0.13</version>
<date>2007-03-28</date>
@ -35,7 +41,7 @@
<version>0.12</version>
<date>2007-03-26</date>
<initials>psa</initials>
<remark><p>Specified creation of registry for TXT records.</p></remark>
<remark><p>Specified creation of registry for TXT records and hardcoded txtvers record value at 1.</p></remark>
</revision>
<revision>
<version>0.11</version>
@ -178,7 +184,7 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo
<owner> IN <ttl> TXT "phsh=sha1-hash-of-avatar"
<owner> IN <ttl> TXT "port.p2pj=5298"
<owner> IN <ttl> TXT "status=avail-away-or-dnd"
<owner> IN <ttl> TXT "txtvers=2"
<owner> IN <ttl> TXT "txtvers=1"
<owner> IN <ttl> TXT "vc=capabilities-string"
<owner> IN <ttl> TXT "ver=application-version"
]]></code>
@ -204,29 +210,31 @@ psa IN TXT "node=http://www.apple.com/ichat/caps"
psa IN TXT "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
psa IN TXT "port.p2pj=5298"
psa IN TXT "status=avail"
psa IN TXT "txtvers=2"
psa IN TXT "txtvers=1"
psa IN TXT "vc=CA!"
psa IN TXT "ver=524"
]]></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 "10.2.1.187" but when the machine is connected to a wireless network, its physical address might change to "10.10.1.179".</p>
<p>In the unlikely event that the "presence name" (username@machine-name) asserted by a client is already taken by another entity on the network, the client MUST choose a different presence name, which SHOULD be formed by adding the digit "1" to the end of the username string, adding the digit "2" if the resulting presence name is already taken, and incrementing the digit until a unique presence name is constructed.</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., "roundabout-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "roundabout-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., "stpeter-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "stpeter-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; shall maintain 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, since link-local messaging can be used by non-human entities (e.g., devices) and these records relate to human users. However, for use by humans, certain records are of greater interest than others, e.g. the "msg", "nick", and "status" records.</p>
<p>It is OPTIONAL to include any of these TXT records, and an implementation MUST NOT fail (i.e., MUST enable link-local messaging) even if none of the TXT records are provided by another local 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, link-local 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>
</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" MUST be obtained from the &lt;Instance&gt; portion of the received PTR record for each user; the client MAY 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>
</section1>
<section1 topic='Capabilities Discovery' anchor='caps'>
<p>Because link-local communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is REQUIRED to instead include the node and ver TXT records (and OPTIONAL to include the ext TXT record). The values of these records MUST be the same as the values for the 'node', 'ver', and 'ext' attributes that are advertised for the application in XMPP presence (if any) via the Entity Capabilities protocol as described in <cite>XEP-0115</cite>.</p>
<section1 topic='Discovering Capabilities' anchor='caps'>
<p>Because link-local communication does not involve the exchange of XMPP presence, it is not possible to use &xep0115; for capabilities discovery. Therefore, it is RECOMMENDED to instead include the node and ver TXT records (and OPTIONAL to include the ext TXT record). The values of these records MUST be the same as the values for the 'node', 'ver', and 'ext' attributes that are advertised for the application in XMPP presence (if any) via the Entity Capabilities protocol as described in <cite>XEP-0115</cite>.</p>
</section1>
<section1 topic='Establishing XML Streams' anchor='streams'>
<section1 topic='Initiating a Messaging Session' anchor='initiate'>
<p>In order to exchange link-local messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 3920</cite>.</p>
<p>First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for a local entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:</p>
<example caption="Opening a Stream"><![CDATA[
@ -251,22 +259,19 @@ psa IN TXT "ver=524"
<example caption="Recipient Sends Stream Features"><![CDATA[
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
]]></example>
<p>The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. See the <link url='#security'>Security Considerations</link> section of this document regarding methods for authenticating and encrypting the stream.</p>
</section1>
<section1 topic='Exchanging Messages' anchor='comms'>
<p>Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: <note>The "JIDs" MUST be of the form "username@machine-name" as discovered via SRV (this is the &lt;Instance&gt; portion of the Service Instance Name).</note></p>
<section1 topic='Exchanging Messages' anchor='exchange'>
<p>Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: <note>The to and from addresses MUST be of the form "username@machine-name" as discovered via SRV (this is the &lt;Instance&gt; portion of the Service Instance Name).</note></p>
<example caption="Sending a Message"><![CDATA[
<message to='hildjj@wolfram' from='stpeter@roundabout'>
<body>hey, testing out link-local messaging</body>
<body>Hey, I'm testing out link-local messaging!</body>
</message>
]]></example>
</section1>
<section1 topic='Ending a Chat' anchor='end'>
<section1 topic='Ending a Messaging Session' anchor='end'>
<p>To end the chat, either party closes the XML stream:</p>
<example caption="Ending the Chat"><![CDATA[
</stream:stream>
@ -307,17 +312,20 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<li>Negotiate the use of TLS and SASL for the XML stream as described in <cite>RFC 3920</cite>.</li>
<li>Negotiate encryption with identity checking for the message exchange using &xep0116;.</li>
</ol>
<p>It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client MUST warn the human user that the channel is unauthenticated and unencrypted.</p>
<p>It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client SHOULD warn the human user that the channel is unauthenticated and unencrypted.</p>
</section2>
<section2 topic='Stanza Injection' anchor='security-inject'>
<p>Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in <cite>RFC 3920</cite>. However, a client on a local mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).</p>
</section2>
<section2 topic='TXT Record Data' anchor='security-txt'>
<p>Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).</p>
</section2>
<section2 topic='Private Information' anchor='security-priv'>
<p>The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. As far as is known, the port number does not need to be registered with the IANA.</p>
<p>The (deprecated) "p2pj" port number 5298 is not included in the &ianaports; maintained by &IANA;. As far as is known, the port number does not need to be registered with the IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Link-Local TXT Records Registry' anchor='registrar-linklocal'>
@ -341,7 +349,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<p>The registrant may 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 March 2007. Refer to the registry itself for a complete and current list of TXT records.</p>
<p>The following submission registers TXT records in use as of April 2007. Refer to the registry itself for a complete and current list of TXT records.</p>
<code><![CDATA[
<record>
@ -351,7 +359,10 @@ _presence._tcp.local. IN NULL raw-binary-data-here
</record>
<record>
<name>email</name>
<desc>The email address of the user.</desc>
<desc>
The email address of the user; may contain a space-separated list
of more than one email address.
</desc>
<status>optional</status>
</record>
<record>
@ -360,13 +371,16 @@ _presence._tcp.local. IN NULL raw-binary-data-here
A space-separated list of extensions; the value of this record MUST
be the same as that provided via normal XMPP presence (if applicable)
in the 'ext' attribute specified in XEP-0115; for details, refer to
the Capabilities Discovery section of XEP-0174.
the Discovering Capabilities section of XEP-0174.
</desc>
<status>recommended</status>
</record>
<record>
<name>jid</name>
<desc>The Jabber ID of the user.</desc>
<desc>
The Jabber ID of the user; may contain a space-separated list of
more than one JID.
</desc>
<status>recommended</status>
</record>
<record>
@ -393,7 +407,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
A unique identifier for the application; the value of this record MUST
be the same as that provided via normal XMPP presence (if applicable)
in the 'node' attribute specified in XEP-0115; for details, refer to
the Capabilities Discovery section of XEP-0174.
the Discovering Capabilities section of XEP-0174.
</desc>
<status>recommended</status>
</record>
@ -452,7 +466,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
in the string is immaterial. NOTE: This flag is included only for
backwards-compatibility; implementations SHOULD use the node, ver,
and ext records for more robust capabilities discovery as described
in the Capabilities Discovery section of XEP-0174.
in the Discovering Capabilities section of XEP-0174.
</desc>
<status>optional</status>
</record>
@ -461,7 +475,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<desc>
The application version; the value of this record MUST be the same as that
provided via normal XMPP presence (if applicable) in the 'ver' attribute
specified in XEP-0115; for details, refer to the Capabilities Discovery
specified in XEP-0115; for details, refer to the Discovering Capabilities
section of XEP-0174.
</desc>
<status>recommended</status>
@ -472,6 +486,6 @@ _presence._tcp.local. IN NULL raw-binary-data-here
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Jens Alfke, Justin Karneges, Marc Krochmal, and Sjoerd Simons for their input.</p>
<p>Thanks to Jens Alfke, Justin Karneges, Marc Krochmal, Eric St. Onge, and Sjoerd Simons for their input.</p>
</section1>
</xep>