Update to spec 0.17.22

30 files changed, 653 insertions, 258 deletions

diff --git a/spec/Channel_Dispatch_Operation.xml b/spec/Channel_Dispatch_Operation.xml
index 6f728c354..fdee9445d 100644
--- a/spec/Channel_Dispatch_Operation.xml
+++ b/spec/Channel_Dispatch_Operation.xml
@@ -191,7 +191,7 @@
         The well known bus names (starting with
         <code>org.freedesktop.Telepathy.Client.</code>) of the possible
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
+          namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>s
         for these channels. The channel dispatcher MUST place the most
         preferred handlers first, according to some reasonable heuristic.
         As a result, approvers SHOULD use the first handler by default.
diff --git a/spec/Channel_Dispatcher_Interface_Operation_List.xml b/spec/Channel_Dispatcher_Interface_Operation_List.xml
index b59ef72a3..7a1c0e1c2 100644
--- a/spec/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/spec/Channel_Dispatcher_Interface_Operation_List.xml
@@ -51,7 +51,7 @@
         <tp:docstring>
           The object path of the
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>.
+            namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>.
         </tp:docstring>
       </tp:member>
 
diff --git a/spec/Channel_Future.xml b/spec/Channel_Future.xml
index 823d8a0da..5bbca17b1 100644
--- a/spec/Channel_Future.xml
+++ b/spec/Channel_Future.xml
@@ -50,7 +50,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         pseudo-interface)</tp:added>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle</tp:dbus-ref>
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle.DRAFT</tp:dbus-ref>
           to which this channel belongs.</p>
 
         <p>A channel's Bundle property can never change.</p>
diff --git a/spec/Channel_Interface_Call_State.xml b/spec/Channel_Interface_Call_State.xml
index 0df6e3472..eec6a4b34 100644
--- a/spec/Channel_Interface_Call_State.xml
+++ b/spec/Channel_Interface_Call_State.xml
@@ -20,12 +20,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Channel.Interface.CallState">
     <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
 
-    <tp:docstring>
-      An interface for streamed media channels that can indicate call
-      progress or call states. The presence of this interface is no guarantee
-      that call states will actually be signalled (for instance, SIP
-      implementations are not guaranteed to generate status 180 Ringing,
-      so a call can be accepted without the Ringing flag ever having been set).
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface for streamed media channels that can indicate call
+        progress or call states. The presence of this interface is no guarantee
+        that call states will actually be signalled (for instance, SIP
+        implementations are not guaranteed to generate status 180 Ringing, so a
+        call can be accepted without the Ringing flag ever having been set).</p>
+
+      <p>To notify the other participant in the call that they are on hold,
+        see <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel.Interface"
+          >Hold</tp:dbus-ref>.</p>
     </tp:docstring>
     <tp:added version="0.17.2"/>
 
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group.xml
index 9c7e25446..db17a0b17 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group.xml
@@ -242,7 +242,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </tp:flag>
       <tp:flag suffix="Message_Depart" value="8192">
-        <tp:added version="0.17.UNRELEASED"/>
+        <tp:added version="0.17.21"/>
         <tp:docstring>
           A message may be sent to the server when calling
           <tp:member-ref>RemoveMembers</tp:member-ref> on
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold.xml
index 835aff926..1e3a832d9 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold.xml
@@ -26,7 +26,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Interface for channels where you may put the channel on hold.
         This only makes sense for channels where
