diff --git a/xep-0260.xml b/xep-0260.xml
index fa1eaa4c..174e1a04 100644
--- a/xep-0260.xml
+++ b/xep-0260.xml
@@ -25,10 +25,16 @@
   &stpeter;
   &dmeyer;
   &infiniti;
+  <author>
+    <firstname>Klaus</firstname>
+    <surname>Hartke</surname>
+    <email>klaus.hartke@googlemail.com</email>
+    <jid>nx@jabber.org</jid>
+  </author>
   <revision>
     <version>0.3</version>
     <date>2009-07-14</date>
-    <initials>dm/psa/jk</initials>
+    <initials>dm/kh/psa/jk</initials>
     <remark><p>Major update to make Jingle S5B inherit more features from ICE and ICE-TCP. Added priorities and candidate identifiers. Renamed streamhost element to candidate element. Updated candidate selection to use priorities, and it is now required for both clients to send a candidate-used or candidate-error notification. Defined type attribute to differentiate between various kinds of candidates. More clearly described how S5B negotiation is completed, including an activated notification from responder to initiator when the candidate used is a proxy. Noted reuse of fast-mode methodology from S5B optimization specification. Because of incompatibilities with the previous version, changed the namespace to urn:xmpp:jingle:transports:s5b:1.</p></remark>
   </revision>
   <revision>
@@ -52,8 +58,8 @@
   <revision>
     <version>0.0.2</version>
     <date>2009-02-11</date>
-    <initials>dm</initials>
-    <remark><p>Add additional text to use NAT assisting protocols and allow the responder to also send &lt;streamhost/&gt; information. This change required the introduction of streamhost-used and streamhost-error.</p></remark>
+    <initials>dm/jk</initials>
+    <remark><p>Specified that the responder can send &lt;streamhost/&gt; candidates, consistent with the earlier S5B optimization extension; this change required the introduction of streamhost-used and streamhost-error. Also added text to encourage the use of NAT-assisting protocols.</p></remark>
   </revision>
   <revision>
     <version>0.0.1</version>
@@ -194,22 +200,27 @@ priority = (2^16)*(type preference) + (local preference)
     <p>The type preference is an integer value between 0 and 127. The following types and their suggested preference values are defined here:</p>
     <table caption='Defined Types'>
       <tr>
+	<th>Type</th>
 	<th>Description</th>
 	<th>Preference Value</th>
       </tr>
       <tr>
+	<td>direct</td>
 	<td>Direct connection using the given interface</td>
 	<td>126</td>
       </tr>
       <tr>
+	<td>assisted</td>
 	<td>Direct connection using NAT assisting technologies like NAT-PMP or UPnP-IGD</td>
 	<td>120</td>
       </tr>
       <tr>
+	<td>tunnel</td>
 	<td>Tunnel protocols such as Teredo</td>
 	<td>110</td>
       </tr>
       <tr>
+	<td>proxy</td>
 	<td>SOCKS5 Relay</td>
 	<td>10</td>
       </tr>
@@ -278,7 +289,7 @@ priority = (2^16)*(type preference) + (local preference)
       <li>If both parties send a candidate-used notification but the candidates have a different priority, then the candidate with the lower priority shall be considered the nominated candidate.</li>
       <li>If both parties send a candidate-used notification with candidates having the same priority, then the candidate chosen by the initiator shall be considered the nominated candidate (consistent with the rules in <cite>XEP-0166</cite>).</li>
     </ol>
-    <p>The parties shall use the nominated candidate for the data transfer. If the nominated candidate is of the proxy type <em>and</em> it was offered by the responder, then the initiator has no way to know when it can send data. Therefore the responder MUST send an activated notification to the initiator once it has activated the bytestream (as described in <cite>XEP-0065</cite>); it does so by sending a transport-info message containing an &lt;activated/&gt; element as follows.</p>
+    <p>The parties shall use the nominated candidate for the data transfer. If the nominated candidate is of the proxy type, then the peer has no way to know when it can send data. Therefore the party that offered the nominated candidate MUST send an activated notification to the peer once it has activated the bytestream (as described in <cite>XEP-0065</cite>); it does so by sending a transport-info message containing an &lt;activated/&gt; element as follows.</p>
     <example caption="Responder informs initiator that bytestream has been activated"><![CDATA[
 <iq from='juliet@capulet.lit/balcony'
     id='bv73bs91'
@@ -511,9 +522,10 @@ Romeo                               Juliet
           <xs:attribute name='type' use='optional' default='direct'>
             <xs:simpleType>
               <xs:restriction base='xs:NCName'>
+                <xs:enumeration value='assisted'/>
                 <xs:enumeration value='direct'/>
                 <xs:enumeration value='proxy'/>
-                <xs:enumeration value='teredo'/>
+                <xs:enumeration value='tunnel'/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>