0.11

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@650 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0174.xml

@@ -25,6 +25,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <version>0.11</version>
+    <date>2007-03-14</date>
+    <initials>psa</initials>
+    <remark><p>Added section on capabilities discovery; added TXT fields corresponding to the node, ver, and ext attributes from XEP-0115; changed textvers value to 2.</p></remark>
+  </revision>
   <revision>
     <version>0.10</version>
     <date>2007-03-13</date>
@@ -151,15 +157,18 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo
       <code><![CDATA[
 <owner> IN <ttl> TXT "1st=user-first-name"
 <owner> IN <ttl> TXT "email=user-email-address"
+<owner> IN <ttl> TXT "ext=optional-list-of-extensions"
 <owner> IN <ttl> TXT "jid=user-jabber-id"
 <owner> IN <ttl> TXT "last=user-last-name"
 <owner> IN <ttl> TXT "msg=freeform-availability-status"
 <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 "status=avail-away-or-dnd"
-<owner> IN <ttl> TXT "txtvers=1"
+<owner> IN <ttl> TXT "txtvers=2"
 <owner> IN <ttl> TXT "vc=capabilities-string"
+<owner> IN <ttl> TXT "ver=application-version"
       ]]></code>
     </li>
   </ol>
@@ -174,15 +183,19 @@ _presence._tcp.local. 5526 IN PTR stpeter@roundabout._presence._tcp.local.
 
 psa IN TXT "1st=Peter"
 psa IN TXT "email=stpeter@jabber.org"
+psa IN TXT "ext=rcd sgc auxvideo sgs mvideo avavail avcap maudio"
 psa IN TXT "jid=stpeter@jabber.org"
 psa IN TXT "last=Saint-Andre"
 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 "status=avail"
-psa IN TXT "txtvers=1"
+psa IN TXT "txtvers=2"
 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> 
@@ -201,6 +214,10 @@ psa IN TXT "vc=CA!"
       <td>email</td>
       <td>The email address of the user.</td>
     </tr>
+    <tr>
+      <td>ext</td>
+      <td>A space-separated list of extensions; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ext' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
+    </tr>
     <tr>
       <td>jid</td>
       <td>The Jabber ID of the user.</td>
@@ -217,6 +234,10 @@ psa IN TXT "vc=CA!"
       <td>nick</td>
       <td>A friendly or informal name for the user.</td>
     </tr>
+    <tr>
+      <td>node</td>
+      <td>A unique identifier for the application; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'node' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
+    </tr>
     <tr>
       <td>phsh</td>
       <td>The SHA-1 hash of the user's avatar icon or photo. <note>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.</note> 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).</td>
@@ -231,11 +252,15 @@ psa IN TXT "vc=CA!"
     </tr>
     <tr>
       <td>txtvers</td>
-      <td>The version of the TXT fields supported by the client. This document describes txtvers "1".</td>
+      <td>The version of the TXT fields supported by the client. This document describes txtvers "2". <note>Version 1 did not include the ext, nick, node, and ver TXT fields.</note></td>
     </tr>
     <tr>
       <td>vc</td>
-      <td>A flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial. NOTE: This flag is included for backwards-compatibility only; implementations SHOULD use &xep0030; and &xep0115; for more robust capabilities discovery.</td>
+      <td>A flag advertising the user's ability to engage in audio or video conferencing. If the user is able to engage in audio conferencing, the string MUST include the "A" character. If the user is able to engage in video conferencing, the string MUST include the "V" character. If the user is able to engage in conferencing with more than one participant, the string MUST include the "C" character. If the user is not currently engaged in an audio or video conference, the string MUST include the "!" character. The order of characters in the string is immaterial. NOTE: This flag is included for backwards-compatibility only; implementations SHOULD use the node, ver, and ext keys for more robust capabilities discovery as described in the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
+    </tr>
+    <tr>
+      <td>ver</td>
+      <td>The application version; the value of this field MUST be the same as that provided via normal XMPP presence (if applicable) in the 'ver' attribute specified in <cite>XEP-0115</cite>; for details, refer to the <link url='#disco'>Capabilities Discovery</link> section of this document.</td>
     </tr>
   </table>
   <p>It is OPTIONAL to include any of these TXT keys, since link-local messaging can be used by non-human entities (e.g., devices) and these keys relate to human users. However, for use by humans, certain keys are of greater interest than others, e.g. the "msg" and "status" keys. See also 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" keys).</p>
@@ -247,6 +272,9 @@ psa IN TXT "vc=CA!"
 <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='disco'>
+  <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 fields (and OPTIONAL to include the ext TXT field). The values of these fields 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'>
   <p>In order to exchange link-local messages, the sender and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 3920</cite>.</p>
   <p>First, the initating party 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>