-        you are streaming media to or from the members.</p>
+        you are streaming media to or from the members. (To see whether the
+        other participant has put you on hold, see <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel.Interface">CallState</tp:dbus-ref>.)</p>
 
       <p>If you place a channel on hold, this indicates that you do not wish
         to be sent media streams by any of its members and will be ignoring
diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml
index b69e5b352..5c2931646 100644
--- a/spec/Channel_Interface_Media_Signalling.xml
+++ b/spec/Channel_Interface_Media_Signalling.xml
@@ -103,43 +103,49 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         within.
       </tp:docstring>
     </signal>
-    <tp:property name="nat-traversal" type="s">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A string indicating the NAT traversal techniques employed by the
-      streams within this channel. Can be protocol-specific values, but the
-      following values should be used if appropriate:</p>
-
-      <dl>
-        <dt>none</dt>
-        <dd>No attempt should be made at NAT traversal.</dd>
-
-        <dt>stun</dt>
-        <dd>If appropriate, a STUN request should be made to the given server
-        to open a UDP port mapping and determine the external IP.</dd>
 
-        <dt>gtalk-p2p</dt>
-        <dd>Google Talk peer-to-peer connectivity establishment should be used,
-        as implemented in libjingle 0.3.</dd>
-
-        <dt>ice-udp</dt>
-        <dd>
-          Interactive Connectivity Establishment should be used, as defined by
-          the IETF MMUSIC working group.
-        </dd>
-      </dl>
+    <tp:property name="nat-traversal" type="s">
+      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
+        property on the Media.StreamHandler, if available; use this
+        as a fallback.</tp:deprecated>
+      <tp:docstring>
+        A string indicating the NAT traversal techniques employed by the
+        streams within this channel if they do not have a <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
+        property. The possible values are the same as for the NATTraversal
+        property on the streams.
       </tp:docstring>
     </tp:property>
+
     <tp:property name="stun-server" type="s">
+      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
+        property on the Media.StreamHandler, if available; use this
+        as a fallback.</tp:deprecated>
       <tp:docstring>
-      The IP address or hostname of the STUN server to use for NAT traversal.
+        The IP address or hostname of the STUN server to use for NAT traversal
+        if the individual streams do not specify one.
       </tp:docstring>
     </tp:property>
+
     <tp:property name="stun-port" type="q">
+      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
+        property on the Media.StreamHandler, if available; use this
+        as a fallback.</tp:deprecated>
       <tp:docstring>
       The UDP port number to use on the provided STUN server.
       </tp:docstring>
     </tp:property>
+
     <tp:property name="gtalk-p2p-relay-token" type="s">
+      <tp:deprecated version="0.17.22">XMPP connection managers
+        supporting the Google Talk relay server SHOULD make the necessary
+        HTTP requests to find a username and password, and use those
+        to populate the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Media.StreamHandler">RelayInfo</tp:dbus-ref>
+        property on the Media.StreamHandler.</tp:deprecated>
       <tp:docstring>
       The authentication token for use with the Google Talk peer-to-peer relay
       server.
diff --git a/spec/Channel_Interface_Media_Signalling_Future.xml b/spec/Channel_Interface_Media_Signalling_Future.xml
index d908450be..102f20640 100644
--- a/spec/Channel_Interface_Media_Signalling_Future.xml
+++ b/spec/Channel_Interface_Media_Signalling_Future.xml
@@ -67,9 +67,31 @@
           properties list of the channel class that advertises a contact's
           ability to receive streamed media calls.</p>
 
-        <p>Clients that are able to receive calls with particular NAT
-          traversal mechanisms MAY include the following filters if
-          calling <tp:dbus-ref
+        <p>Clients SHOULD NOT pass ICETransportAvailable and similar
+          properties to <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
+          or similar functions. If they do, the connection manager MUST
+          accept and ignore any such property that is in the allowed properties
+          list.</p>
+
+        <tp:rationale>
+          <p>There is currently no way for clients to influence the choice
+            of transport: in general, a client making a call can't know the
+            capabilities of the streaming implementation, or even which
+            streaming implementation will be used (channels will often be
+            requested by an address book or similar application that will not
+            handle the channel itself).</p>
+
+          <p>If a mechanism for transport negotiation is added, it should be
+            something that happens after the request, but before calling
+            <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">Media.SessionHandler.Ready</tp:dbus-ref>,
+            so that it is the streaming implementation that chooses the
+            transport, rather than the requesting client.</p>
+        </tp:rationale>
+
+        <p>Clients that are able to receive calls with particular transports
+          MUST include the following filters if calling <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
           (clients of a <tp:dbus-ref
             namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</tp:dbus-ref>
@@ -87,71 +109,13 @@
         </ul>
 
         <p>Connection managers MAY use this information to adjust the
-          transports for which they advertise support to other contacts.
-          If a client has indicated support for any particular transports,
-          the connection manager SHOULD advertise support for
-          each transport that is supported by any client, and also
-          supported by the CM itself.</p>
+          transports for which they advertise support to other contacts.</p>
 
         <tp:rationale>
-          <p>This minimizes the possibility that a call will be started that
-            cannot in fact succeed, because the intersection of the contacts'
-            available transports is empty.</p>
+          <p>In particular, in XMPP, the connection manager will not be
+            callable unless a client has told it to advertise support for
+            at least one transport.</p>
         </tp:rationale>
-
-        <p>If no client has mentioned any of the transports known to the
-          connection manager in a call to SetSelfCapabilities, the connection
-          manager SHOULD advertise support for every transport that it can
-          signal.</p>
-
-        <tp:rationale>
-          <p>This simplifies implementation on integrated platforms like Maemo,
-            where it can be assumed that client libraries will support all the
-            "standard" transports known to any connection manager, and
-            lowers the "barrier to entry" for new Telepathy clients.</p>
-        </tp:rationale>
-
-        <p>Clients making outgoing calls for which the same client that made
-          the request will handle the streaming MAY indicate their ability or
-          inability to handle particular transports by including
-          <code>ICETransportAvailable = true</code>,
-          <code>RawUDPTransportAvailable = false</code>, etc.
-          in the request properties parameter of their call to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
-          or similar functions. When they do so, the connection manager
-          SHOULD attempt to use a transport that the client has indicated
-          it is able to handle; if this is not possible, the connection
-          manager SHOULD raise an error instead of creating a channel.</p>
-
-        <tp:rationale>
-          <p>This enables such clients to restrict the CM to the subset of
-            transports supported by that particular client.</p>
-        </tp:rationale>
-
-        <p>Clients making outgoing calls for which they will not themselves
-          handle the streaming (e.g. an address book starting a call which
-          will be streamed by a separate call UI) SHOULD NOT include those
-          properties in the request.</p>
-
-        <tp:rationale>
-          <p>In general, such a client can't know the capabilities of the
-            streaming implementation, or even which streaming implementation
-            will be used.</p>
-        </tp:rationale>
-
-        <p>In the absence of any indication of supported transports from the
-          client, the connection manager SHOULD assume that the transports
-          indicated by calling SetSelfCapabilities are available. If
-          no transports were indicated as supported by calling
-          SetSelfCapabilities either, it SHOULD assume that any transport
-          that it can signal will be acceptable.</p>
-
-        <p>If this property, or any of the similar transport availability
-          properties, is passed to EnsureChannel (as opposed to CreateChannel),
-          the connection manager SHOULD ignore these properties when checking
-          whether it can return an existing channel as suitable; these
-          properties only become significant when the connection manager has
-          decided to create a new channel.</p>
       </tp:docstring>
     </property>
 
@@ -165,8 +129,8 @@
       </tp:docstring>
     </property>
 
-    <property name="GoogleP2PTransportAvailable"
-      tp:name-for-bindings="Google_P2P_Transport_Available"
+    <property name="GTalkP2PTransportAvailable"
+      tp:name-for-bindings="GTalk_P2P_Transport_Available"
       type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
@@ -176,12 +140,23 @@
       </tp:docstring>
     </property>
 
-    <property name="MSNTransportAvailable"
-      tp:name-for-bindings="MSN_Transport_Available"
+    <property name="WLM85TransportAvailable"
+      tp:name-for-bindings="WLM_8_5_Transport_Available"
+      type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
+          but for the transport implemented by Windows Live Messenger 8.5 or
+          later (which resembles ICE draft 6).</p>
+      </tp:docstring>
+    </property>
+
+    <property name="WLM2009TransportAvailable"
+      tp:name-for-bindings="WLM_2009_Transport_Available"
       type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
-          but for the variant of ICE used by MSN.</p>
+          but for the transport implemented by Windows Live Messenger 2009
+          or later (which resembles ICE draft 19).</p>
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index c012f2f65..c668067d7 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -706,7 +706,8 @@ USA.</p>
       </tp:member>
     </tp:mapping>
 
-    <tp:simple-type type="u" name="Message_Part_Index">
+    <tp:simple-type type="u" name="Message_Part_Index"
+      array-name="Message_Part_Index_List">
       <tp:added version="0.17.17"/>
       <tp:docstring>
         The index of a message part within a message.
diff --git a/spec/Channel_Interface_Tube.xml b/spec/Channel_Interface_Tube.xml
index 8e6eb6514..5d1eda712 100644
--- a/spec/Channel_Interface_Tube.xml
+++ b/spec/Channel_Interface_Tube.xml
@@ -26,9 +26,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       systems to communicate without having to establish network
       connections themselves. Currently, two types of tube exist:
       <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-      >Channel.Type.DBusTube</tp:dbus-ref> and
+      >Channel.Type.DBusTube.DRAFT</tp:dbus-ref> and
       <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-      >Channel.Type.StreamTube</tp:dbus-ref>. This interface contains
+      >Channel.Type.StreamTube.DRAFT</tp:dbus-ref>. This interface contains
       the properties, signals and methods common to both types of tube;
       you can only create channels of a specific tube type, not of this
       type. A tube channel contains exactly one tube; if you need several
@@ -42,8 +42,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <p>As an exception to the usual handling of capabilities, connection managers
         for protocols with capability discovery, such as XMPP, SHOULD advertise the
         capability representing each Tube type that they support
-       (<tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.DBusTube</tp:dbus-ref> and/or
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.StreamTube</tp:dbus-ref>)
+       (<tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.DBusTube.DRAFT</tp:dbus-ref> and/or
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.StreamTube.DRAFT</tp:dbus-ref>)
         even if no client has indicated via
         <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
diff --git a/spec/Channel_Type_Contact_Search.xml b/spec/Channel_Type_Contact_Search.xml
index 204ecf11d..b0e905fd6 100644
--- a/spec/Channel_Type_Contact_Search.xml
+++ b/spec/Channel_Type_Contact_Search.xml
@@ -43,6 +43,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         running search can be cancelled by calling
         <tp:member-ref>Stop</tp:member-ref>.</p>
 
+      <p>If the protocol supports limiting the number of results returned by a
+        search and subsequently requesting more results, after
+        <tp:member-ref>Limit</tp:member-ref> results have been received the
+        search state will be set to <code>More_Available</code>. Clients may
+        call <tp:member-ref>More</tp:member-ref> to request another
+        <tp:member-ref>Limit</tp:member-ref> results. If allowed by the
+        connection manager, clients may specify the "page size" by specifying
+        <tp:member-ref>Limit</tp:member-ref> when calling
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+        </p>
+
       <p>The client should call the channel's <tp:dbus-ref
         namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
         method when it is finished with the channel, so that any handles held
@@ -73,10 +84,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:enumvalue suffix="In_Progress" value="1">
         <tp:docstring>The search is in progress</tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Completed" value="2">
+      <tp:enumvalue suffix="More_Available" value="2">
+        <tp:docstring>The search has paused, but more results can be retrieved
+          by calling <tp:member-ref>More</tp:member-ref>.</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Completed" value="3">
         <tp:docstring>The search has been completed</tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Failed" value="3">
+      <tp:enumvalue suffix="Failed" value="4">
         <tp:docstring>The search has failed</tp:docstring>
       </tp:enumvalue>
     </tp:enum>
@@ -127,6 +142,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <ul>
           <li><code>Not_Started</code> → <code>In_Progress</code></li>
+          <li><code>In_Progress</code> → <code>More_Available</code></li>
+          <li><code>More_Available</code> → <code>In_Progress</code></li>
           <li><code>In_Progress</code> → <code>Completed</code></li>
           <li><code>In_Progress</code> → <code>Failed</code></li>
         </ul>
@@ -215,35 +232,33 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
               Gadu-Gadu and TOC appear to support this.
             </tp:rationale>
           </dd>
-
-          <dt><code>x-search-offset</code></dt>
-          <dd>
-            <p>For protocols that support paging results, the offset from the
-              start of the results that should be returned, i.e. the number of
-              contacts from the beginning that should be omitted.</p>
-
-            <p>For example, if the search terms match 50 contacts, this key
-              is set to <code>"20"</code> and <code>x-search-limit</code>
-              is set to <code>"10"</code>, then the ten contacts from the 21st
-              to the 30th should be returned.</p>
-
-            <p>Connection managers for protocols which do not natively support
-              restricting the number of results returned MUST NOT support
-              either this term or <code>x-search-limit</code>: all results
-              should be signalled, and the client can provide its own paging as
-              desired.</p>
-          </dd>
-
-          <dt><code>x-search-limit</code></dt>
-          <dd>For protocols that support limiting results, the maximum number
-            of results that should be returned.  For example, if the search
-            terms match <i>Antonius</i>, <i>Bridget</i> and <i>Charles</i> and
-            this key is set to <code>"2"</code>, the search service SHOULD only
-            return <i>Antonius</i> and <i>Bridget</i>.</dd>
         </dl>
       </tp:docstring>
     </tp:simple-type>
 
+    <property name="Limit" type="u" access="read"
+      tp:name-for-bindings="Limit">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If supported by the protocol, the maximum number of results that
+          should be returned, where <code>0</code> represents no limit. If the
+          protocol does not support limiting results, this should be
+          <code>0</code>.</p>
+
+        <p>For example, if the terms passed to
+          <tp:member-ref>Search</tp:member-ref> match <i>Antonius</i>,
+          <i>Bridget</i> and <i>Charles</i> and this property is
+          <code>2</code>, the search service SHOULD only return <i>Antonius</i>
+          and <i>Bridget</i>.</p>
+
+        <p>This property cannot change during the lifetime of the channel.
+          This property SHOULD be in the Allowed_Properties of a
+          <tp:type>Requestable_Channel_Class</tp:type> if and only if the
+          protocol supports specifying a limit; implementations SHOULD use
+          <code>0</code> as the default if possible, or a protocol-specific
+          sensible default otherwise.</p>
+      </tp:docstring>
+    </property>
+
     <property name="AvailableSearchKeys" type="as" access="read"
       tp:name-for-bindings="Available_Search_Keys">
       <tp:docstring>
@@ -310,6 +325,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:possible-errors>
     </method>
 
+    <method name="More" tp:name-for-bindings="More">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Request that a search in <tp:member-ref>SearchState</tp:member-ref>
+        <code>More_Available</code> move back to state <code>In_Progress</code>
+        and continue listing up to <tp:member-ref>Limit</tp:member-ref> more results.
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The <tp:member-ref>SearchState</tp:member-ref> is not
+            <code>More_Available</code>.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
     <method name="Stop" tp:name-for-bindings="Stop">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Stop the current search. This may not be called while the
diff --git a/spec/Channel_Type_Room_List.xml b/spec/Channel_Type_Room_List.xml
index 4170fce3a..93ea77705 100644
--- a/spec/Channel_Type_Room_List.xml
+++ b/spec/Channel_Type_Room_List.xml
@@ -87,7 +87,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dd>The current subject of conversation in the room</dd>
 
           <dt>members (u)</dt>
-          <dd>The number of members of the room</dd>
+          <dd>The number of members in the room</dd>
 
           <dt>password (b)</dt>
           <dd>True if the room requires a password to enter</dd>
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
index 701c8a515..c4ddea7a4 100644
--- a/spec/Channel_Type_Streamed_Media.xml
+++ b/spec/Channel_Type_Streamed_Media.xml
@@ -22,7 +22,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
 
-    <tp:enum name="Media_Stream_Type" type="u">
+    <tp:enum name="Media_Stream_Type" type="u"
+      array-name="Media_Stream_Type_List">
       <tp:enumvalue suffix="Audio" value="0">
         <tp:docstring>An audio stream</tp:docstring>
       </tp:enumvalue>
@@ -86,7 +87,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         name="Pending_Send_Flags"/>
     </tp:struct>
 
-    <tp:simple-type name="Stream_ID" type="u"/>
+    <tp:simple-type name="Stream_ID" type="u"
+      array-name="Stream_ID_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An unsigned integer identifying a stream within a channel.</p>
+      </tp:docstring>
+    </tp:simple-type>
 
     <method name="ListStreams" tp:name-for-bindings="List_Streams">
       <arg direction="out" type="a(uuuuuu)" tp:type="Media_Stream_Info[]"
@@ -118,9 +124,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>ListStreams</tp:member-ref>)
         </tp:docstring>
       </arg>
-      <tp:docstring>
-        Request that the given streams are removed.
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Request that the given streams are removed. If all streams are
+          removed, the channel MAY close.</p>
+
+        <p>Clients SHOULD NOT attempt to terminate calls by removing all the
+          streams; instead, clients SHOULD terminate calls by removing the
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref>
+          from the channel, using either
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembers</tp:dbus-ref>
+          or
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>.
+          </p>
       </tp:docstring>
+
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           A stream identifier is unknown
@@ -209,11 +230,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         MEDIA_STREAM_PENDING_REMOTE_SEND flag set, and the signal emitted again
         with the flag cleared when the remote end has replied.</p>
 
-        <p>If streams of the requested types have already been requested
-          via this method or <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">FUTURE.InitialAudio</tp:dbus-ref>/<tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">FUTURE.InitialVideo</tp:dbus-ref>,
-          this method SHOULD return successfully.</p>
+        <p>If streams of the requested types already exist, calling this
+          method results in the creation of additional streams. Accordingly,
+          clients wishing to have exactly one audio stream or exactly one
+          video stream SHOULD check for the current streams using
+          <tp:member-ref>ListStreams</tp:member-ref> before calling this
+          method.</p>
       </tp:docstring>
       <tp:changed version="0.17.2">
         <p>It is valid to use a handle which is neither
@@ -257,8 +279,54 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           The stream type (a value from MediaStreamType)
         </tp:docstring>
       </arg>
-      <tp:docstring>
-        Emitted when a new stream has been added to this channel.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new stream has been added to this channel.
+          Clients SHOULD assume that the stream's
+          <tp:type>Media_Stream_State</tp:type> is initially Disconnected.</p>
+
+        <p>If a connection manager needs to represent the addition of a stream
+          whose state is already Connecting or Connected, it MUST do this
+          by emitting StreamAdded, closely followed by
+          <tp:member-ref>StreamStateChanged</tp:member-ref> indicating a
+          change to the appropriate state.</p>
+
+        <tp:rationale>
+          <p>Historically, it was not clear from the StreamAdded signal what
+            the state of the stream was. telepathy-spec 0.17.22
+            clarified this.</p>
+        </tp:rationale>
+
+        <p>Similarly, clients SHOULD assume that the initial
+          <tp:type>Media_Stream_Direction</tp:type> of a newly added stream
+          is Receive, and that the initial
+          <tp:type>Media_Stream_Pending_Send</tp:type> is
+          Pending_Local_Send.</p>
+
+        <p>If a connection manager needs to represent the addition of a stream
+          whose direction or pending-send differs from those initial values,
+          it MUST do so by emitting StreamAdded, closely followed by
+          <tp:member-ref>StreamDirectionChanged</tp:member-ref> indicating a
+          change to the appropriate direction and pending-send state.</p>
+
+        <tp:rationale>
+          <p>StreamAdded doesn't itself indicate the stream's direction; this
+            is unfortunate, but is preserved for compatibility.</p>
+
+          <p>This is the appropriate direction for streams added by a remote
+            contact on existing connection managers, and does not violate
+            user privacy by automatically sending audio or video (audio streams
+            start off muted, video streams start off not sending). For
+            streams added by the local user using the client receiving the
+            signal, the true direction can also be determined from the return
+            value of the <tp:member-ref>RequestStreams</tp:member-ref>
+            method.</p>
+
+          <p>Existing clients typically operate by maintaining a separate
+            idea of the directions that they would like the streams to have,
+            and enforcing these intended directions by calling
+            <tp:member-ref>RequestStreamDirection</tp:member-ref> whenever
+            needed.</p>
+        </tp:rationale>
       </tp:docstring>
     </signal>
 
@@ -279,12 +347,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         The new pending send flags (as defined in ListStreams)
         </tp:docstring>
       </arg>
-      <tp:docstring>
-        Emitted when the direction or pending flags of a stream are changed. If
-        the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user has
-        requested that we begin sending on this stream.
-        <tp:member-ref>RequestStreamDirection</tp:member-ref>
-        should be called to indicate whether or not this change is acceptable.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the direction or pending flags of a stream are
+          changed.</p>
+
+        <p>If the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user
+          has requested that we begin sending on this stream.
+          <tp:member-ref>RequestStreamDirection</tp:member-ref>
+          should be called to indicate whether or not this change is
+          acceptable.</p>
+
+        <tp:rationale>
+          <p>This allows for a MSN-style user interface, "Fred has asked you
+            to enable your webcam. (Accept | Reject)", if desired.</p>
+        </tp:rationale>
       </tp:docstring>
     </signal>
 
@@ -367,6 +443,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         which point the contact should appear in the channel's <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemotePendingMembers</tp:dbus-ref>).</p>
 
+      <p>In the past, several other patterns have been used to place outgoing
+        calls; see
+        <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
+        for the details.</p>
+
       <p>Incoming calls should be signalled as <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
         = Contact, <tp:dbus-ref
@@ -377,10 +458,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           namespace="org.freedesktop.Telepathy.Channel.Interface.Group">AddMembers</tp:dbus-ref>
         can be used to move the local user to the group's members.</p>
 
-      <p>In the past, several other patterns have been used to place outgoing
-        calls; see
-        <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
-        for the details.</p>
+      <p>When the local user accepts an incoming call, the connection manager
+        SHOULD change the direction of any streams with pending local send
+        to be sending, without altering whether those streams are
+        receiving.</p>
+
+      <tp:rationale>
+        <p>This matches existing practice, and means that a client
+          can answer incoming calls and get an unmuted microphone/activated
+          webcam without having to take additional action to accept the
+          stream directions.</p>
+
+        <p>It does, however, introduce a race condition: a client believing
+          that it is accepting an audio-only call by calling AddMembers
+          can inadvertantly accept an audio + video call (and hence activate
+          sending from a webcam without the user's permission) if a video
+          stream is added just before AddMembers is processed. This race
+          should be removed when this specification is revised.</p>
+      </tp:rationale>
 
     <p>In general this should be used in conjunction with the <tp:dbus-ref
       namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
diff --git a/spec/Channel_Type_Streamed_Media_Future.xml b/spec/Channel_Type_Streamed_Media_Future.xml
index fa8a01530..5b75c5f17 100644
--- a/spec/Channel_Type_Streamed_Media_Future.xml
+++ b/spec/Channel_Type_Streamed_Media_Future.xml
@@ -118,9 +118,9 @@
         <ul>
           <li>{ ChannelType = StreamedMedia }</li>
           <li>{ ChannelType = StreamedMedia, InitialAudio = true }
-            if receiving audio-only or audio+video calls is supported</li>
+            if receiving calls with audio is supported</li>
           <li>{ ChannelType = StreamedMedia, InitialVideo = true }
-            if receiving video-only or audio+video calls is supported</li>
+            if receiving calls with video is supported</li>
         </ul>
 
         <tp:rationale>
@@ -128,21 +128,6 @@
             like XMPP, need this information to advertise the appropriate
             capabilities for their protocol.</p>
         </tp:rationale>
-
-        <p>If { ChannelType = StreamedMedia } is passed to
-          SetSelfCapabilities, but no more specific channel class for
-          audio or video has been passed to that method (in the presence
-          of a ChannelDispatcher, this would mean that there is at least one
-          client with that channel class in its HandlerChannelFilter, but
-          no installed client has the more specific channel classes in its
-          HandlerChannelFilter), then the connection manager SHOULD advertise
-          support for every content type (audio or video) that it
-          supports.</p>
-
-        <tp:rationale>
-          <p>This lowers the "barrier to entry" by allowing a simple client
-            to say merely that it supports streamed media at all.</p>
-        </tp:rationale>
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index f5828a40b..7d6e314b2 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -21,7 +21,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Channel.Type.Text">
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
 
-    <tp:simple-type name="Message_ID" type="u">
+    <tp:simple-type name="Message_ID" type="u" array-name="Message_ID_List">
       <tp:docstring>
         A unique-per-channel identifier for an incoming message. These
         SHOULD be allocated in a way that minimizes collisions (in particular,
@@ -87,7 +87,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>AcknowledgePendingMessages</tp:member-ref> had also
           been called.
         </tp:docstring>
-        <tp:deprecated since="0.17.3">
+        <tp:deprecated version="0.17.3">
           Setting this to true is NOT RECOMMENDED for clients that
           have some sort of persistent message storage - clients SHOULD only
           acknowledge messages after they have actually stored them, which is
@@ -290,7 +290,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
-    <tp:enum name="Channel_Text_Message_Type" type="u">
+    <tp:enum name="Channel_Text_Message_Type" type="u"
+      array-name="Channel_Text_Message_Type_List">
       <tp:docstring>
         The type of message.
       </tp:docstring>
diff --git a/spec/Channel_Type_Tubes.xml b/spec/Channel_Type_Tubes.xml
index 925ae1bed..2cc0131b0 100644
--- a/spec/Channel_Type_Tubes.xml
+++ b/spec/Channel_Type_Tubes.xml
@@ -71,57 +71,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:member>
     </tp:struct>
 
-    <tp:struct name="Socket_Address_IPv4">
-      <tp:docstring>An IPv4 address and port.</tp:docstring>
-      <tp:member type="s" name="Address">
-        <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
-          numbers, each between 0 and 255 inclusive, e.g.
-          "192.168.0.1".</tp:docstring>
-      </tp:member>
-      <tp:member type="q" name="Port">
-        <tp:docstring>The TCP or UDP port number.</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:struct name="Socket_Address_IPv6">
-      <tp:docstring>An IPv6 address and port.</tp:docstring>
-      <tp:member type="s" name="Address">
-        <tp:docstring>An IPv6 address literal as specified by RFC2373
-          section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
-      </tp:member>
-      <tp:member type="q" name="Port">
-        <tp:docstring>The TCP or UDP port number.</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:struct name="Socket_Netmask_IPv4">
-      <tp:docstring>An IPv4 network or subnet.</tp:docstring>
-      <tp:member type="s" name="Address">
-        <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
-          numbers, each between 0 and 255 inclusive, e.g.
-          "192.168.0.1".</tp:docstring>
-      </tp:member>
-      <tp:member type="y" name="Prefix_Length">
-        <tp:docstring>The number of leading bits of the address that must
-          match, for this netmask to be considered to match an
-          address.</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:struct name="Socket_Netmask_IPv6">
-      <tp:docstring>An IPv6 network or subnet.</tp:docstring>
-      <tp:member type="s" name="Address">
-        <tp:docstring>An IPv6 address literal as specified by RFC2373
-          section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
-      </tp:member>
-      <tp:member type="y" name="Prefix_Length">
-        <tp:docstring>The number of leading bits of the address that must
-          match, for this netmask to be considered to match an
-          address.</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:enum name="Tube_Type" type="u">
+    <tp:enum name="Tube_Type" type="u" array-name="Tube_Type_List">
       <tp:enumvalue suffix="DBus" value="0">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The tube is D-Bus tube as described by the
@@ -193,7 +143,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     </tp:enum>
 
-    <tp:enum name="Socket_Access_Control" type="u">
+    <tp:enum name="Socket_Access_Control" type="u"
+      array-name="Socket_Access_Control_List">
       <tp:enumvalue suffix="Localhost" value="0">
         <tp:docstring>
           The IP or Unix socket can be accessed by any local user (e.g.
diff --git a/spec/Client.xml b/spec/Client.xml
index d0bb8e5f5..5307efa47 100644
--- a/spec/Client.xml
+++ b/spec/Client.xml
@@ -105,9 +105,9 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of the extra interfaces provided by this client.
           This SHOULD include at least one of
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer</tp:dbus-ref>,
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver</tp:dbus-ref> or
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>.</p>
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.DRAFT</tp:dbus-ref>,
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver.DRAFT</tp:dbus-ref> or
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler.DRAFT</tp:dbus-ref>.</p>
 
         <p>In the <code>.client</code> file, this is represented by key
           "<code>Interfaces</code>" in the group named after this interface.
diff --git a/spec/Client_Approver.xml b/spec/Client_Approver.xml
index 8f59a1939..8725c81e6 100644
--- a/spec/Client_Approver.xml
+++ b/spec/Client_Approver.xml
@@ -107,7 +107,7 @@
       <arg name="DispatchOperation" type="o" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>
             to be processed.</p>
         </tp:docstring>
       </arg>
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index b29ffacdc..3d75f0b8c 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -34,7 +34,7 @@
       <p>When a new incoming channel (one with
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
         = FALSE) is offered to
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver.DRAFT</tp:dbus-ref>s
         by the channel dispatcher, it also offers the Approvers a list of all
         the running or activatable handlers whose
         <tp:member-ref>HandlerChannelFilter</tp:member-ref> property
@@ -140,7 +140,8 @@
         </tp:docstring>
       </arg>
 
-      <arg name="Channels" type="a(oa{sv})" direction="in">
+      <arg name="Channels" type="a(oa{sv})" direction="in"
+        tp:type="Channel_Details[]">
         <tp:docstring>
           The channels and their immutable properties. Their well-known
           bus name is the same as that of the Connection.
@@ -190,7 +191,7 @@
       <arg name="Request" type="o" direction="in">
         <tp:docstring>
           The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+            namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
           object, which MUST have been returned by <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT">CreateChannel</tp:dbus-ref>
           or <tp:dbus-ref
diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml
index 40c71e739..c06f83d72 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -56,7 +56,7 @@
           channels, doing the actual data transfer for file transfers,
           setting up the out-of-band connection for Tubes). The
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+            namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>
           is responsible for such tasks.</p>
 
         <p>Handlers MAY, of course, delegate responsibility for these
diff --git a/spec/Connection.xml b/spec/Connection.xml
index ec0cc2e4b..39fb73834 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -534,27 +534,31 @@ USA.</p>
       </tp:enumvalue>
     </tp:enum>
 
-    <tp:simple-type name="Handle" type="u">
+    <tp:simple-type name="Handle" type="u" array-name="Handle_List">
       <tp:docstring>An unsigned 32-bit integer representing a
         handle</tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="Contact_Handle" type="u">
+    <tp:simple-type name="Contact_Handle" type="u"
+      array-name="Contact_Handle_List">
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_Contact</tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="Room_Handle" type="u">
+    <tp:simple-type name="Room_Handle" type="u"
+      array-name="Room_Handle_List">
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_Room</tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="List_Handle" type="u">
+    <tp:simple-type name="List_Handle" type="u"
+      array-name="List_Handle_List">
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_List</tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="Group_Handle" type="u">
+    <tp:simple-type name="Group_Handle" type="u"
+      array-name="Group_Handle_List">
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_Group</tp:docstring>
     </tp:simple-type>
diff --git a/spec/Connection_Interface_Avatars.xml b/spec/Connection_Interface_Avatars.xml
index acc44de8c..e6f7ac59f 100644
--- a/spec/Connection_Interface_Avatars.xml
+++ b/spec/Connection_Interface_Avatars.xml
@@ -21,7 +21,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Connection.Interface.Avatars">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
 
-    <tp:simple-type name="Avatar_Token" type="s">
+    <tp:simple-type name="Avatar_Token" type="s"
+      array-name="Avatar_Token_List">
       <tp:changed version="0.17.16">strengthened uniqueness requirements
         so (CM name, protocol, token) is unique; previously only
         (our Account, remote contact identifier, token) was required to be
@@ -124,8 +125,131 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
+    <property name="SupportedAvatarMIMETypes"
+      tp:name-for-bindings="Supported_Avatar_MIME_Types"
+      type="as" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        An array of supported MIME types (e.g. "image/jpeg").
+        Clients MAY assume that the first type in this array is preferred.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
+    <property name="MinimumAvatarHeight"
+      tp:name-for-bindings="Minimum_Avatar_Height"
+      type="u" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        The minimum height in pixels of an avatar on this protocol, which MAY
+        be 0.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
+    <property name="MinimumAvatarWidth"
+      tp:name-for-bindings="Minimum_Avatar_Width"
+      type="u" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        The minimum width in pixels of an avatar on this protocol, which MAY
+        be 0.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
+    <property name="RecommendedAvatarHeight"
+      tp:name-for-bindings="Recommended_Avatar_Height"
+      type="u" access="read">
+      <tp:added version="0.17.22"/>
+      <tp:docstring>
+        The recommended height in pixels of an avatar on this protocol, or 0 if
+        there is no preferred height.
+        This property cannot change after the Connection goes to the Connected
+        state.
+
+        <tp:rationale>
+          In XMPP a recommended width is given by the protocol specification;
+          in proprietary protocols, using the same avatar size as the
+          proprietary client is likely to lead to the best display to other
+          users.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="RecommendedAvatarWidth"
+      tp:name-for-bindings="Recommended_Avatar_Width"
+      type="u" access="read">
+      <tp:added version="0.17.22"/>
+      <tp:docstring>
+        The recommended width in pixels of an avatar on this protocol, or 0 if
+        there is no preferred width.
+        This property cannot change after the Connection goes to the Connected
+        state.
+
+        <tp:rationale>
+          The rationale is the same as for
+          <tp:member-ref>RecommendedAvatarHeight</tp:member-ref>.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumAvatarHeight"
+      tp:name-for-bindings="Maximum_Avatar_Height"
+      type="u" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        The maximum height in pixels of an avatar on this protocol, or 0 if
+        there is no limit.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumAvatarWidth"
+      tp:name-for-bindings="Maximum_Avatar_Width"
+      type="u" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        The maximum width in pixels of an avatar on this protocol, or 0 if
+        there is no limit.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumAvatarBytes"
+      tp:name-for-bindings="Maximum_Avatar_Bytes"
+      type="u" access="read">
+      <tp:added version="0.17.22">Fall back to calling
+        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+          property fails.</tp:added>
+      <tp:docstring>
+        The maximum size in bytes of an avatar on this protocol, or 0 if
+        there is no limit.
+        This property cannot change after the Connection goes to the Connected
+        state.
+      </tp:docstring>
+    </property>
+
     <method name="GetAvatarRequirements"
       tp:name-for-bindings="Get_Avatar_Requirements">
+      <tp:deprecated version="0.17.22">Use GetAll to retrieve the
+        D-Bus properties on this interface, falling back to this method
+        on failure.</tp:deprecated>
       <arg direction="out" type="as" name="MIME_Types">
         <tp:docstring>
           An array of supported MIME types (eg image/jpeg)
diff --git a/spec/Connection_Interface_Contact_Info.xml b/spec/Connection_Interface_Contact_Info.xml
index a9d086a94..d08545466 100644
--- a/spec/Connection_Interface_Contact_Info.xml
+++ b/spec/Connection_Interface_Contact_Info.xml
@@ -300,7 +300,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="VCard_Type_Parameter" type="s">
+    <tp:simple-type name="VCard_Type_Parameter" type="s"
+      array-name="VCard_Type_Parameter_List">
       <tp:docstring>
         A type parameter as defined by RFC 2426, such as "type=cell" or
         "language=en".
diff --git a/spec/Connection_Interface_Presence.xml b/spec/Connection_Interface_Presence.xml
index ecf96f868..100ec3617 100644
--- a/spec/Connection_Interface_Presence.xml
+++ b/spec/Connection_Interface_Presence.xml
@@ -281,7 +281,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:possible-errors>
     </method>
 
-    <tp:deprecated version="0.17.UNRELEASED">New client implementations
+    <tp:deprecated version="0.17.21">New client implementations
       SHOULD use <tp:dbus-ref
         namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
       instead. New connection managers SHOULD implement both Presence
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Simple_Presence.xml
index 7acea32cc..84460505f 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Simple_Presence.xml
@@ -349,7 +349,8 @@
       </tp:enumvalue>
     </tp:enum>
 
-    <tp:enum name="Rich_Presence_Access_Control_Type" type="u">
+    <tp:enum name="Rich_Presence_Access_Control_Type" type="u"
+      array-name="Rich_Presence_Access_Control_Type_List">
       <tp:docstring>
         A type of access control for Rich_Presence_Access_Control.
         For most types, the exact access control is given by an associated
diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml
index 46b56ac7a..ad8f058ec 100644
--- a/spec/Connection_Manager.xml
+++ b/spec/Connection_Manager.xml
@@ -55,7 +55,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         characters were not specified</tp:changed>
     </tp:simple-type>
 
-    <tp:simple-type name="Protocol" type="s">
+    <tp:simple-type name="Protocol" type="s" array-name="Protocol_List">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>An instant messaging protocol. It must consist only of ASCII
           letters, digits and hyphen/minus signs (U+002D "-"), and must start
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index cb7c79326..d335e3853 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -70,6 +70,150 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:member>
     </tp:struct>
 
+    <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
+      type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
+      <tp:added version="0.17.22"/>
+      <tp:docstring>
+        The IP addresses of possible STUN servers to use for NAT traversal, as
+        dotted-quad IPv4 address literals or RFC2373 IPv6 address literals.
+        This property cannot change once the stream has been created, so there
+        is no change notification. The IP addresses MUST NOT be given as DNS
+        hostnames.
+
+        <tp:rationale>
+          High-quality connection managers already need an asynchronous
+          DNS resolver, so they might as well resolve this name to an IP
+          to make life easier for streaming implementations.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="CreatedLocally" tp:name-for-bindings="Created_Locally"
+      type="b" access="read">
+      <tp:added version="0.17.22"/>
+      <tp:docstring>
+        True if we were the creator of this stream, false otherwise.
+        <tp:rationale>
+          This information is needed for some nat traversal mechanisms, such
+          as ICE-UDP, where the creator gets the role of the controlling agent.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="NATTraversal" tp:name-for-bindings="NAT_Traversal"
+      type="s" access="read">
+      <tp:added version="0.17.22"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The transport (NAT traversal technique) to be used for this
+          stream. Well-known values include:</p>
+
+        <dl>
+          <dt>none</dt>
+          <dd>Raw UDP, with or without STUN, should be used. If the
+            <tp:member-ref>STUNServers</tp:member-ref> property is non-empty,
+            STUN SHOULD be used.</dd>
+
+          <dt>stun</dt>
+          <dd>A deprecated synonym for 'none'.</dd>
+
+          <dt>gtalk-p2p</dt>
+          <dd>Google Talk peer-to-peer connectivity establishment should be
+            used, as implemented in libjingle 0.3.</dd>
+
+          <dt>ice-udp</dt>
+          <dd>Interactive Connectivity Establishment should be used,
+            as defined by the IETF MMUSIC working group.</dd>
+
+          <dt>wlm-8.5</dt>
+          <dd>The transport used by Windows Live Messenger 8.5 or later,
+            which resembles ICE draft 6, should be used.</dd>
+
+          <dt>wlm-2009</dt>
+          <dd>The transport used by Windows Live Messenger 2009 or later,
+            which resembles ICE draft 19, should be used.</dd>
+        </dl>
+
+        <p>This property cannot change once the stream has been created, so
+          there is no change notification.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="RelayInfo" type="aa{sv}" access="read"
+      tp:type="String_Variant_Map[]" tp:name-for-bindings="Relay_Info">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of mappings describing TURN or Google relay servers
+          available for the client to use in its candidate gathering, as
+          determined from the protocol. Map keys are:</p>
+
+        <dl>
+          <dt><code>ip</code> - s</dt>
+          <dd>The IP address of the relay server as a dotted-quad IPv4
+            address literal or an RFC2373 IPv6 address literal. This MUST NOT
+            be a DNS hostname.
+
+            <tp:rationale>
+              High-quality connection managers already need an asynchronous
+              DNS resolver, so they might as well resolve this name to an IP
+              and make life easier for streaming implementations.
+            </tp:rationale>
+          </dd>
+
+          <dt><code>type</code> - s</dt>
+          <dd>
+            <p>Either <code>udp</code> for UDP (UDP MUST be assumed if this
+              key is omitted), <code>tcp</code> for TCP, or
+              <code>tls</code>.</p>
+
+            <p>The precise meaning of this key depends on the
+              <tp:member-ref>NATTraversal</tp:member-ref> property: if
+              NATTraversal is <code>ice-udp</code>, <code>tls</code> means
+              TLS over TCP as referenced by ICE draft 19, and if
+              NATTraversal is <code>gtalk-p2p</code>, <code>tls</code> means
+              a fake SSL session over TCP as implemented by libjingle.</p>
+          </dd>
+
+          <dt><code>port</code> - q</dt>
+          <dd>The UDP or TCP port of the relay server as an ASCII unsigned
+            integer</dd>
+
+          <dt><code>username</code> - s</dt>
+          <dd>The username to use</dd>
+
+          <dt><code>password</code> - s</dt>
+          <dd>The password to use</dd>
+
+          <dt><code>component</code> - u</dt>
+          <dd>The component number to use this relay server for, as an
+            ASCII unsigned integer; if not included, this relay server
+            may be used for any or all components.
+
+            <tp:rationale>
+              In ICE draft 6, as used by Google Talk, credentials are only
+              valid once, so each component needs relaying separately.
+            </tp:rationale>
+          </dd>
+        </dl>
+
+        <tp:rationale>
+          <p>An equivalent of the gtalk-p2p-relay-token property on
+            MediaSignalling channels is not included here. The connection
+            manager should be responsible for making the necessary HTTP
+            requests to turn the token into a username and password.</p>
+        </tp:rationale>
+
+        <p>The type of relay server that this represents depends on
+          the value of the <tp:member-ref>NATTraversal</tp:member-ref>
+          property. If NATTraversal is ice-udp, this is a TURN server;
+          if NATTraversal is gtalk-p2p, this is a Google relay server;
+          otherwise, the meaning of RelayInfo is undefined.</p>
+
+        <p>If relaying is not possible for this stream, the list is empty.</p>
+
+        <p>This property cannot change once the stream has been created, so
+          there is no change notification.</p>
+      </tp:docstring>
+    </property>
+
     <signal name="AddRemoteCandidate"
       tp:name-for-bindings="Add_Remote_Candidate">
       <arg name="Candidate_ID" type="s">
@@ -246,7 +390,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           String identifier for remote candidate to drop
         </tp:docstring>
       </arg>
-      <tp:deprecated>
+      <tp:deprecated version="0.17.18">
         There is no case where you want to release candidates (except
         for an ICE reset, and there you'd want to replace then all,
         using <tp:member-ref>SetRemoteCandidateList</tp:member-ref>).
diff --git a/spec/Properties_Interface.xml b/spec/Properties_Interface.xml
index 91423c108..aaa46029e 100644
--- a/spec/Properties_Interface.xml
+++ b/spec/Properties_Interface.xml
@@ -39,7 +39,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:member type="u" name="New_Flags"/>
     </tp:struct>
 
-    <tp:simple-type name="Property_ID" type="u">
+    <tp:simple-type name="Property_ID" type="u" array-name="Property_ID_List">
       <tp:docstring>
         An unsigned integer used to represent a Telepathy property.
       </tp:docstring>
diff --git a/spec/all.xml b/spec/all.xml
index 1c377dfb9..952ff6b0c 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -3,7 +3,7 @@
   xmlns:xi="http://www.w3.org/2001/XInclude">
 
 <tp:title>Telepathy D-Bus Interface Specification</tp:title>
-<tp:version>0.17.21</tp:version>
+<tp:version>0.17.22</tp:version>
 
 <tp:copyright>Copyright © 2005-2009 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright>
diff --git a/spec/generic-types.xml b/spec/generic-types.xml
index fba6a9f44..d4dce1552 100644
--- a/spec/generic-types.xml
+++ b/spec/generic-types.xml
@@ -17,23 +17,27 @@
       interfaces.</tp:rationale>
   </tp:simple-type>
 
-  <tp:simple-type name="DBus_Bus_Name" type="s">
+  <tp:simple-type name="DBus_Bus_Name" type="s"
+    array-name="DBus_Bus_Name_List">
     <tp:docstring>A string representing a D-Bus bus name - either a well-known
       name like "org.freedesktop.Telepathy.MissionControl" or a unique name
       like ":1.123"</tp:docstring>
   </tp:simple-type>
 
-  <tp:simple-type name="DBus_Well_Known_Name" type="s">
+  <tp:simple-type name="DBus_Well_Known_Name" type="s"
+    array-name="DBus_Well_Known_Name_List">
     <tp:docstring>A string representing a D-Bus well-known
       name like "org.freedesktop.Telepathy.MissionControl".</tp:docstring>
   </tp:simple-type>
 
-  <tp:simple-type name="DBus_Unique_Name" type="s">
+  <tp:simple-type name="DBus_Unique_Name" type="s"
+    array-name="DBus_Unique_Name_List">
     <tp:docstring>A string representing a D-Bus unique name, such as
       ":1.123"</tp:docstring>
   </tp:simple-type>
 
-  <tp:simple-type name="DBus_Interface" type="s">
+  <tp:simple-type name="DBus_Interface" type="s"
+    array-name="DBus_Interface_List">
     <tp:docstring>An ASCII string representing a D-Bus interface - two or more
       elements separated by dots, where each element is a non-empty
       string of ASCII letters, digits and underscores, not starting with
@@ -60,7 +64,8 @@
       characters. For example, "Ping".</tp:docstring>
   </tp:simple-type>
 
-  <tp:simple-type name="DBus_Qualified_Member" type="s">
+  <tp:simple-type name="DBus_Qualified_Member" type="s"
+    array-name="DBus_Qualified_Member_List">
     <tp:docstring>A string representing the full name of a D-Bus method,
       signal or property, consisting of a DBus_Interface, followed by
       a dot, followed by a DBus_Member. For example,
@@ -90,11 +95,74 @@
     <tp:member type="v" name="Value"/>
   </tp:mapping>
 
-  <tp:mapping name="String_String_Map">
+  <tp:mapping name="String_String_Map" array-name="String_String_Map_List">
     <tp:docstring>A mapping from strings to strings representing extra
       key-value pairs.</tp:docstring>
     <tp:member type="s" name="Key"/>
     <tp:member type="s" name="Value"/>
   </tp:mapping>
 
+  <tp:struct name="Socket_Address_IP" array-name="Socket_Address_IP_List">
+    <tp:docstring>An IP address and port.</tp:docstring>
+    <tp:member type="s" name="Address">
+      <tp:docstring>Either a dotted-quad IPv4 address literal as for
+        <tp:type>Socket_Address_IPv4</tp:type>, or an RFC2373 IPv6 address
+        as for <tp:type>Socket_Address_IPv6</tp:type>.
+      </tp:docstring>
+    </tp:member>
+    <tp:member type="q" name="Port">
+      <tp:docstring>The TCP or UDP port number.</tp:docstring>
+    </tp:member>
+  </tp:struct>
+
+  <tp:struct name="Socket_Address_IPv4">
+    <tp:docstring>An IPv4 address and port.</tp:docstring>
+    <tp:member type="s" name="Address">
+      <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
+        numbers, each between 0 and 255 inclusive, e.g.
+        "192.168.0.1".</tp:docstring>
+    </tp:member>
+    <tp:member type="q" name="Port">
+      <tp:docstring>The TCP or UDP port number.</tp:docstring>
+    </tp:member>
+  </tp:struct>
+
+  <tp:struct name="Socket_Address_IPv6">
+    <tp:docstring>An IPv6 address and port.</tp:docstring>
+    <tp:member type="s" name="Address">
+      <tp:docstring>An IPv6 address literal as specified by RFC2373
+        section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
+    </tp:member>
+    <tp:member type="q" name="Port">
+      <tp:docstring>The TCP or UDP port number.</tp:docstring>
+    </tp:member>
+  </tp:struct>
+
+  <tp:struct name="Socket_Netmask_IPv4">
+    <tp:docstring>An IPv4 network or subnet.</tp:docstring>
+    <tp:member type="s" name="Address">
+      <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
+        numbers, each between 0 and 255 inclusive, e.g.
+        "192.168.0.1".</tp:docstring>
+    </tp:member>
+    <tp:member type="y" name="Prefix_Length">
+      <tp:docstring>The number of leading bits of the address that must
+        match, for this netmask to be considered to match an
+        address.</tp:docstring>
+    </tp:member>
+  </tp:struct>
+
+  <tp:struct name="Socket_Netmask_IPv6">
+    <tp:docstring>An IPv6 network or subnet.</tp:docstring>
+    <tp:member type="s" name="Address">
+      <tp:docstring>An IPv6 address literal as specified by RFC2373
+        section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
+    </tp:member>
+    <tp:member type="y" name="Prefix_Length">
+      <tp:docstring>The number of leading bits of the address that must
+        match, for this netmask to be considered to match an
+        address.</tp:docstring>
+    </tp:member>
+  </tp:struct>
+
 </tp:generic-types>