0.10

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

xep-0174.xml

@@ -25,6 +25,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <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>
+  </revision>
   <revision>
     <version>0.9</version>
     <date>2006-12-22</date>
@@ -123,7 +129,7 @@
   <p>In order to advertise its availability for link-local messaging, a client MUST publish four different kinds of DNS records:</p>
   <ol>
     <li>
-      <p>An address ("A") record of the following form:</p>
+      <p>An address ("A" or "AAAA") record of the following form: <note>The IP address MAY be either an IPv4 address or an IPv6 address.</note></p>
       <code><![CDATA[
 machine-name.local. A ip-address
       ]]></code>
@@ -148,6 +154,7 @@ _presence._tcp.local. port-number IN PTR username@machine-name._presence._tcp.lo
 <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 "phsh=sha1-hash-of-avatar"
 <owner> IN <ttl> TXT "port.p2pj=5298"
 <owner> IN <ttl> TXT "status=avail-away-or-dnd"
@@ -170,6 +177,7 @@ psa IN TXT "email=stpeter@jabber.org"
 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 "phsh=a3839614e1a382bcfebbcf20464f519e81770813"
 psa IN TXT "port.p2pj=5298"
 psa IN TXT "status=avail"
@@ -205,6 +213,10 @@ psa IN TXT "vc=CA!"
       <td>msg</td>
       <td>Natural-language text describing the user's state. This is equivalent to the XMPP &STATUS; element.</td>
     </tr>
+    <tr>
+      <td>nick</td>
+      <td>A friendly or informal name for the user.</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>
@@ -226,7 +238,7 @@ psa IN TXT "vc=CA!"
       <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.</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", "email", and "jid" keys).</p>
+  <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>
 </section2>
 </section1>
 <section1 topic='Discovering Other Users' anchor='disco'>
@@ -237,13 +249,30 @@ psa IN TXT "vc=CA!"
 </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 with no 'to' or 'from' address:</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>
   <example caption="Opening a Stream"><![CDATA[
-<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
+<stream:stream 
+        xmlns='jabber:client' 
+        xmlns:stream='http://etherx.jabber.org/streams'
+        from='stpeter@roundabout'
+        to='hildjj@wolfram'>
   ]]></example>
   <p>The recipient then responds with a stream header as well:</p>
   <example caption="Stream Header Response"><![CDATA[
-<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
+<stream:stream 
+        xmlns='jabber:client' 
+        xmlns:stream='http://etherx.jabber.org/streams'>
+        from='hildjj@wolfram'
+        to='stpeter@roundabout'>
+  ]]></example>
+  <p>The recipient SHOULD also send stream features as specified in <cite>RFC 3920</cite>:</p>
+  <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>
@@ -312,6 +341,6 @@ _presence._tcp.local. IN NULL raw-binary-data-here
   <p>This document requires no interaction with the &REGISTRAR;.</p>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to Justin Karneges, Jens Alfke, and Marc Krochmal for their input.</p>
+  <p>Thanks to Jens Alfke, Justin Karneges, Marc Krochmal, and Sjoerd Simons for their input.</p>
 </section1>
 </xep>