Update to spec 0.21.1

35 files changed, 3518 insertions, 521 deletions

diff --git a/spec/Account.xml b/spec/Account.xml
index 5917c6f0..acd8c302 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -407,16 +407,23 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>The presence status that this account should have if it is brought
           online.</p>
 
+        <tp:rationale>
+          In ITOS2007 and ITOS2008 this is a global preference, not visible
+          on D-Bus (the "default presence"). "Automatic presence" better
+          describes when it is used.
+        </tp:rationale>
+
         <p>Setting this property MUST NOT actually change the account's
           status until the next time it is (re)connected for some reason.</p>
 
-        <p>The <tp:type>Connection_Presence_Type</tp:type> in the structure
-          SHOULD NOT be Offline or Unset.</p>
+        <p>The value of this property MUST be one that would be acceptable
+          for <tp:member-ref>RequestedPresence</tp:member-ref>,
+          with the additional restriction that the
+          <tp:type>Connection_Presence_Type</tp:type> MUST NOT be Offline.</p>
 
         <tp:rationale>
-          In ITOS2007 and ITOS2008 this is a global preference, not visible
-          on D-Bus (the "default presence"). "Automatic presence" better
-          describes when it is used.
+          <p>Otherwise, it would not be possible to use this presence to bring
+            the account online for a channel request.</p>
         </tp:rationale>
       </tp:docstring>
     </property>
@@ -553,11 +560,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <property name="CurrentPresence" type="(uss)" access="read"
       tp:type="Simple_Presence" tp:name-for-bindings="Current_Presence">
       <tp:docstring>
-        The actual presence. If the connection is not online, this should be
-        (Connection_Presence_Type_Offline, "", "").
+        The actual presence. If the connection is not online, the
+        <tp:type>Connection_Presence_Type</tp:type> SHOULD be
+        Connection_Presence_Type_Offline.
         If the connection is online but does not support the <tp:dbus-ref
         namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
-        interface, this should be (Connection_Presence_Type_Unset, "", "").
+        interface, the type SHOULD be Connection_Presence_Type_Unset.
         The account manager is expected to set this by observing signals
         from the Connection.
 
@@ -585,6 +593,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           This corresponds to e.g. GetPresence and GetPresenceMessage
           in NMC 4.x.
         </tp:rationale>
+
+        <p>The <tp:type>Connection_Presence_Type</tp:type> in this property
+          MUST NOT be Unset, Unknown or Error.</p>
+
+        <tp:rationale>
+          <p>Requesting those presence types doesn't make sense.</p>
+        </tp:rationale>
       </tp:docstring>
     </property>
 
diff --git a/spec/Account_Interface_Minimum_Presence.xml b/spec/Account_Interface_Minimum_Presence.xml
new file mode 100644
index 00000000..eb829b82
--- /dev/null
+++ b/spec/Account_Interface_Minimum_Presence.xml
@@ -0,0 +1,108 @@
+<?xml version="1.0" ?>
+<node name="/Account_Interface_Minimum_Presence"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2010 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+<p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Account.Interface.MinimumPresence.DRAFT2"
+    tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+    <tp:added version="0.19.12">(draft 2)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface extends the core Account interface to provide a way
+        for applications to request minimum presence on the account.</p>
+
+      <tp:rationale>
+        <p>Some applications, for example mail notifiers or address book
+          synchronisation, can make use of account's connection even while
+          the user is nominally offline.</p>
+      </tp:rationale>
+
+      <p>Each client's unique name may set a minimum desired presence on the
+        account. The combined presence is the most available presence
+        of the minimum presences set and of <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Account">RequestedPresence</tp:dbus-ref>
+        set by the user. The account manager should attempt to manipulate
+        the connection to set the combined presence.</p>
+    </tp:docstring>
+
+    <property name="MinimumPresenceRequests"
+      tp:name-for-bindings="MinimumPresenceRequests" access="read"
+      type="a{s(uss)}" tp:type="Minimum_Presence_Request_Map">
+      <tp:docstring>
+        Active requests for minimum presence status, a map of client unique
+        name to the (non-offline) minimum presence they set.
+      </tp:docstring>
+    </property>
+
+    <method name="SetMinimumPresence" tp:name-for-bindings="Set_Minimum_Presence">
+      <tp:docstring>
+        <p>Set a minimum presence needed by the client for this account. Setting
+          (Offline, "offline", "") removes the minimum presence requirement for
+          the client's unique name.</p>
+      </tp:docstring>
+
+      <arg direction="in" name="status" type="(uss)" tp:type="Simple_Presence">
+        <tp:docstring>
+          Requested presence status.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <signal name="MinimumPresenceRequestsChanged"
+      tp:name-for-bindings="Minimum_Presence_Requests_Changed">
+      <tp:docstring>
+        Emitted when the
+        <tp:member-ref>MinimumPresenceRequests</tp:member-ref> property
+        changes.
+      </tp:docstring>
+
+      <arg name="MinimumPresenceRequests" type="a{s(uss)}"
+        tp:type="Minimum_Presence_Request_Map">
+        <tp:docstring>
+          A new value of MinimumPresenceRequests property.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:mapping name="Minimum_Presence_Request_Map">
+      <tp:docstring>
+        <p>A map of active minimum presence requests.</p>
+      </tp:docstring>
+      <tp:member type="s" name="Key" tp:type="DBus_Unique_Name">
+        <tp:docstring>
+          <p>Client unique name.</p>
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="(uss)" name="Value" tp:type="Simple_Presence">
+        <tp:docstring>
+          <p>Requested minimum presence.</p>
+
+          <tp:rationale>
+            <p>Some applications may want to monitor the currently active
+              minimum presences required. An example is an tool allowing
+              the user to inspect applications maintaining open connections and
+              close those applications.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Authentication_TLS_Certificate.xml b/spec/Authentication_TLS_Certificate.xml
index 709ea282..db1d76fd 100644
--- a/spec/Authentication_TLS_Certificate.xml
+++ b/spec/Authentication_TLS_Certificate.xml
@@ -17,9 +17,8 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Authentication.TLSCertificate.DRAFT"
-             tp:causes-havoc="experimental">
-    <tp:added version="0.19.11">(draft 1)</tp:added>
+  <interface name="org.freedesktop.Telepathy.Authentication.TLSCertificate">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
 
     <tp:docstring>
       This object represents a TLS certificate.
@@ -41,10 +40,81 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </tp:simple-type>
 
+    <tp:struct name="TLS_Certificate_Rejection" array-name="TLS_Certificate_Rejection_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Struct representing one reason why a TLS certificate was rejected.</p>
+        <p>Since there can be multiple things wrong with a TLS certificate,
+        arrays of this type are used to represent lists of reasons for
+        rejection. In that case, the most important reason SHOULD be placed
+        first in the list.</p>
+      </tp:docstring>
+
+      <tp:member name="Reason" type="u"
+                 tp:type="TLS_Certificate_Reject_Reason">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The value of the TLS_Certificate_Reject_Reason enumeration for
+          this certificate rejection.
+          <tp:rationale>
+            Clients that do not understand the <code>Error</code> member,
+            which may be implementation-specific, can use this property to
+            classify rejection reasons into common categories.
+          </tp:rationale>
+	  </p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Error" type="s"
+                 tp:type="DBus_Error_Name">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The DBus error name for this certificate rejection.</p>
+          <p>This MAY correspond to the value of the <code>Reason</code> member,
+          or MAY be a more specific D-Bus error name, perhaps implementation-specific.</p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Details" type="a{sv}"
+                 tp:type="String_Variant_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Additional information about why the certificate was rejected.
+          This MAY also include one or more of the following well-known keys:</p>
+          <p>
+          <dl>
+            <dt>user-requested (b)</dt>
+            <dd>True if the error was due to an user-requested rejection of
+            the certificate; False if there was an unrecoverable error in the
+            verification process.</dd>
+            <dt>expected-hostname (s)</dt>
+            <dd>If the rejection reason is Hostname_Mismatch, the hostname that
+            the server certificate was expected to have.</dd>
+            <dt>certificate-hostname (s)</dt>
+            <dd>If the rejection reason is Hostname_Mismatch, the hostname of
+            the certificate that was presented.
+            <tp:rationale>
+              <p>For instance, if you try to connect to gmail.com but are presented
+              with a TLS certificate issued to evil.example.org, the error details
+              for Hostname_Mismatch MAY include:</p>
+              <pre>
+                {
+                  'expected-hostname': 'gmail.com',
+                  'certificate-hostname': 'evil.example.org',
+                }
+              </pre>
+            </tp:rationale>
+            </dd>
+            <dt>debug-message (s)</dt>
+            <dd>Debugging information on the error, corresponding to the
+            message part of a D-Bus error message, which SHOULD NOT be
+            displayed to users under normal circumstances</dd>
+          </dl>
+          </p>
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
     <tp:enum type="u" name="TLS_Certificate_State">
       <tp:docstring>
         The possible states for a <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate.DRAFT</tp:dbus-ref>
+        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
         object.
       </tp:docstring>
 
@@ -149,75 +219,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
-    <property name="RejectError" type="s" access="read"
-              tp:type="DBus_Error_Name"
-              tp:name-for-bindings="Reject_Error">
+    <property name="Rejections" type="a(usa{sv})" access="read"
+              tp:type="TLS_Certificate_Rejection[]" tp:name-for-bindings="Rejections">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If the <tp:member-ref>State</tp:member-ref> is Rejected,
-        the reason why the certificate was rejected; this MAY correspond to
-        the <tp:member-ref>RejectReason</tp:member-ref>, or MAY be a more
-        specific D-Bus error name, perhaps implementation-specific.</p>
+        an array of <tp:type>TLS_Certificate_Rejection</tp:type>
+        structures containing the reason why the certificate is rejected.</p>
         <p>If the <tp:member-ref>State</tp:member-ref> is not Rejected,
         this property is not meaningful, and SHOULD be set to an empty
-        string.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="RejectDetails" type="a{sv}" access="read"
-              tp:type="String_Variant_Map"
-              tp:name-for-bindings="Reject_Details">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If the <tp:member-ref>State</tp:member-ref> is Rejected,
-        additional information about why the certificate was rejected.</p>
-        <p>If the <tp:member-ref>State</tp:member-ref> is not Rejected,
-        this property is not meaningful and SHOULD be set to an empty
-        map.</p>
-        <p>The additional information MAY also include
-        one or more of the following well-known keys:</p>
-        <dl>
-          <dt>user-requested (b)</dt>
-          <dd>True if the error was due to an user-requested rejection of
-          the certificate; False if there was an unrecoverable error in the
-          verification process.</dd>
-          <dt>expected-hostname (s)</dt>
-          <dd>If the rejection reason is Hostname_Mismatch, the hostname that
-          the server certificate was expected to have.</dd>
-          <dt>certificate-hostname (s)</dt>
-          <dd>If the rejection reason is Hostname_Mismatch, the hostname of
-          the certificate that was presented.
-          <tp:rationale>
-            <p>For instance, if you try to connect to gmail.com but are presented
-            with a TLS certificate issued to evil.example.org, the error details
-            for Hostname_Mismatch MAY include:</p>
-            <pre>
-              {
-                'expected-hostname': 'gmail.com',
-                'certificate-hostname': 'evil.example.org',
-              }
-            </pre>
-          </tp:rationale>
-          </dd>
-          <dt>debug-message (s)</dt>
-          <dd>Debugging information on the error, corresponding to the
-          message part of a D-Bus error message, which SHOULD NOT be
-          displayed to users under normal circumstances</dd>
-        </dl>
-      </tp:docstring>
-    </property>
-
-    <property name="RejectReason" type="u" access="read"
-              tp:type="TLS_Certificate_Reject_Reason"
-              tp:name-for-bindings="Reject_Reason">
-      <tp:docstring>
-        If the <tp:member-ref>State</tp:member-ref> is Rejected, the
-        reason why the certificate was rejected.
-        <tp:rationale>
-          Clients that do not understand the <tp:member-ref>RejectError</tp:member-ref>,
-          which may be implementation-specific, can use this property to
-          classify rejection reasons into common categories.
-        </tp:rationale>
-        Otherwise, this property is not meaningful, and SHOULD be set to
-        Unknown.
+        array.</p>
+        <p>The first rejection in the list MAY be assumed to be
+        the most important; if the array contains more than one
+        element, the CM MAY either use the values after the first,
+        or ignore them.</p>
       </tp:docstring>
     </property>
 
@@ -252,19 +266,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:docstring>
         The <tp:member-ref>State</tp:member-ref> of this certificate has changed to Rejected.
       </tp:docstring>
-      <arg name="Reason" type="u" tp:type="TLS_Certificate_Reject_Reason">
+      <arg name="Rejections" type="a(usa{sv})" tp:type="TLS_Certificate_Rejection[]">
         <tp:docstring>
-          The new value of <tp:member-ref>RejectReason</tp:member-ref>.
-        </tp:docstring>
-      </arg>
-      <arg name="Error" type="s" tp:type="DBus_Error_Name">
-        <tp:docstring>
-          The new value of <tp:member-ref>RejectError</tp:member-ref>.
-        </tp:docstring>
-      </arg>
-      <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
-        <tp:docstring>
-          The new value of <tp:member-ref>RejectDetails</tp:member-ref>
+          The new value of the <tp:member-ref>Rejections</tp:member-ref> property.
         </tp:docstring>
       </arg>
     </signal>
@@ -279,24 +283,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:docstring>
         Rejects this certificate.
       </tp:docstring>
-      <arg direction="in" type="u" name="Reason"
-           tp:type="TLS_Certificate_Reject_Reason">
-        <tp:docstring>
-          The new value of <tp:member-ref>RejectReason</tp:member-ref>.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" type="s" name="Error"
-           tp:type="DBus_Error_Name">
-        <tp:docstring>
-          The new value of <tp:member-ref>RejectError</tp:member-ref>.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" type="a{sv}" name="Details"
-           tp:type="String_Variant_Map">
-        <tp:docstring>
-          The new value of <tp:member-ref>RejectDetails</tp:member-ref>.
+      <arg direction="in" type="a(usa{sv})" name="Rejections"
+           tp:type="TLS_Certificate_Rejection[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The new value of the <tp:member-ref>Rejections</tp:member-ref> property.</p>
+          <p>This MUST NOT be an empty array.</p>
         </tp:docstring>
       </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Raised when the method is called on an object whose <tp:member-ref>State</tp:member-ref>
+            is not <code>Pending</code>, or when the provided rejection list is empty.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
     </method>
 
   </interface>
diff --git a/spec/Channel.xml b/spec/Channel.xml
index 897b6835..b1772d7d 100644
--- a/spec/Channel.xml
+++ b/spec/Channel.xml
@@ -101,7 +101,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>TargetHandleType</tp:member-ref>
           MUST be present and not Handle_Type_None, and
           <tp:member-ref>TargetID</tp:member-ref> MUST NOT be
-          present.</p>
+          present. Properties from
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Addressing.DRAFT</tp:dbus-ref>
+          MUST NOT be present.</p>
 
         <p>The channel that satisfies the request MUST either:</p>
 
@@ -147,8 +149,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>TargetHandleType</tp:member-ref>
           MUST be present and not Handle_Type_None, and
           <tp:member-ref>TargetHandle</tp:member-ref> MUST NOT be
-          present. The request MUST fail with error InvalidHandle, without
-          side-effects, if the requested TargetID would not be accepted by
+          present. Properties from
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Addressing.DRAFT</tp:dbus-ref>
+          MUST NOT be present.The request MUST fail with error InvalidHandle,
+          without side-effects, if the requested TargetID would not be
+          accepted by
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">RequestHandles</tp:dbus-ref>.</p>
 
         <p>The returned channel must be related to the handle corresponding
diff --git a/spec/Channel_Dispatcher_Future.xml b/spec/Channel_Dispatcher_Future.xml
new file mode 100644
index 00000000..701b4247
--- /dev/null
+++ b/spec/Channel_Dispatcher_Future.xml
@@ -0,0 +1,377 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Dispatcher_Future"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+
+  <tp:copyright>Copyright © 2008-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+      USA.</p>
+  </tp:license>
+
+  <interface name="org.freedesktop.Telepathy.ChannelDispatcher.FUTURE"
+    tp:causes-havoc="a staging area for future functionality">
+
+    <tp:requires interface="org.freedesktop.Telepathy.ChannelDispatcher"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface contains functionality which we intend to incorporate
+        into the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
+        interface in future. It should be considered to
+        be conceptually part of the core ChannelDispatcher interface, but without
+        API or ABI guarantees.</p>
+    </tp:docstring>
+
+    <method name="CreateChannelWithHints"
+            tp:name-for-bindings="Create_Channel_With_Hints">
+      <tp:added version="0.19.12">
+        Support for this method is indicated by the
+        <tp:member-ref>SupportsRequestHints</tp:member-ref> property.
+        Clients MUST recover from this method being unsupported by falling back
+        to <tp:dbus-ref
+          namespace="ofdT.ChannelDispatcher">CreateChannel</tp:dbus-ref>.
+      </tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start a request to create a channel. This initially just creates a
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          object, which can be used to continue the request and track its
+          success or failure.</p>
+
+        <tp:rationale>
+          <p>The request can take a long time - in the worst case, the
+            channel dispatcher has to ask the account manager to put the
+            account online, the account manager has to ask the operating
+            system to obtain an Internet connection, and the operating
+            system has to ask the user whether to activate an Internet
+            connection using an on-demand mechanism like dialup.</p>
+
+          <p>This means that using a single D-Bus method call and response
+            to represent the whole request will tend to lead to that call
+            timing out, which is not the behaviour we want.</p>
+        </tp:rationale>
+
+        <p>If this method is called for an Account that is disabled, invalid
+          or otherwise unusable, no error is signalled until
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
+          is called, at which point
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
+          is emitted with an appropriate error.</p>
+
+        <tp:rationale>
+          <p>This means there's only one code path for errors, apart from
+            InvalidArgument for "that request makes no sense".</p>
+
+          <p>It also means that the request will proceed if the account is
+            enabled after calling CreateChannel, but before calling
+            Proceed.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Account" type="o">
+        <tp:docstring>
+          The
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          for which the new channel is to be created.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Requested_Properties" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A dictionary containing desirable properties. This has the same
+            semantics as the corresponding parameter to
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>.
+          </p>
+
+          <p>Certain properties will not necessarily make sense in this
+            dictionary: for instance,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+            can only be given if the requester is able to interact with a
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+            to the desired account.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="User_Action_Time" type="x"
+        tp:type="User_Action_Timestamp">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The time at which user action occurred, or 0 if this channel
+            request is for some reason not involving user action.
+            The <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
+            property will be set to this value, and it will eventually be
+            passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Preferred_Handler" type="s"
+        tp:type="DBus_Well_Known_Name">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Either the well-known bus name (starting with
+            <code>org.freedesktop.Telepathy.Client.</code>)
+            of the preferred handler for this
+            channel, or an empty string to indicate that any handler would be
+            acceptable. The channel dispatcher SHOULD dispatch as many as
+            possible of the resulting channels (ideally, all of them)
+            to that handler—irrespective of whether that handler's <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+            matches the channel—and SHOULD remember the preferred handler
+            so it can try to dispatch subsequent channels in the same bundle
+            to the same handler.</p>
+
+          <tp:rationale>
+            <p>This must be the well-known bus name, not the unique name,
+              to ensure that all handlers do indeed have the Client API,
+              and the Client object on the handler can be located easily.</p>
+
+            <p>This is partly so the channel dispatcher can call
+              <tp:dbus-ref
+                namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+              on it, and partly so the channel dispatcher
+              can recover state if it crashes and is restarted.</p>
+
+            <p>The filter should be disregarded for ease of use of this
+              interface: clients will usually use this argument to request
+              channels be sent to themself, and this should trump the filter
+              not matching. This also allows a client to become the handler
+              for a channel produced by one of its own requests, while not
+              being a candidate to handle other channels of that type.</p>
+          </tp:rationale>
+
+          <p>If this is a well-known bus name and the handler has the
+            Requests interface, the channel dispatcher SHOULD
+            call <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref>
+            on that Handler after this method has returned.</p>
+
+          <tp:rationale>
+            <p>This ordering allows a Handler which calls CreateChannel with
+              itself as the preferred handler to associate the call to
+              AddRequest with that call.</p>
+          </tp:rationale>
+
+          <p>This is copied to the ChannelRequest that is returned,
+            as the <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.ChannelRequest">PreferredHandler</tp:dbus-ref>
+            property.</p>
+        </tp:docstring>
+
+        <tp:changed version="0.19.0">
+          Previously, the spec didn't say that this should disregard the
+          handler's filter. This has been implemented since
+          telepathy-mission-control 5.3.2.
+        </tp:changed>
+      </arg>
+
+      <arg direction="in" name="Hints" type="a{sv}">
+        <tp:docstring>
+          <p>Additional information about the channel request, which will be
+            used as the value for the resulting request's <tp:dbus-ref
+              namespace="ofdT.ChannelRequest.FUTURE">Hints</tp:dbus-ref>
+            property, but will not otherwise be interpreted by the Channel
+            Dispatcher.</p>
+
+          <tp:rationale>
+            <p>See the Hints property's documentation for rationale.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Request" type="o">
+        <tp:docstring>
+          A
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          object.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The Preferred_Handler is syntactically invalid or does
+            not start with <code>org.freedesktop.Telepathy.Client.</code>,
+            the Account does not exist, or one of the Requested_Properties
+            is invalid
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+
+    </method>
+
+    <method name="EnsureChannelWithHints"
+            tp:name-for-bindings="Ensure_Channel_With_Hints">
+      <tp:added version="0.19.12">
+        Support for this method is indicated by the
+        <tp:member-ref>SupportsRequestHints</tp:member-ref> property.
+        Clients MUST recover from this method being unsupported by falling back
+        to <tp:dbus-ref
+          namespace="ofdT.ChannelDispatcher">EnsureChannel</tp:dbus-ref>.
+      </tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start a request to ensure that a channel exists, creating it if
+          necessary.  This initially just creates a <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          object, which can be used to continue the request and track its
+          success or failure.</p>
+
+        <p>If this method is called for an Account that is disabled, invalid
+          or otherwise unusable, no error is signalled until
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
+          is called, at which point
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
+          is emitted with an appropriate error.</p>
+
+        <tp:rationale>
+          <p>The rationale is as for <tp:dbus-ref
+              namespace='org.freedesktop.Telepathy.ChannelDispatcher'>CreateChannel</tp:dbus-ref>.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Account" type="o">
+        <tp:docstring>
+          The
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          for which the new channel is to be created.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Requested_Properties" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A dictionary containing desirable properties. This has the same
+            semantics as the corresponding parameter to
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>.
+          </p>
+
+          <p>Certain properties will not necessarily make sense in this
+            dictionary: for instance,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+            can only be given if the requester is able to interact with a
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+            to the desired account.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="User_Action_Time" type="x"
+        tp:type="User_Action_Timestamp">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The time at which user action occurred, or 0 if this channel
+            request is for some reason not involving user action.</p>
+
+          <p>This parameter is used in the same way as the corresponding
+            parameter to
+            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Preferred_Handler" type="s"
+        tp:type="DBus_Well_Known_Name">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Either the well-known bus name (starting with
+            <code>org.freedesktop.Telepathy.Client.</code>)
+            of the preferred handler for this
+            channel, or an empty string to indicate that any handler would be
+            acceptable. The behaviour and rationale are the same as for the
+            corresponding parameter to
+            <tp:member-ref>CreateChannelWithHints</tp:member-ref>, except
+            as noted here.</p>
+
+          <p>If any new channels are created in response to this
+            request, the channel dispatcher SHOULD dispatch as many as
+            possible of the resulting channels (ideally, all of them)
+            to that handler, and SHOULD remember the preferred handler
+            so it can try to dispatch subsequent channels in the same bundle
+            to the same handler. If the requested channel already exists (that
+            is, <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>
+            returns <code>Yours=False</code>) then the channel dispatcher
+            SHOULD re-dispatch the channel to its existing handler, and MUST
+            NOT dispatch it to this client (unless it is the existing handler);
+            the request is still deemed to have succeeded in this case.</p>
+
+          <tp:rationale>
+            <p>An address book application, for example, might call <tp:dbus-ref
+                namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
+              to ensure that a text channel with a particular contact is
+              displayed to the user; it does not care whether a new channel was
+              made. An IM client might call <tp:dbus-ref
+                namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
+              in response to the user double-clicking an entry in the contact
+              list, with itself as the <code>Preferred_Handler</code>; if the
+              user already has a conversation with that contact in another
+              application, they would expect the existing window to be
+              presented, rather than their double-click leading to an error
+              message.  So the request should succeed, even if its
+              <code>Preferred_Handler</code> is not used.</p>
+          </tp:rationale>
+
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Hints" type="a{sv}">
+        <tp:docstring>
+          Additional information about the channel request, which will be used
+          as the value for the resulting request's <tp:dbus-ref
+          namespace="ofdT.ChannelRequest.FUTURE">Hints</tp:dbus-ref>
+          property.</tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Request" type="o">
+        <tp:docstring>
+          A
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          object.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The Preferred_Handler is syntactically invalid or does
+            not start with <code>org.freedesktop.Telepathy.Client.</code>,
+            the Account does not exist, or one of the Requested_Properties
+            is invalid
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+
+    </method>
+
+    <property name="SupportsRequestHints"
+              tp:name-for-bindings="Supports_Request_Hints"
+              type="b" access="read">
+      <tp:added version="0.19.12"/>
+      <tp:docstring>
+        If <code>True</code>, the channel dispatcher is new enough to support
+        <tp:member-ref>CreateChannelWithHints</tp:member-ref> and
+        <tp:member-ref>EnsureChannelWithHints</tp:member-ref>, in addition
+        to the older <tp:dbus-ref
+          namespace="ofdT.ChannelDispatcher">CreateChannel</tp:dbus-ref>
+        and <tp:dbus-ref
+          namespace="ofdT.ChannelDispatcher">EnsureChannel</tp:dbus-ref>.
+        methods. If <code>False</code> or missing, only the metadata-less
+        variants are supported.
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Addressing.xml b/spec/Channel_Interface_Addressing.xml
new file mode 100644
index 00000000..494fd7bf
--- /dev/null
+++ b/spec/Channel_Interface_Addressing.xml
@@ -0,0 +1,107 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Addressing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Limited</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Channel.Interface.Addressing.DRAFT"
+             tp:causes-havoc="experimental">
+    <tp:added version="0.19.12">(as draft)</tp:added>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface provides properties that can be used for
+        requesting channels through different contact addressing
+        schemes like vCard addresses or URIs.
+      </p>
+    </tp:docstring>
+
+    <property name="TargetVCardField" type="s" access="read"
+              tp:name-for-bindings="Target_VCard_Field">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The vCard field, normalized to lower case,
+          <tp:member-ref>TargetVCardAddress</tp:member-ref> refers to.</p>
+
+          <p>The <code>url</code> vCard field MUST NOT appear here; see
+            <tp:member-ref>TargetURI</tp:member-ref> instead.</p>
+
+          <tp:rationale>
+            <p>In practice, protocols have a limited set of URI
+              schemes that make sense to resolve as a contact.</p>
+          </tp:rationale>
+
+        <p>If this is omitted from a request,
+          <tp:member-ref>TargetVCardAddress</tp:member-ref> MUST be
+          omitted as well.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="TargetURIScheme" type="s" access="read"
+              tp:name-for-bindings="Target_URI_Scheme">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The URI scheme used in <tp:member-ref>TargetURI</tp:member-ref></p>
+
+        <tp:rationale>
+          <p>While this seems redundant, since the scheme is included in
+            <tp:member-ref>TargetURI</tp:member-ref>, it exists for constructing
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+            that support a limited set of URI schemes.</p>
+        </tp:rationale>
+
+        <p>If this is omitted from a request,
+          <tp:member-ref>TargetURI</tp:member-ref> MUST be
+          omitted as well.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="TargetVCardAddress" type="s" access="read"
+              tp:name-for-bindings="Target_VCard_Address">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The vCard address of the Channel's target.</p>
+
+        <p>If this is present in a channel request,
+          <tp:member-ref>TargetVCardField</tp:member-ref>
+          MUST be present, and
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>,
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>,
+          and <tp:member-ref>TargetURI</tp:member-ref> MUST NOT be present.
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          must either not be present or set to Handle_Type_Contact.
+          The request MUST fail with error InvalidHandle, without
+          side-effects, if the requested vCard address cannot be found.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="TargetURI" type="s" access="read"
+              tp:name-for-bindings="Target_URI">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The URI of the Channel's target. The URI's scheme (i.e. the
+          part before the first colon) MUST be identical to
+          <tp:member-ref>TargetURIScheme</tp:member-ref>.</p>
+
+        <p>If this is present in a channel request,
+          <tp:member-ref>TargetVCardField</tp:member-ref>
+          MUST be present, and
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>,
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>,
+          and <tp:member-ref>TargetVCardAddress</tp:member-ref> MUST NOT be
+          present.
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          must either not be present or set to Handle_Type_Contact.
+          The request MUST fail with error InvalidHandle, without
+          side-effects, if the requested vCard address cannot be found.</p>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Conference.xml b/spec/Channel_Interface_Conference.xml
index 92d962d6..afb99c5c 100644
--- a/spec/Channel_Interface_Conference.xml
+++ b/spec/Channel_Interface_Conference.xml
@@ -20,16 +20,18 @@
       02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.0">(draft 1)</tp:added>
+    name="org.freedesktop.Telepathy.Channel.Interface.Conference">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:requires
       interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can "continue
-        from" one or more individual channels.</p>
+        from" one or more individual channels. This could be used to invite
+        other contacts to an existing 1-1 text conversation, combine two phone
+        calls into one conference call, and so on, with roughly the same API in
+        each case.</p>
 
       <tp:rationale>
         <p>This interface addresses freedesktop.org <a
@@ -37,71 +39,45 @@
             #24906</a> (GSM-compatible conference calls) and <a
             href="http://bugs.freedesktop.org/show_bug.cgi?id=24939">bug
             #24939</a> (upgrading calls and chats to multi-user).
-          See those bugs for rationale and use cases.</p>
-
-        <p>Examples of usage:</p>
-
-        <p>Active and held GSM calls C1, C2 can be merged into a single
-          channel Cn with the Conference interface, by calling
-          <code>CreateChannel({...ChannelType: ...Call,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]})</code>
-          which returns Cn.</p>
-
-        <p>An XMPP 1-1 conversation C1 can be continued in a newly created
-          multi-user chatroom Cn by calling
-          <code>CreateChannel({...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns Cn.</p>
-
-        <p>An XMPP 1-1 conversation C1 can be continued in a specified
-          multi-user chatroom by calling
-          <code>CreateChannel({...ChannelType: ...Text, ...HandleType: ROOM,
-            ...TargetID: 'telepathy@conf.example.com',
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns a Conference channel.</p>
-
-        <p>Either of the XMPP cases could work for Call channels, to
-          upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
-          could in principle work for link-local XMPP (XEP-0174).</p>
-
-        <p>The underlying switchboard representing an MSN 1-1 conversation C1
-          with a contact X can be moved to a representation as a nameless
-          chatroom, Cn, to which more contacts can be invited, by calling
-          <code>CreateChannel({...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns Cn. C1 SHOULD remain open, with no underlying
-          switchboard attached. If X establishes a new switchboard with the
-          local user, C1 SHOULD pick up that switchboard rather than letting
-          it create a new channel.
-          <strong>[FIXME: should it?]</strong>
-          Similarly, if the local user sends a message in C1, then
-          a new switchboard to X should be created and associated with C1.</p>
-
-        <p>XMPP and MSN do not natively have a concept of merging two or more
-          channels C1, C2... into one channel, Cn. However, the GSM-style
-          merging API can be supported on XMPP and MSN, as an API short-cut
-          for upgrading C1 into a conference Cn (which invites the
-          TargetHandle of C1 into Cn), then immediately inviting the
-          TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
-
-        <p>With a suitable change of terminology, Skype has behaviour similar
-          to MSN.</p>
+          See those bugs for more rationale and use cases.</p>
       </tp:rationale>
 
+      <p>Existing channels are upgraded by requesting a new channel of the same
+        <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>,
+        listing the channels to be merged into the new conference in the
+        <tp:member-ref>InitialChannels</tp:member-ref> property of the request.
+        If <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
+        <var>Allowed_Properties</var> in <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>,
+        ad-hoc conferences to a set of contacts may be created by requesting a
+        channel, specifying
+        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and/or
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> to be the contacts in
+        question. A request may specify these alongside
+        <tp:member-ref>InitialChannels</tp:member-ref>, to simultaneously
+        upgrade a channel to a conference and invite others to join it.</p>
+
+      <p>Channels with this interface MAY also implement <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>MergeableConference.DRAFT</tp:dbus-ref>
+        to support merging more 1-1 channels into an ongoing conference.
+        Similarly, 1-1 channels MAY implement <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>Splittable.DRAFT</tp:dbus-ref> to
+        support being broken out of a Conference channel.</p>
+
       <p>The <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Group</tp:dbus-ref> MAY have channel-specific handles for participants;
-        clients SHOULD support both Conferences that have channel-specific handles,
-        and those that do not.</p>
+          >Group</tp:dbus-ref> interface on Conference channels MAY use
+          channel-specific handles for participants; clients SHOULD support
+          both Conferences that have channel-specific handles, and those that
+          do not.</p>
 
       <tp:rationale>
         <p>In the GSM case, the Conference's Group interface MAY have
-          channel-specific handles, to reflect the fact that the identities of
-          the participants might not be known - it can be possible to know that
-          there is another participant in the Conference, but not know who
-          they are.
-          <strong>[FIXME: fact check from GSM gurus needed]</strong>
-        </p>
+          channel-specific handles, to represent the fact that the same
+          phone number may be in a conference twice (for instance, it could be
+          the number of a corporate switchboard).</p>
 
         <p>In the XMPP case, the Conference's Group interface SHOULD have
           channel-specific handles, to reflect the fact that the participants
@@ -132,6 +108,164 @@
           be misleading.</p>
       </tp:rationale>
 
+      <h4>Examples of usage</h4>
+
+      <p>A pair of 1-1 GSM calls <var>C1</var> and <var>C2</var> can be merged
+        into a single conference call by calling:</p>
+
+      <blockquote>
+        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...Call,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]
+          })</code>
+      </blockquote>
+
+      <p>which returns a new channel <var>Cn</var> implementing the conference
+        interface. (As a quirk of GSM, both 1-1 will cease to function normally
+        until they are <tp:dbus-ref
+          namespace="ofdT.Channel.Interface.Splittable.DRAFT">Split</tp:dbus-ref>
+        from the conference, or the conference ends.)</p>
+
+      <p>An XMPP 1-1 conversation <var>C3</var> (with
+        <tt>chris@example.com</tt>, say) can be continued in a newly created
+        multi-user chatroom by calling:</p>
+
+      <blockquote>
+        <code>CreateChannel({
+            ...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
+          })</code>
+      </blockquote>
+
+      <p>Or, to invite <tt>emily@example.net</tt> to join the newly-created MUC
+        at the same time:</p>
+
+      <blockquote>
+        <code>CreateChannel({
+            ...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3],
+            ...<tp:member-ref>InitialInviteeIDs</tp:member-ref>: ['emily@example.net']
+          })</code>
+      </blockquote>
+
+      <p>To continue <var>C3</var> in a particular multi-user
+        chatroom (rather than the implementation inventing a unique name for
+        the room), call:</p>
+
+      <blockquote>
+        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>({
+            ...ChannelType: ...Text,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: ...Room,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: 'telepathy@conf.example.com',
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
+          })</code>
+      </blockquote>
+
+      <p>Note the use of EnsureChannel — if a channel for
+        <tt>telepathy@conf.example.com</tt> is already open, this SHOULD be
+        equivalent to inviting <tt>chris@example.com</tt> to the existing
+        channel.</p>
+
+      <p>In the above cases, the text channel <var>C3</var> SHOULD remain open
+        and fully functional (until explicitly closed by a client); new
+        incoming 1-1 messages from <tt>chris@example.com</tt> SHOULD appear in
+        <var>C3</var>, and messages sent using <var>C3</var> MUST be relayed
+        only to <tt>chris@example.com</tt>.</p>
+
+      <tp:rationale>
+        <p>If there is an open 1-1 text channel with a contact, in every
+          other situation new messages will appear in that channel. Given
+          that the old channel remains open — which is the least surprising
+          behaviour, and eases us towards a beautiful world where channels
+          never close themselves — it stands to reason that it should be
+          where new messages from Chris should appear. On MSN, creating a
+          conference from <var>C3</var> should migrate the underlying
+          switchboard from <var>C3</var> to the new channel; this is an
+          implementation detail, and should not affect the representation on
+          D-Bus. With a suitable change of terminology, Skype has the same
+          behaviour.</p>
+
+        <p>If the current handler of that channel doesn't want this to happen
+          (maybe it transformed the existing tab into the group chat window,
+          and so there'd be no UI element still around to show new messages),
+          then it should just <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> the
+          old 1-1 channel; it'll respawn if necessary.</p>
+      </tp:rationale>
+
+      <p>Either of the XMPP cases could work for Call channels, to
+        upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
+        could in principle work for link-local XMPP (XEP-0174).</p>
+
+      <p>XMPP and MSN do not natively have a concept of merging two or more
+        channels C1, C2... into one channel, Cn. However, the GSM-style
+        merging API can be supported on XMPP and MSN, as an API short-cut
+        for upgrading C1 into a conference Cn (which invites the
+        TargetHandle of C1 into Cn), then immediately inviting the
+        TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
+
+      <h4>Sample <tp:dbus-ref namespace='ofdT.Connection.Interface.Requests'
+                             >RequestableChannelClasses</tp:dbus-ref></h4>
+
+      <p>A GSM connection might advertise the following channel class for
+        conference calls:</p>
+
+      <blockquote>
+        <code>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref><br/>
+  },<br/>
+  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:dbus-ref namespace='ofdT.Channel.Type.StreamedMedia'
+                          >InitialAudio</tp:dbus-ref>
+            ]<br/>
+)
+        </code>
+      </blockquote>
+
+      <p>This indicates support for starting audio-only conference calls by
+        merging two or more existing channels (since
+        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are not allowed).</p>
+
+      <p>An XMPP connection might advertise the following classes for ad-hoc
+        multi-user text chats:</p>
+
+      <blockquote>
+        <code>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref><br/>
+  },<br/>
+  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
+              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
+              <tp:member-ref>InvitationMessage</tp:member-ref>
+            ]<br/>
+),<br/>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+      Room<br/>
+  },<br/>
+  Allowed = [ <tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
+              <tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref>,<br/>
+              <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
+              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
+              <tp:member-ref>InvitationMessage</tp:member-ref>
+            ]<br/>
+)
+        </code>
+      </blockquote>
+
+      <p>The first class indicates support for starting ad-hoc (nameless) chat
+        rooms, upgraded from existing 1-1 channels and/or inviting new
+        contacts, along with a message to be sent along with the invitations.
+        The second indicates support for upgrading to a particular named chat
+        room.</p>
     </tp:docstring>
 
     <property name="Channels" tp:name-for-bindings="Channels"
@@ -145,10 +279,18 @@
               namespace="org.freedesktop.Telepathy.Channel"
               >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
 
-        <p>This property MUST NOT be requestable.
-          <strong>[FIXME: or would it be better for this one, and not IC, to be
-            requestable?]</strong>
-        </p>
+        <p>This property MUST NOT be requestable; instead, the
+          <tp:member-ref>InitialChannels</tp:member-ref> property may be
+          specified when requesting a channel.</p>
+
+        <tp:rationale>
+          <p>This is consistent with requesting
+            <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+            <tp:member-ref>InitialInviteeIDs</tp:member-ref>, rather than
+            requesting <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.Members</tp:dbus-ref>
+            and some hypothetical ID version of that property.</p>
+       </tp:rationale>
 
         <p>Change notification is via the
           <tp:member-ref>ChannelMerged</tp:member-ref> and
@@ -166,6 +308,22 @@
         <tp:docstring>The channel that was added to
           <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
       </arg>
+
+      <arg name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
+        <tp:docstring>A new channel-specific handle for the <tp:dbus-ref
+          namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> of
+          <var>Channel</var>, as will appear in
+          <tp:member-ref>OriginalChannels</tp:member-ref>, or <tt>0</tt> if a
+          global handle is used for
+          <var>Channel</var>'s TargetHandle on the <tp:dbus-ref
+            namespace="ofdT.Channel.Interface">Group</tp:dbus-ref> interface
+          of this channel.</tp:docstring>
+      </arg>
+
+      <arg name="Properties" type="a{sv}"
+           tp:type="Qualified_Property_Value_Map">
+        <tp:docstring><var>Channel</var>'s immutable properties.</tp:docstring>
+      </arg>
     </signal>
 
     <signal name="ChannelRemoved" tp:name-for-bindings="Channel_Removed">
@@ -176,14 +334,24 @@
             namespace="org.freedesktop.Telepathy.Channel.Interface"
             >Splittable.DRAFT.Split</tp:dbus-ref> method.</p>
 
-        <p><strong>[FIXME: relative ordering of this vs. Closed? Do we
-            care?]</strong></p>
+        <p>If a channel is removed because it was closed, <tp:dbus-ref
+          namespace='ofdT.Channel'>Closed</tp:dbus-ref> should be emitted
+          before this signal.</p>
       </tp:docstring>
 
       <arg name="Channel" type="o">
         <tp:docstring>The channel that was removed from
           <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
       </arg>
+
+      <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Additional information about the removal, which may include
+          the same well-known keys as the Details argument of
+          <tp:dbus-ref namespace="ofdT.Channel.Interface.Group"
+            >MembersChangedDetailed</tp:dbus-ref>, with the same semantics.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <property name="InitialChannels" tp:name-for-bindings="Initial_Channels"
@@ -193,18 +361,23 @@
 
         <p>This property SHOULD be requestable. Omitting it from a request is
           equivalent to providing it with an empty list as value. Requests
-          where its value has at least two elements SHOULD be expected to
-          succeed on any implementation of this interface.</p>
-
-        <p>Whether a request with 0 or 1 elements in the list will succeed is
-          indicated by <tp:member-ref>SupportsNonMerges</tp:member-ref>.</p>
+          where its value has at least two channel paths SHOULD be expected to
+          succeed on any implementation of this interface. If
+          <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+          <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
+          <var>Allowed_Properties</var> in <tp:dbus-ref
+            namespace='ofdT.Connection.Interface.Requests'
+            >RequestableChannelClasses</tp:dbus-ref>, then requests with zero
+          or one channel paths SHOULD also succeed; otherwise, clients SHOULD
+          NOT make requests with zero or one paths for this property.</p>
 
         <tp:rationale>
-          <p>In GSM, a pair of calls can be merged into a conference. In XMPP
-            and MSN, you can create a new chatroom, or upgrade one 1-1 channel
-            into a chatroom; however, on these protocols, it is also possible
-            to fake GSM-style merging by upgrading the first channel, then
-            inviting the targets of all the other channels into it.</p>
+          <p>In GSM, a pair of calls can be merged into a conference, but you
+            can't start a conference call from zero or one existing calls. In
+            XMPP and MSN, you can create a new chatroom, or upgrade one 1-1
+            channel into a chatroom; however, on these protocols, it is also
+            possible to fake GSM-style merging by upgrading the first channel,
+            then inviting the targets of all the other channels into it.</p>
         </tp:rationale>
 
         <p>If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD
@@ -213,9 +386,7 @@
           them in this property's value or by calling
           <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.
-          <strong>[FIXME: there's nothing in RequestableChannelClasses yet
-            to say what will happen, see #24906 comment 6]</strong></p>
+            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.</p>
 
         <tp:rationale>
           <p>In Jingle, nothing special will happen to merged calls. UIs MAY
@@ -223,10 +394,6 @@
             the desired behaviour; this SHOULD always work. Not doing
             an implicit hold/unhold seems to preserve least-astonishment.</p>
 
-          <p><strong>[FIXME: check whether ring supports faking Hold on both
-              channels, as it probably should: see #24906 comment 6]</strong>
-          </p>
-
           <p>In GSM, the calls that are merged go into a state similar to
             Hold, but they cannot be unheld, only split from the conference
             call using <tp:dbus-ref namespace="org.freedesktop.Telepathy"
@@ -258,13 +425,21 @@
         <p>A list of additional contacts invited to this conference when it
           was created.</p>
 
-        <p>This property SHOULD be requestable, and appear in the allowed
+        <p>If it is possible to invite new contacts when creating a conference
+          (as opposed to merging several channels into one new conference
+          channel), this property SHOULD be requestable, and appear in the allowed
           properties in <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-            >RequestableChannelClasses</tp:dbus-ref>, in all connection
-          managers that can implement its semantics (in practice, this is
-          likely to mean exactly those connection managers where
-          <tp:member-ref>SupportsNonMerges</tp:member-ref> will be true).</p>
+            >RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property
+          SHOULD NOT be requestable, and its value SHOULD always be the empty
+          list.</p>
+
+        <tp:rationale>
+          <p>On GSM you have to place a 1-1 call before you can merge it into a
+            conference; on the other hand, you can invite new contacts to XMPP
+            Muji calls and XMPP/MSN/Skype ad-hoc chat rooms without starting a
+            1-1 channel with them first.</p>
+        </tp:rationale>
 
         <p>If included in a request, the given contacts are automatically
           invited into the new channel, as if they had been added with
@@ -326,8 +501,8 @@
         <p>A list of additional contacts invited to this conference when it
           was created.</p>
 
-        <p>This property SHOULD be requestable as an alternative to, or
-          combined with, <tp:member-ref>InitialInviteeHandles</tp:member-ref>.
+        <p>This property SHOULD be requestable if and only if
+          <tp:member-ref>InitialInviteeHandles</tp:member-ref> is requestable.
           Its semantics are the same, except that it takes a list of the
           string representations of contact handles; invitations are sent to
           any contact present in either or both of these properties.</p>
@@ -369,60 +544,92 @@
       </tp:docstring>
     </property>
 
-    <property name="SupportsNonMerges"
-      tp:name-for-bindings="Supports_Non_Merges"
-      access="read" type="b">
+    <property name="OriginalChannels" tp:name-for-bindings="Original_Channels"
+              type="a{uo}" tp:type="Channel_Originator_Map"
+              access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p><strong>[FIXME: needs a better name; or perhaps it could be implied
-            by InitialInviteeHandles being requestable in XMPP/MSN but not in
-            GSM?]</strong></p>
-
-        <p>If true, requests with <tp:member-ref>InitialChannels</tp:member-ref>
-          omitted, empty, or one element long should be expected to succeed.</p>
-
-        <p>This property SHOULD appear in <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-              >RequestableChannelClasses</tp:dbus-ref> for
-          conference channels if and only if its value on those channels will
-          be true.</p>
-
-        <tp:rationale>
-          <p>Putting this in <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-              >RequestableChannelClasses</tp:dbus-ref> means clients can find
-            out whether their request will succeed early enough to do
-            something about it.</p>
-
-          <p>In XMPP, you can request a channel of type ROOM without
-            incorporating any 1-1 chats at all - indeed, this is the normal
-            way to do it - or as a continuation of a single 1-1 chat, and then
-            invite other people in later.</p>
-
-          <p>The sense of this property is a bit awkward, but it avoids making it
-            an anti-capability. If the sense were inverted, then its presence in
-            RequestableChannelClasses would imply that the protocol <em>lacks</em>
-            a feature; as it stands, it is additive. (Contrast with
-            <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"
-              >ImmutableStreams</tp:dbus-ref>, which is the wrong way around for
-            backwards-compatibility reasons.)</p>
-        </tp:rationale>
+        <p>On GSM conference calls, it is possible to have the same phone
+          number in a conference twice; for instance, it could be the number of
+          a corporate switchboard. This is represented using channel-specific
+          handles; whether or not a channel uses channel-specific handles is
+          reported in <tp:dbus-ref
+          namespace='ofdT.Channel.Interface'>Group.GroupFlags</tp:dbus-ref>.
+          The <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref>
+          property specifies the mapping from opaque channel-specific handles
+          to actual numbers; this property specifies the original 1-1 channel
+          corresponding to each channel-specific handle in the conference.</p>
+
+        <p>In protocols where this situation cannot arise, such as XMPP,
+          this property MAY remain empty.</p>
+
+        <p>For example, consider this situation:</p>
+
+        <ol>
+          <li>Place a call (with path <tt>/call/to/simon</tt>) to the contact
+            <tt>+441234567890</tt> (which is assigned the handle <var>h</var>,
+            say), and ask to be put through to Simon McVittie;</li>
+          <li>Put that call on hold;</li>
+          <li>Place another call (with path <tt>/call/to/jonny</tt>) to
+            <tt>+441234567890</tt>, and ask to be put
+            through to Jonny Lamb;</li>
+          <li>Request a new channel with
+            <tp:member-ref>InitialChannels</tp:member-ref>:
+            <tt>['/call/to/simon', '/call/to/jonny']</tt>.</li>
+        </ol>
+
+        <p>The new channel will have the following properties, for some handles
+          <var>s</var> and <var>j</var>:</p>
+
+        <blockquote>
+          <code>{<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>:
+                Channel_Specific_Handles | (other flags),<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>:
+                [self_handle, s, j],<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>:
+                { s: h, j: h },<br/>
+            ...<tp:member-ref>InitialChannels</tp:member-ref>:
+                ['/call/to/simon', '/call/to/jonny'],<br/>
+            ...<tp:member-ref>Channels</tp:member-ref>:
+                ['/call/to/simon', '/call/to/jonny'],<br/>
+            ...<tp:member-ref>OriginalChannels</tp:member-ref>:
+                { s: '/call/to/simon', j: '/call/to/jonny' },<br/>
+            # ...standard properties like ChannelType: Group elided...<br/>
+          }</code>
+        </blockquote>
 
-        <p>If false, <tp:member-ref>InitialChannels</tp:member-ref> SHOULD be
-          supplied in all requests for this channel class, and contain at least
-          two channels. Requests where this requirement is not met SHOULD fail
-          with NotImplemented.
-        </p>
-
-        <tp:rationale>
-          <p>In GSM, you can only make a conference call by merging at least
-            two channels.
-            <strong>[FIXME: the CM could conceivably fake it, but that would be
-              rather nasty]</strong>
-          </p>
-        </tp:rationale>
+        <p>Change notification is via the
+          <tp:member-ref>ChannelMerged</tp:member-ref> and
+          <tp:member-ref>ChannelRemoved</tp:member-ref> signals: if
+          <var>Channel_Specific_Handle</var> in the former is non-zero, this
+          property SHOULD be updated to map that handle to the merged channel's
+          path.</p>
       </tp:docstring>
     </property>
 
+    <tp:mapping name="Channel_Originator_Map">
+      <tp:member name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          A channel-specific handle for a participant in this conference.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Original_Channel" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The object path of <tp:member-ref>Channels</tp:member-ref>
+          representing the original 1-1 channel with
+          <var>Channel_Specific_Handle</var>.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        A mapping from members of a conference to the original 1-1 channel with
+        that contact, if any. See
+        <tp:member-ref>OriginalChannels</tp:member-ref> for details.
+      </tp:docstring>
+    </tp:mapping>
   </interface>
 </node>
diff --git a/spec/Channel_Interface_Conference_DRAFT.xml b/spec/Channel_Interface_Conference_DRAFT.xml
new file mode 100644
index 00000000..92d962d6
--- /dev/null
+++ b/spec/Channel_Interface_Conference_DRAFT.xml
@@ -0,0 +1,428 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Conference"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2009 Collabora Limited</tp:copyright>
+  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+      02110-1301, USA.</p>
+  </tp:license>
+  <interface
+    name="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires
+      interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface for multi-user conference channels that can "continue
+        from" one or more individual channels.</p>
+
+      <tp:rationale>
+        <p>This interface addresses freedesktop.org <a
+            href="http://bugs.freedesktop.org/show_bug.cgi?id=24906">bug
+            #24906</a> (GSM-compatible conference calls) and <a
+            href="http://bugs.freedesktop.org/show_bug.cgi?id=24939">bug
+            #24939</a> (upgrading calls and chats to multi-user).
+          See those bugs for rationale and use cases.</p>
+
+        <p>Examples of usage:</p>
+
+        <p>Active and held GSM calls C1, C2 can be merged into a single
+          channel Cn with the Conference interface, by calling
+          <code>CreateChannel({...ChannelType: ...Call,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]})</code>
+          which returns Cn.</p>
+
+        <p>An XMPP 1-1 conversation C1 can be continued in a newly created
+          multi-user chatroom Cn by calling
+          <code>CreateChannel({...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
+          which returns Cn.</p>
+
+        <p>An XMPP 1-1 conversation C1 can be continued in a specified
+          multi-user chatroom by calling
+          <code>CreateChannel({...ChannelType: ...Text, ...HandleType: ROOM,
+            ...TargetID: 'telepathy@conf.example.com',
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
+          which returns a Conference channel.</p>
+
+        <p>Either of the XMPP cases could work for Call channels, to
+          upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
+          could in principle work for link-local XMPP (XEP-0174).</p>
+
+        <p>The underlying switchboard representing an MSN 1-1 conversation C1
+          with a contact X can be moved to a representation as a nameless
+          chatroom, Cn, to which more contacts can be invited, by calling
+          <code>CreateChannel({...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
+          which returns Cn. C1 SHOULD remain open, with no underlying
+          switchboard attached. If X establishes a new switchboard with the
+          local user, C1 SHOULD pick up that switchboard rather than letting
+          it create a new channel.
+          <strong>[FIXME: should it?]</strong>
+          Similarly, if the local user sends a message in C1, then
+          a new switchboard to X should be created and associated with C1.</p>
+
+        <p>XMPP and MSN do not natively have a concept of merging two or more
+          channels C1, C2... into one channel, Cn. However, the GSM-style
+          merging API can be supported on XMPP and MSN, as an API short-cut
+          for upgrading C1 into a conference Cn (which invites the
+          TargetHandle of C1 into Cn), then immediately inviting the
+          TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
+
+        <p>With a suitable change of terminology, Skype has behaviour similar
+          to MSN.</p>
+      </tp:rationale>
+
+      <p>The <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel.Interface"
+          >Group</tp:dbus-ref> MAY have channel-specific handles for participants;
+        clients SHOULD support both Conferences that have channel-specific handles,
+        and those that do not.</p>
+
+      <tp:rationale>
+        <p>In the GSM case, the Conference's Group interface MAY have
+          channel-specific handles, to reflect the fact that the identities of
+          the participants might not be known - it can be possible to know that
+          there is another participant in the Conference, but not know who
+          they are.
+          <strong>[FIXME: fact check from GSM gurus needed]</strong>
+        </p>
+
+        <p>In the XMPP case, the Conference's Group interface SHOULD have
+          channel-specific handles, to reflect the fact that the participants
+          have MUC-specific identities, and the user might also be able to see
+          their global identities, or not.</p>
+
+        <p>In most other cases, including MSN and link-local XMPP, the
+          Conference's Group interface SHOULD NOT have channel-specific
+          handles, since users' identities are always visible.</p>
+      </tp:rationale>
+
+      <p>Connection managers implementing channels with this interface
+        MUST NOT allow the object paths of channels that could be merged
+        into a Conference to be re-used, unless the channel re-using the
+        object path is equivalent to the channel that previously used it.</p>
+
+      <tp:rationale>
+        <p>If you upgrade some channels into a conference, and then close
+          the original channels, <tp:member-ref>InitialChannels</tp:member-ref>
+          (which is immutable) will contain paths to channels which no longer
+          exist. This implies that you should not re-use channel object paths,
+          unless future incarnations of the path are equivalent.</p>
+
+        <p>For instance, on protocols where you can only have
+          zero or one 1-1 text channels with Emily at one time, it would
+          be OK to re-use the same object path for every 1-1 text channel
+          with Emily; but on protocols where this is not true, it would
+          be misleading.</p>
+      </tp:rationale>
+
+    </tp:docstring>
+
+    <property name="Channels" tp:name-for-bindings="Channels"
+      access="read" type="ao">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The individual <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s that
+          are continued by this conference, which have the same <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Channel"
+              >ChannelType</tp:dbus-ref> as this one, but with <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Channel"
+              >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
+
+        <p>This property MUST NOT be requestable.
+          <strong>[FIXME: or would it be better for this one, and not IC, to be
+            requestable?]</strong>
+        </p>
+
+        <p>Change notification is via the
+          <tp:member-ref>ChannelMerged</tp:member-ref> and
+          <tp:member-ref>ChannelRemoved</tp:member-ref> signals.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="ChannelMerged" tp:name-for-bindings="Channel_Merged">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new channel is added to the value of
+          <tp:member-ref>Channels</tp:member-ref>.</p>
+      </tp:docstring>
+
+      <arg name="Channel" type="o">
+        <tp:docstring>The channel that was added to
+          <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="ChannelRemoved" tp:name-for-bindings="Channel_Removed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a channel is removed from the value of
+          <tp:member-ref>Channels</tp:member-ref>, either because it closed
+          or because it was split using the <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface"
+            >Splittable.DRAFT.Split</tp:dbus-ref> method.</p>
+
+        <p><strong>[FIXME: relative ordering of this vs. Closed? Do we
+            care?]</strong></p>
+      </tp:docstring>
+
+      <arg name="Channel" type="o">
+        <tp:docstring>The channel that was removed from
+          <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="InitialChannels" tp:name-for-bindings="Initial_Channels"
+      access="read" type="ao">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The initial value of <tp:member-ref>Channels</tp:member-ref>.</p>
+
+        <p>This property SHOULD be requestable. Omitting it from a request is
+          equivalent to providing it with an empty list as value. Requests
+          where its value has at least two elements SHOULD be expected to
+          succeed on any implementation of this interface.</p>
+
+        <p>Whether a request with 0 or 1 elements in the list will succeed is
+          indicated by <tp:member-ref>SupportsNonMerges</tp:member-ref>.</p>
+
+        <tp:rationale>
+          <p>In GSM, a pair of calls can be merged into a conference. In XMPP
+            and MSN, you can create a new chatroom, or upgrade one 1-1 channel
+            into a chatroom; however, on these protocols, it is also possible
+            to fake GSM-style merging by upgrading the first channel, then
+            inviting the targets of all the other channels into it.</p>
+        </tp:rationale>
+
+        <p>If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD
+          NOT be altered by merging them into a conference. However, depending on
+          the protocol, the Channels MAY be placed in a "frozen" state by placing
+          them in this property's value or by calling
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface"
+            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.
+          <strong>[FIXME: there's nothing in RequestableChannelClasses yet
+            to say what will happen, see #24906 comment 6]</strong></p>
+
+        <tp:rationale>
+          <p>In Jingle, nothing special will happen to merged calls. UIs MAY
+            automatically place calls on hold before merging them, if that is
+            the desired behaviour; this SHOULD always work. Not doing
+            an implicit hold/unhold seems to preserve least-astonishment.</p>
+
+          <p><strong>[FIXME: check whether ring supports faking Hold on both
+              channels, as it probably should: see #24906 comment 6]</strong>
+          </p>
+
+          <p>In GSM, the calls that are merged go into a state similar to
+            Hold, but they cannot be unheld, only split from the conference
+            call using <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+              >Channel.Interface.Splittable.DRAFT.Split</tp:dbus-ref>.</p>
+        </tp:rationale>
+
+        <p>Depending on the protocol, it might be signalled to remote users
+          that this channel is a continuation of all the requested channels,
+          or that it is only a continuation of the first channel in the
+          list.</p>
+
+        <tp:rationale>
+          <p>In MSN, the conference steals the underlying switchboard (protocol
+            construct) from one of its component channels, so the conference
+            appears to remote users to be a continuation of that channel and no
+            other. The connection manager has to make some arbitrary choice, so
+            we arbitrarily mandate that it SHOULD choose the first channel in
+            the list as the one to continue.</p>
+        </tp:rationale>
+
+        <p>This property is immutable.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialInviteeHandles"
+      tp:name-for-bindings="Initial_Invitee_Handles"
+      access="read" type="au" tp:type="Contact_Handle[]">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of additional contacts invited to this conference when it
+          was created.</p>
+
+        <p>This property SHOULD be requestable, and appear in the allowed
+          properties in <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+            >RequestableChannelClasses</tp:dbus-ref>, in all connection
+          managers that can implement its semantics (in practice, this is
+          likely to mean exactly those connection managers where
+          <tp:member-ref>SupportsNonMerges</tp:member-ref> will be true).</p>
+
+        <p>If included in a request, the given contacts are automatically
+          invited into the new channel, as if they had been added with
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
+            >Group.AddMembers</tp:dbus-ref>(InitialInviteeHandles,
+          <tp:member-ref>InvitationMessage</tp:member-ref>) immediately after
+          the channel was created.</p>
+
+        <tp:rationale>
+          <p>This is a simple convenience API for the common case that a UI
+            upgrades a 1-1 chat to a multi-user chat solely in order to invite
+            someone else to participate.</p>
+        </tp:rationale>
+
+        <p>If the local user was not the initiator of this channel, the
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
+            >Group.SelfHandle</tp:dbus-ref> SHOULD appear in the value of this
+          property, together with any other contacts invited at the same time
+          (if that information is known).</p>
+
+        <p>This property is immutable.</p>
+
+        <p>InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be
+          combined in a single request.</p>
+
+        <tp:rationale>
+          <p>For example, if you have a 1-1 channel C1 with Rob, and you want
+            to invite Sjoerd to join the discussion, you can do so by
+            requesting a channel with InitialChannels=[C1] and
+            InitialInviteeHandles=[sjoerd],
+            or InitialChannels=[C1] and
+            InitialInviteeIDs=["sjoerd@example.com"].</p>
+        </tp:rationale>
+
+        <p>If a request includes some combination of InitialInviteeHandles,
+          InitialInviteeIDs and InitialChannels, then the value of
+          InitialInviteeHandles on the resulting channel SHOULD be the union of
+          the handles from InitialInviteeHandles, the handles corresponding
+          to the InitialInviteeIDs, and the target handles of the
+          InitialChannels, with any duplicate handles removed. Because this
+          property is immutable, its value SHOULD be computed before the
+          channel is announced via the NewChannels signal.</p>
+
+        <tp:rationale>
+          <p>This simplifies identification of new channels in clients - they
+            only have to look at one of the properties, not both. For example,
+            after either of the requests mentioned above, the NewChannels
+            signal would announce the channel with InitialChannels=[C1],
+            InitialInviteeHandles=[rob, sjoerd], and
+            InitialInviteeIDs=["rob@example.net", "sjoerd.example.com"].</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialInviteeIDs"
+      tp:name-for-bindings="Initial_Invitee_IDs"
+      access="read" type="as">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of additional contacts invited to this conference when it
+          was created.</p>
+
+        <p>This property SHOULD be requestable as an alternative to, or
+          combined with, <tp:member-ref>InitialInviteeHandles</tp:member-ref>.
+          Its semantics are the same, except that it takes a list of the
+          string representations of contact handles; invitations are sent to
+          any contact present in either or both of these properties.</p>
+
+        <p>When a channel is created, the values of InitialInviteeHandles and
+          InitialInviteeIDs MUST correspond to each other. In particular, this
+          means that the value of InitialInviteeIDs will include the TargetID
+          of each channel in InitialChannels, and the ID corresponding to each
+          handle in InitialInviteeHandles.</p>
+
+        <p>This property is immutable.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InvitationMessage" tp:name-for-bindings="Invitation_Message"
+      access="read" type="s">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The message that was sent to the
+          <tp:member-ref>InitialInviteeHandles</tp:member-ref> when they were
+          invited.</p>
+
+        <p>This property SHOULD be requestable, and appear in the allowed
+          properties in <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+            >RequestableChannelClasses</tp:dbus-ref>, in protocols where
+          invitations can have an accompanying text message.</p>
+
+        <tp:rationale>
+          <p>This allows invitations with a message to be sent when using
+            <tp:member-ref>InitialInviteeHandles</tp:member-ref> or
+            <tp:member-ref>InitialInviteeIDs</tp:member-ref>.</p>
+        </tp:rationale>
+
+        <p>If the local user was not the initiator of this channel, the
+          message with which they were invited (if any) SHOULD appear in the
+          value of this property.</p>
+
+        <p>This property is immutable.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="SupportsNonMerges"
+      tp:name-for-bindings="Supports_Non_Merges"
+      access="read" type="b">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p><strong>[FIXME: needs a better name; or perhaps it could be implied
+            by InitialInviteeHandles being requestable in XMPP/MSN but not in
+            GSM?]</strong></p>
+
+        <p>If true, requests with <tp:member-ref>InitialChannels</tp:member-ref>
+          omitted, empty, or one element long should be expected to succeed.</p>
+
+        <p>This property SHOULD appear in <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+              >RequestableChannelClasses</tp:dbus-ref> for
+          conference channels if and only if its value on those channels will
+          be true.</p>
+
+        <tp:rationale>
+          <p>Putting this in <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+              >RequestableChannelClasses</tp:dbus-ref> means clients can find
+            out whether their request will succeed early enough to do
+            something about it.</p>
+
+          <p>In XMPP, you can request a channel of type ROOM without
+            incorporating any 1-1 chats at all - indeed, this is the normal
+            way to do it - or as a continuation of a single 1-1 chat, and then
+            invite other people in later.</p>
+
+          <p>The sense of this property is a bit awkward, but it avoids making it
+            an anti-capability. If the sense were inverted, then its presence in
+            RequestableChannelClasses would imply that the protocol <em>lacks</em>
+            a feature; as it stands, it is additive. (Contrast with
+            <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"
+              >ImmutableStreams</tp:dbus-ref>, which is the wrong way around for
+            backwards-compatibility reasons.)</p>
+        </tp:rationale>
+
+        <p>If false, <tp:member-ref>InitialChannels</tp:member-ref> SHOULD be
+          supplied in all requests for this channel class, and contain at least
+          two channels. Requests where this requirement is not met SHOULD fail
+          with NotImplemented.
+        </p>
+
+        <tp:rationale>
+          <p>In GSM, you can only make a conference call by merging at least
+            two channels.
+            <strong>[FIXME: the CM could conceivably fake it, but that would be
+              rather nasty]</strong>
+          </p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
diff --git a/spec/Channel_Interface_DTMF.xml b/spec/Channel_Interface_DTMF.xml
index bd20f6ed..c74dd513 100644
--- a/spec/Channel_Interface_DTMF.xml
+++ b/spec/Channel_Interface_DTMF.xml
@@ -20,6 +20,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </tp:license>
   <interface name="org.freedesktop.Telepathy.Channel.Interface.DTMF">
     <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+    <tp:changed version="0.19.6">The <tp:type>Stream_ID</tp:type>s in this
+      interface should now be ignored by CMs. This is primarily to allow this
+      interface to be used with <tp:dbus-ref
+      namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+      channels.</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       An interface that gives a Channel the ability to send DTMF events over
@@ -30,6 +35,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:docstring>
 
     <method name="StartTone" tp:name-for-bindings="Start_Tone">
+      <tp:changed version="0.19.6">The <var>Stream_ID</var> parameter became
+        vestigial.</tp:changed>
       <arg direction="in" name="Stream_ID" type="u" tp:type="Stream_ID">
         <tp:docstring>A stream ID as defined in the StreamedMedia channel
         type. This argument is included for backwards compatibility and MUST
@@ -78,6 +85,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </method>
 
     <method name="StopTone" tp:name-for-bindings="Stop_Tone">
+      <tp:changed version="0.19.6">The <var>Stream_ID</var> parameter became
+        vestigial.</tp:changed>
       <arg direction="in" name="Stream_ID" type="u" tp:type="Stream_ID">
         <tp:docstring>A stream ID as defined in the StreamedMedia channel
         type. This argument is included for backwards compatibility and MUST
diff --git a/spec/Channel_Interface_Mergeable_Conference.xml b/spec/Channel_Interface_Mergeable_Conference.xml
index 989ffacf..03e89683 100644
--- a/spec/Channel_Interface_Mergeable_Conference.xml
+++ b/spec/Channel_Interface_Mergeable_Conference.xml
@@ -23,7 +23,7 @@
     name="org.freedesktop.Telepathy.Channel.Interface.MergeableConference.DRAFT"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Conference"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can have
@@ -50,11 +50,11 @@
 
         <p>The given channel SHOULD be added to <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT.Channels</tp:dbus-ref> if and only if the
+            >Conference.Channels</tp:dbus-ref> if and only if the
           underlying protocol signals the merge in some way. It MUST NOT be
           added to <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT.InitialChannels</tp:dbus-ref> (to preserve
+            >Conference.InitialChannels</tp:dbus-ref> (to preserve
           immutability).</p>
 
         <tp:rationale>
diff --git a/spec/Channel_Interface_SMS.xml b/spec/Channel_Interface_SMS.xml
new file mode 100644
index 00000000..b0dce664
--- /dev/null
+++ b/spec/Channel_Interface_SMS.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_SMS"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2008–2010 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+  </tp:license>
+
+  <interface
+    name="org.freedesktop.Telepathy.Channel.Interface.SMS">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
+    <tp:added version='0.19.12'>Imported from
+      rtcom-telepathy-glib, with the unused properties removed and the
+      documentation tidied up.</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface contains SMS-specific properties for text channels.
+        This currently only includes whether the SMSes received on the channel
+        should be displayed immediately to the user, without prompting.</p>
+
+      <h4>Handler filters</h4>
+
+      <p>A handler for class 0 SMSes should advertise the following filter:</p>
+
+      <blockquote><code>
+{ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+  ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+      <tp:type>Handle_Type</tp:type>_Contact,<br/>
+  ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
+      True,<br/>
+}</code></blockquote>
+
+      <p>It should also set its <tp:dbus-ref
+        namespace='ofdT.Client.Handler'>BypassApproval</tp:dbus-ref> property
+        to <code>True</code>, so that it is invoked immediately for new
+        channels.</p>
+    </tp:docstring>
+
+    <property name="Flash" tp:name-for-bindings="Flash"
+      type="b" access="read" >
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <code>True</code>, then this channel is exclusively for
+          receiving class 0 SMSes (and no SMSes can be sent using <tp:dbus-ref
+          namespace='ofdT.Channel.Interface.Messages'>SendMessage</tp:dbus-ref>
+          on this channel). If <code>False</code>, no incoming class 0 SMSes
+          will appear on this channel.</p>
+
+        <p>This property is immutable (cannot change), and therefore SHOULD
+          appear wherever immutable properties are reported, e.g. <tp:dbus-ref
+            namespace="ofdT.Connection.Interface.Requests"
+          >NewChannels</tp:dbus-ref> signals.</p>
+
+        <tp:rationale>
+          <p>Class 0 SMSes should be displayed immediately to the user, and
+            need not be saved to the device memory unless the user explicitly
+            chooses to do so. This is unlike “normal”, class 1 SMSes, which
+            must be stored, but need not be shown immediately in their entirity
+            to the user.</p>
+
+          <p>Separating class 0 SMSes into their own channel with this
+            immutable property allows them to be dispatched to a different
+            <tp:dbus-ref namespace='ofdT.Client'>Handler</tp:dbus-ref>—which
+            would include this property in its <tp:dbus-ref
+            namespace='ofdT.Client.Handler'
+            >HandlerChannelFilter</tp:dbus-ref>—avoiding the normal Text
+            channel handler having to decide for each message whether it should
+            be displayed to the user immediately or handled normally.</p>
+
+          <p>Currently, no mechanism is defined for <em>sending</em> class 0
+            SMSes. It seems reasonable to support specifying the class of an
+            outgoing SMS in its header <tp:type>Message_Part</tp:type>, rather
+            than requiring the UI to request a special channel for such SMSes;
+            hence, we define here that channels with Flash set to
+            <code>True</code> are read-only.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
diff --git a/spec/Channel_Interface_Splittable.xml b/spec/Channel_Interface_Splittable.xml
index 063565e8..7509c9c8 100644
--- a/spec/Channel_Interface_Splittable.xml
+++ b/spec/Channel_Interface_Splittable.xml
@@ -28,7 +28,7 @@
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for channels that can be made conceptually part of a
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference.DRAFT</tp:dbus-ref>, and can then be detached from that
+          >Conference</tp:dbus-ref>, and can then be detached from that
         conference.</p>
 
       <tp:rationale>
@@ -45,14 +45,11 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request that this channel is removed from any
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference.DRAFT</tp:dbus-ref> of which it is a part.</p>
+          >Conference</tp:dbus-ref> of which it is a part.</p>
 
         <p>This implies that the media streams within the conference are put on
           hold and the media streams within the member channel leaving the
-          conference are unheld.
-          <strong>[FIXME: or, maybe it'd be less surprising if it didn't do
-            this?]</strong>
-        </p>
+          conference are unheld.</p>
       </tp:docstring>
 
       <tp:possible-errors>
diff --git a/spec/Channel_Request_Future.xml b/spec/Channel_Request_Future.xml
new file mode 100644
index 00000000..d75c7e0c
--- /dev/null
+++ b/spec/Channel_Request_Future.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Request_Future"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2008-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+      02110-1301, USA.</p>
+    </tp:license>
+    <interface name="org.freedesktop.Telepathy.ChannelRequest.FUTURE"
+      tp:causes-havoc="a staging area for future Channel functionality">
+
+      <tp:requires interface="org.freedesktop.Telepathy.ChannelRequest"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface contains functionality which we intend to incorporate
+        into the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+        interface in future. It should be considered to
+        be conceptually part of the core ChannelRequest interface, but without
+        API or ABI guarantees.</p>
+    </tp:docstring>
+
+    <property name="Hints" tp:name-for-bindings="Hints"
+      type="a{sv}" access="read">
+      <tp:added version="0.19.12">(as draft)</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A dictionary of metadata provided by the channel
+          requester, which the handler and other clients MAY choose to
+          interpret.  Currently no standard keys are defined; clients MAY
+          choose to use platform-specific keys for their own purposes, but MUST
+          ignore unknown keys and MUST cope with expected keys being
+          missing.</p>
+
+        <tp:rationale>This property might be used to pass a contact ID for a
+          telephone number shared between two contacts from the address book to
+          the call UI, so that if you try to call “Mum”, the call UI knows this
+          rather than having to guess or show “Calling Mum or Dad”. The format
+          of these contact IDs would be platform-specific, so we leave the
+          definition of the dictionary entry up to the platform in question.
+          But third-party channel requesters might not include the contact ID,
+          so the call UI has to be able to deal with it not being
+          there.</tp:rationale>
+
+        <p>The channel dispatcher will not interpret these hints: they are
+          solely for communication between cooperating clients.</p>
+
+        <tp:rationale>
+          <p>Any extra parameters that do affect the channel dispatcher should
+            be designed separately.</p>
+        </tp:rationale>
+
+        <p>This property may be set when the channel request is created, and
+          can never change. Since it is immutable, it SHOULD be included in the
+          dictionary of properties passed to <tp:dbus-ref
+          namespace="ofdT.Client.Interface.Requests">AddRequest</tp:dbus-ref>
+          by the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="SucceededWithChannel" tp:name-for-bindings="Succeeded_With_Channel">
+      <tp:added version="0.19.12">(as draft)</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Variant of the <tp:dbus-ref
+            namespace="ofdT.ChannelRequest">Succeeded</tp:dbus-ref> signal
+        allowing to get the channel which has been created.</p>
+      </tp:docstring>
+
+      <arg name="Connection" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The Connection owning the channel.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg name="Channel" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The channel which has been created.</p>
+        </tp:docstring>
+      </arg>
+
+    </signal>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call.xml
index f1d0f0e0..68dc7ffc 100644
--- a/spec/Channel_Type_Call.xml
+++ b/spec/Channel_Type_Call.xml
@@ -663,6 +663,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           </tp:rationale>
         </tp:docstring>
       </tp:flag>
+
+      <tp:flag suffix="Conference_Host" value="4">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          This contact has merged this call into a conference. Note that GSM
+          provides a notification when the remote party merges a call into a
+          conference, but not when it is split out again; thus, this flag can
+          only indicate that the call has been part of a conference at some
+          point. If a GSM connection manager receives a notification that a
+          call has been merged into a conference a second time, it SHOULD
+          represent this by clearing and immediately re-setting this flag on
+          the remote contact.
+        </tp:docstring>
+      </tp:flag>
     </tp:flags>
 
     <tp:mapping name="Call_Member_Map" array-name="Call_Member_Map_List">
diff --git a/spec/Channel_Type_Server_TLS_Connection.xml b/spec/Channel_Type_Server_TLS_Connection.xml
index 1d705c55..1f3348e1 100644
--- a/spec/Channel_Type_Server_TLS_Connection.xml
+++ b/spec/Channel_Type_Server_TLS_Connection.xml
@@ -18,9 +18,8 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerTLSConnection.DRAFT"
-             tp:causes-havoc="experimental">
-    <tp:added version="0.19.11">(draft 1)</tp:added>
+  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerTLSConnection">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
 
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
 
@@ -45,16 +44,26 @@
     </tp:docstring>
 
     <property name="ServerCertificate" type="o" access="read"
-              tp:name-for-bindings="ServerCertificate">
+              tp:name-for-bindings="Server_Certificate">
       <tp:docstring>
         <p>A <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate.DRAFT</tp:dbus-ref>
+        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
         containing the certificate chain as sent by the server,
         and other relevant information.</p>
         <p>This property is immutable.</p>
       </tp:docstring>
     </property>
 
+    <property name="Hostname" type="s" access="read"
+              tp:name-for-bindings="Hostname">
+      <tp:added version="0.19.12"/>
+      <tp:docstring>
+        The hostname of the server we expect <tp:member-ref>ServerCertificate</tp:member-ref>
+        to certify; clients SHOULD verify <tp:member-ref>ServerCertificate</tp:member-ref> against
+	this hostname when checking its validity.
+      </tp:docstring>
+    </property>
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
index 54456591..aa2b9034 100644
--- a/spec/Channel_Type_Streamed_Media.xml
+++ b/spec/Channel_Type_Streamed_Media.xml
@@ -771,14 +771,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         following filter in <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>:</dt>
       <dd><pre>
-{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
+{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
   '...Channel.TargetHandleType': Contact,
 }</pre></dd>
 
       <dt>To advertise support for audio calls, also include the following
         filter:</dt>
       <dd><pre>
-{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
+{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
   '...Channel.TargetHandleType': Contact,
   '...Channel.Type.StreamedMedia.InitialAudio': True,
 }</pre></dd>
@@ -786,7 +786,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <dt>To advertise support for video calls, also include the following
         filter:</dt>
       <dd><pre>
-{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
+{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
   '...Channel.TargetHandleType': Contact,
   '...Channel.Type.StreamedMedia.InitialVideo': True,
 }</pre></dd>
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index 10a16bd6..2cceed17 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -279,11 +279,21 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
 
       <arg name="Handler_Info" type="a{sv}" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Additional information about these channels. No keys are
-            currently defined.</p>
-
-          <p>If keys are defined for this dictionary, all will be optional;
-            handlers MAY safely ignore any entry in this dictionary.</p>
+          <p>Additional information about these channels. Currently defined
+            keys are:</p>
+
+          <dl>
+            <dt><code>request-properties</code> - a{oa{sv}}</dt>
+            <dd>A map from <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              paths listed in <var>Requests_Satisfied</var> to
+              <tp:type>Qualified_Property_Value_Map</tp:type>s containing
+              namespaced immutable properties of each request.</dd>
+          </dl>
+
+          <p>When more keys are defined for this dictionary, all will be
+            optional; handlers MAY safely ignore any entry in this
+            dictionary.</p>
         </tp:docstring>
       </arg>
 
diff --git a/spec/Client_Handler_Future.xml b/spec/Client_Handler_Future.xml
index 776fa4f3..da31fadc 100644
--- a/spec/Client_Handler_Future.xml
+++ b/spec/Client_Handler_Future.xml
@@ -39,9 +39,9 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, channels destined for this handler that have the
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT</tp:dbus-ref> interface, with a channel that
+            >Conference</tp:dbus-ref> interface, with a channel that
           was previously handled by the same client process in their
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Conference"
             >InitialChannels</tp:dbus-ref> property, should bypass the
           approval stage. In effect, this is a weaker form of
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler"
diff --git a/spec/Client_Interface_Requests.xml b/spec/Client_Interface_Requests.xml
index f4c11087..cfab58de 100644
--- a/spec/Client_Interface_Requests.xml
+++ b/spec/Client_Interface_Requests.xml
@@ -124,7 +124,9 @@
               namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
             and <tp:dbus-ref
               namespace="org.freedesktop.Telepathy.ChannelRequest">Account</tp:dbus-ref>
-            MUST be included.</p>
+            MUST be included, and <tp:dbus-ref
+              namespace="ofdT.ChannelRequest.FUTURE">Hints</tp:dbus-ref>
+            SHOULD be included if implemented.</p>
         </tp:docstring>
       </arg>
     </method>
diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml
index 912edaf4..01fee8b9 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -326,7 +326,9 @@ Recover=true
 
       <arg name="Requests_Satisfied" type="ao" direction="in">
         <tp:docstring>
-          The requests satisfied by these channels.
+          The <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>s
+          satisfied by these channels.
 
           <tp:rationale>
             If the same process is an Observer and a Handler, it can be useful
@@ -356,6 +358,13 @@ Recover=true
                 the same observer crashed).
               </tp:rationale>
             </dd>
+
+            <dt><code>request-properties</code> - a{oa{sv}}</dt>
+            <dd>A map from <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              paths listed in <var>Requests_Satisfied</var> to
+              <tp:type>Qualified_Property_Value_Map</tp:type>s containing
+              namespaced immutable properties of each request.</dd>
           </dl>
 
           <p>All defined keys for this dictionary are optional;
diff --git a/spec/Connection.xml b/spec/Connection.xml
index 6587bb2d..72f1e343 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -1010,10 +1010,8 @@ USA.</p>
             <dd>Debugging information on the change, corresponding to the
               message part of a D-Bus error message, which SHOULD NOT be
               displayed to users under normal circumstances</dd>
-	    <dt>expected-hostname (s), certificate-hostname (s)</dt>
-	    <dd>The same details defined in <tp:dbus-ref
-	    namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate.DRAFT.RejectDetails</tp:dbus-ref>
-	    </dd>
+	    <dt>user-requested (b), expected-hostname (s), certificate-hostname (s)</dt>
+	    <dd>The same details defined in <tp:type>TLS_Certificate_Rejection</tp:type>.</dd>
           </dl>
 
         </tp:docstring>
diff --git a/spec/Connection_Interface_Addressing.xml b/spec/Connection_Interface_Addressing.xml
new file mode 100644
index 00000000..497c6d0d
--- /dev/null
+++ b/spec/Connection_Interface_Addressing.xml
@@ -0,0 +1,258 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Addressing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright> Copyright (C) 2010 Collabora Limited </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or modify it
+      under the terms of the GNU Lesser General Public License as published by
+      the Free Software Foundation; either version 2.1 of the License, or (at
+      your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful, but
+      WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser
+      General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public License
+      along with this library; if not, write to the Free Software Foundation,
+      Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.Addressing.DRAFT"
+             tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.Contacts"/>
+    <tp:added version="0.19.12">(as draft)</tp:added>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface deals with the multiple address types that can
+      refer to the same contact, such as vCard fields and URIs.</p>
+
+      <p>It can be used to retrieve contacts with a specific addresses
+        through <tp:member-ref>GetContactsByVCardField</tp:member-ref> and
+        <tp:member-ref>GetContactsByURI</tp:member-ref>, as well as
+        defining the various addressing methods for a given contact
+        through this interface's contact attributes.</p>
+    </tp:docstring>
+
+    <method name="GetContactsByVCardField"
+            tp:name-for-bindings="Get_Contacts_By_VCard_Field">
+      <arg direction="in" name="Field" type="s">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The vCard field of the addresses we are requesting. The
+            field name SHOULD be in lower case. Supported
+            fields can be found in
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableVCardFields</tp:dbus-ref>.</p>
+
+          <p>The <code>url</code> vCard field MUST NOT appear here; see
+            <tp:member-ref>GetContactsByURI</tp:member-ref> instead.</p>
+
+          <tp:rationale>
+            <p>In practice, protocols have a limited set of URI
+              schemes that make sense to resolve as a contact.</p>
+          </tp:rationale>
+
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Addresses" type="as">
+        <tp:docstring>
+          The addresses to get contact handles for. The address types
+          should match the given vCard field.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Interfaces" type="as"
+        tp:type="DBus_Interface[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A list of strings indicating which D-Bus interfaces the calling
+            process is interested in. All supported attributes from these
+            interfaces, whose values can be obtained without additional network
+            activity, will be in the reply.</p>
+
+          <p>Attributes from this interface and from
+            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
+            are always returned, and need not be requested
+            explicitly.</p>
+
+          <p>The behavior of this parameter is similar to the same
+            parameter in
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
+          </tp:docstring>
+      </arg>
+
+      <arg direction="out" type="a{ua{sv}}" name="Requested_Contacts"
+           tp:type="Contact_Attributes_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A dictionary mapping the contact handles to contact attributes.
+            If any of the requested addresses are in fact invalid, they are
+            simply omitted from this mapping. If contact attributes are not
+            immediately known, the behaviour is defined by the interface;
+            the attribute should either be omitted from the result or
+            replaced with a default value.</p>
+
+          <p>Requested addresses that cannot be satisfied MUST be ommitted
+            from the mapping.</p>
+
+          <p>Each contact's attributes will always include at least the
+            identifier that would be obtained by inspecting the handle
+            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>),
+          and the vCard field used for requesting the contact in
+            <code>org.freedesktop.Telepathy.Connection.Interface.ContactInfo/info</code>.
+          </p>
+        </tp:docstring>
+      </arg>
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Request contacts and retrieve their attributes using a given field
+          in their vCards.</p>
+
+        <p>The connection manager should record that these handles are in
+          use by the client who invokes this method, and must not
+          deallocate the handles until the client disconnects from the
+          bus or calls the
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.ReleaseHandles</tp:dbus-ref>
+          method.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="GetContactsByURI"
+            tp:name-for-bindings="Get_Contacts_By_URI">
+      <arg direction="in" name="URIs" type="as">
+        <tp:docstring>
+          The URI addresses to get contact handles for. Supported
+          schemes can be found in
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableURISchemes</tp:dbus-ref>.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Interfaces" type="as"
+        tp:type="DBus_Interface[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A list of strings indicating which D-Bus interfaces the calling
+            process is interested in. All supported attributes from these
+            interfaces, whose values can be obtained without additional network
+            activity, will be in the reply.</p>
+
+          <p>Attributes from this interface and from
+            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
+            are always returned, and need not be requested
+            explicitly.</p>
+
+          <p>The behavior of this parameter is similar to the same
+            parameter in
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
+          </tp:docstring>
+      </arg>
+
+      <arg direction="out" type="a{ua{sv}}" name="Requested_Contacts"
+           tp:type="Contact_Attributes_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A dictionary mapping the contact handles to contact attributes.
+            If any of the requested addresses are in fact invalid, they are
+            simply omitted from this mapping. If contact attributes are not
+            immediately known, the behaviour is defined by the interface;
+            the attribute should either be omitted from the result or
+            replaced with a default value.</p>
+
+          <p>Requested URIs that cannot be satisfied MUST be ommitted
+            from the mapping.</p>
+
+          <p>Each contact's attributes will always include at least the
+            identifier that would be obtained by inspecting the handle
+            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>).
+          </p>
+        </tp:docstring>
+      </arg>
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Request contacts and retrieve their attributes using URI addresses.</p>
+
+        <p>The connection manager should record that these handles are in
+          use by the client who invokes this method, and must not
+          deallocate the handles until the client disconnects from the
+          bus or calls the
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.ReleaseHandles</tp:dbus-ref>
+          method.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+      </tp:possible-errors>
+    </method>
+
+    <tp:mapping name="VCard_Field_Address_Map" array-name="">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A mapping of vCard fields and addresses that repreent
+          the given contact.</p>
+      </tp:docstring>
+      <tp:member type="s" name="VCard_Field"/>
+      <tp:member type="s" name="Address"/>
+    </tp:mapping>
+
+    <tp:contact-attribute name="addresses" type="a{ss}"
+                          tp:type="VCard_Field_Address_Map">
+      <tp:docstring>
+        The various vCard addresses that identify this contact.
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <tp:contact-attribute name="uris" type="as">
+      <tp:docstring>
+        The various URI addresses that identify this contact.
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <tp:contact-attribute name="requested-address" type="(ss)"
+                          tp:type="Requested_Address">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The contact's address, as it was requested
+        through <tp:member-ref>GetContactsByVCardField</tp:member-ref>. This
+        attribute MUST be ommitted if the contact was not retrieved
+        through <tp:member-ref>GetContactsByVCardField</tp:member-ref>.</p>
+      <tp:rationale>
+        <p>When retrieving more than one contact
+          through <tp:member-ref>GetContactsByVCardField</tp:member-ref>,
+          there needs to be a way to map the given contact back o the
+          original request.</p>
+      </tp:rationale>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <tp:contact-attribute name="requested-uri" type="s">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The contact's URI, as it was requested through
+        <tp:member-ref>GetContactsByURI</tp:member-ref>. This
+        attribute MUST be ommitted if the contact was not retrieved
+        through <tp:member-ref>GetContactsByURI</tp:member-ref>.</p>
+      <tp:rationale>
+        <p>When retrieving more than one contact
+        through <tp:member-ref>GetContactsByURI</tp:member-ref>,
+        there needs to be a way to map the given contact back o the
+        original request.</p>
+      </tp:rationale>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <tp:struct name="Requested_Address" array-name="">
+      <tp:docstring>
+        The address that has been requested by
+        <tp:member-ref>GetContactsByVCardField</tp:member-ref> or
+        <tp:member-ref>GetContactsByURI</tp:member-ref>.
+      </tp:docstring>
+
+      <tp:member name="Field" type="s">
+        <tp:docstring>
+          The vCard field used in <tp:member-ref>GetContactsByVCardField</tp:member-ref>.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Address" type="s">
+        <tp:docstring>
+          The address that was requested.
+        </tp:docstring>
+      </tp:member>
+
+    </tp:struct>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Cellular.xml b/spec/Connection_Interface_Cellular.xml
index bf0f1a9c..3dc29e32 100644
--- a/spec/Connection_Interface_Cellular.xml
+++ b/spec/Connection_Interface_Cellular.xml
@@ -63,12 +63,63 @@
       </tp:docstring>
     </property>
 
+    <property name="OverrideMessageServiceCentre"
+        tp:name-for-bindings="Override_Message_Service_Centre"
+        type="b" access="readwrite">
+      <tp:added version='0.19.12'>Previously, as an undocumented
+        feature, setting <tp:member-ref>MessageServiceCentre</tp:member-ref>
+        to the empty string caused the SIM's default SMSC to be used.</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <code>True</code>, SMSes will be sent via the service centre
+          specified by <tp:member-ref>MessageServiceCentre</tp:member-ref>. If
+          <code>False</code>, the SIM's default SMSC will be used, ignoring the
+          value of MessageServiceCentre.</p>
+
+        <tp:rationale>
+          <p>It could be desirable for a configuration interface to remember
+            the user's previous choice of custom SMSC, even if it's not in use.
+            This boolean allows that choice to be saved as an account parameter
+            by Mission Control, rather than the UI needing to save it elsewhere
+            to be restored if the user wants to reactivate it.</p>
+        </tp:rationale>
+
+        <p>Connections with this interface SHOULD provide this property as a
+          parameter of the same (fully-qualified) name to <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy"
+            >ConnectionManager.RequestConnection</tp:dbus-ref>, with the
+          <code>DBus_Property</code> flag. For connections managed by the
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>,
+          this property SHOULD be set via the Account Manager as follows:</p>
+
+        <blockquote>
+          <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Account"
+            >UpdateParameters</tp:dbus-ref>({
+              "org.freedesktop.Telepathy.Connection.Interface.Cellular.OverrideMessageServiceCentre": True
+              }, [])</code>
+        </blockquote>
+
+        <p>The AccountManager provides change-notification, as long as all
+          other clients cooperate by using it instead of setting this property
+          directly.</p>
+      </tp:docstring>
+    </property>
+
     <property name="MessageServiceCentre" tp:name-for-bindings="Message_Service_Centre"
       type="s" access="readwrite">
+      <tp:changed version='0.19.12'>This property's value is now
+        ignored unless
+        <tp:member-ref>OverrideMessageServiceCentre</tp:member-ref> is
+        <code>True</code>.</tp:changed>
+
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+
         <p>Address for the messaging service centre. Typically (as is the case
           for GSM's SMSC), it's the ISDN / telephony address (ie. a phone
-          number).</p>
+          number). If
+          <tp:member-ref>OverrideMessageServiceCentre</tp:member-ref> is
+          <code>False</code>, this property's value should be ignored by the CM
+          in favour of the SIM's default SMSC.</p>
 
         <p>Connections with this interface SHOULD provide this property as a
           parameter of the same (fully-qualified) name to <tp:dbus-ref
diff --git a/spec/Connection_Interface_Client_Types.xml b/spec/Connection_Interface_Client_Types.xml
index 879095e7..97908561 100644
--- a/spec/Connection_Interface_Client_Types.xml
+++ b/spec/Connection_Interface_Client_Types.xml
@@ -17,9 +17,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ClientTypes.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.11">(as draft)</tp:added>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ClientTypes">
+    <tp:added version="0.21.1">(as stable API)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -47,30 +46,38 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <li>pc</li>
         <li>phone</li>
         <li>web</li>
+<!-- Excluding these two because there's been no conclusion regarding my mail
+     to standards@xmpp.org about adding these two to their list:
+
         <li>sms (the client is not actually an instant messaging client
           but all messages sent to this contact will be delivered as SMSs)</li>
         <li>game (a gaming device)</li>
+-->
       </ul>
 
       <p>If the empty list is given as the client types, this means that
         details about the contact's client types are unknown. If there are
         multiple resources of a contact online at one point in time, the
         client types of the most available resource will be returned. In
-        other words, the client types are the types of the client whose
-        SimplePresence we see. For example, if a contact has two
-        resources:</p>
+        other words, the returned client types are those for the resource whose
+        presence will be retreived using the
+        <tp:dbus-ref namespace="ofdT.Connection.Interface">SimplePresence</tp:dbus-ref>
+        interface.</p>
+
+      <p>For example, if a contact has two resources:</p>
 
       <ul>
-        <li>one his phone, with presence "available", and</li>
-        <li>one his pc, with presence "busy",</li>
+        <li>their phone, with presence "available"; and</li>
+        <li>their pc, with presence "busy";</li>
       </ul>
 
       <p>then the methods in this interface will return an array (with
-      one element: "phone") as the client types as that is the more
-      available resource. If some time later his phone's presence
-      moves to "away", then the
+      one element: "phone") as the client types because that is the more
+      available resource. If at some later time the contact's phone's presence
+      changes to "away", the
       <tp:member-ref>ClientTypesUpdated</tp:member-ref> signal will
-      notify that his client type have changed from "phone" to "pc",
+      notify that the contact's client types attribute has changed from
+      ["phone"] to ["pc"],
       because "busy" is a more available presence than "away".</p>
 
     </tp:docstring>
@@ -84,7 +91,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           A contact.
         </tp:docstring>
       </tp:member>
-      <tp:member type="as" name="Client_Types">
+      <tp:member type="as" name="Client_Types" tp:type="Contact_Client_Type[]">
         <tp:docstring>
           The contact's client types as documented earlier in this interface.
         </tp:docstring>
@@ -151,7 +158,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </arg>
 
-      <arg direction="out" name="Client_Types" type="as">
+      <arg direction="out" name="Client_Types" type="as"
+        tp:type="Contact_Client_Type[]">
         <tp:docstring>
           The contact's client types. It MAY be empty, indicating that no client
           type information was found.
@@ -181,7 +189,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           The contact.
         </tp:docstring>
       </arg>
-      <arg name="Client_Types" type="as">
+      <arg name="Client_Types" type="as" tp:type="Contact_Client_Type[]">
         <tp:docstring>
           The contact's client types, or an empty list to indicate that nothing
           is known about the contact's client types.
@@ -189,7 +197,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
     </signal>
 
-    <tp:contact-attribute name="client-types" type="as">
+    <tp:contact-attribute name="client-types" type="as"
+      tp:type="Contact_Client_Type[]">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The same mapping that would be returned by
           <tp:member-ref>GetClientTypes</tp:member-ref> for this contact.
@@ -198,6 +207,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </tp:contact-attribute>
 
+    <tp:simple-type name="Contact_Client_Type" type="s"
+      array-name="Contact_Client_Type_List">
+      <tp:docstring>A string representing a single client type of a
+        contact.</tp:docstring>
+    </tp:simple-type>
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Communication_Policy.xml b/spec/Connection_Interface_Communication_Policy.xml
new file mode 100644
index 00000000..9a92fa04
--- /dev/null
+++ b/spec/Connection_Interface_Communication_Policy.xml
@@ -0,0 +1,163 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Communication_Policy"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Limited</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+  </tp:license>
+
+  <interface
+     name="org.freedesktop.Telepathy.Connection.Interface.CommunicationPolicy.DRAFT"
+     tp:causes-havoc="experimental">
+    <tp:added version="0.21.1">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>
+        This interface supports controlling which contacts are allowed
+        to initiate text chats, incoming calls, and other forms of
+        communication as supported by the underlying protocol. The
+        policies supported for different communication methods on this
+        connection are listed in the
+        <tp:member-ref>SupportedPolicies</tp:member-ref> property. The
+        current configuration is held in
+        <tp:member-ref>ActivePolicies</tp:member-ref>; it can be modified
+        using <tp:member-ref>SetPolicy</tp:member-ref>, and changes
+        are signalled by <tp:member-ref>PolicyChanged</tp:member-ref>.
+      </p>
+    </tp:docstring>
+
+    <tp:mapping name="Active_Policies_Map">
+      <tp:docstring>
+        A mapping of communication methods (channel types), and their
+        associated policy.
+      </tp:docstring>
+
+      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type">
+        <tp:docstring>
+          The channel interface with the policy.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="(uv)" tp:type="Access_Control" name="Active_Policy">
+        <tp:docstring>
+          The active policy for this channel type.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <property name="SupportedPolicies"
+              tp:name-for-bindings="Supported_Policies" access="read"
+              type="a(asau)" tp:type="Supported_Policy[]">
+      <tp:docstring>
+        The communication policies supported by this connection.
+      </tp:docstring>
+    </property>
+
+    <property name="ActivePolicies" tp:name-for-bindings="Active_Policies"
+              access="read" type="a{s(uv)}" tp:type="Active_Policies_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The active communication policies on this
+        connection. Communication methods that are not in this
+        mapping are considered open.</p>
+
+        <p>For example, to allow incoming calls only from contacts
+          buddy list, and to allow text messages from anyone,
+          the policy would look like this:</p>
+
+        <pre>
+{
+    'org.freedesktop.Telepathy.Channel.Type.Text' : Access_Control_Type_Open,
+    'org.freedesktop.Telepathy.Channel.Type.Call' : Access_Control_Type_Publish_List
+}
+        </pre>
+
+        <p>Changes to this property are signalled by
+          <tp:member-ref>PolicyChanged</tp:member-ref>.</p>
+      </tp:docstring>
+    </property>
+
+    <method name="SetPolicy" tp:name-for-bindings="Set_Policy">
+      <tp:docstring>
+        Set a policy for a communication method (channel
+        type). Depending on the server or protocol, more than one
+        communication method could be bound to the same policy, if
+        calling this method on one channel type changes the policy on
+        another channel type, the <tp:member-ref>PolicyChanged</tp:member-ref>
+        signal that would follow would include all the channel types
+        that have an altered policy.
+      </tp:docstring>
+      <arg name="Channel_Type" direction="in" type="s"
+           tp:type="DBus_Interface">
+        <tp:docstring>
+          The channel type to set the policy for.
+        </tp:docstring>
+      </arg>
+      <arg name="Policy" direction="in" type="(uv)"
+           tp:type="Access_Control">
+        <tp:docstring>
+          The policy to set for this channel.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <signal name="PolicyChanged" tp:name-for-bindings="Policy_Changed">
+      <tp:docstring>
+        <tp:member-ref>ActivePolicies</tp:member-ref> has
+        changed. This occurs when the server unilaterally changed the
+        policy or <tp:member-ref>SetPolicy</tp:member-ref> has been
+        called.
+      </tp:docstring>
+      <arg name="Changed_Policies" type="a{s(uv)}"
+           tp:type="Active_Policies_Map">
+        <tp:docstring>
+          A subset of the active policies that have changed.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:struct name="Supported_Policy" array-name="Supported_Policy_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The communication methods (channel types), and the policies
+        that can be applied to them. This is server and protocol
+        dependant.</p>
+
+        <p>Grouped channel types will always have the same policy applied
+        to them.</p>
+
+        <tp:rationale>
+          Different protocols have different limitations to the
+          granularity of communication policies. One protocol might be
+          able to set a different policy for VoIP calls and text chat,
+          while another protocol might only be able to set one policy
+          to both VoIP and text chat.
+        </tp:rationale>
+      </tp:docstring>
+      <tp:member type="as" tp:type="DBus_Interface[]"
+        name="Chanel_Types">
+        <tp:docstring>
+          A list of channel interfaces that support these policies.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="au" tp:type="Access_Control_Type[]"
+        name="Supported Policies">
+        <tp:docstring>
+          A list of supported policies.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+  </interface>
+</node>
diff --git a/spec/Connection_Interface_Contact_Groups.xml b/spec/Connection_Interface_Contact_Groups.xml
index 87ab7528..5282a827 100644
--- a/spec/Connection_Interface_Contact_Groups.xml
+++ b/spec/Connection_Interface_Contact_Groups.xml
@@ -18,15 +18,63 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups.DRAFT"
-    tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"/>
-    <tp:added version="0.19.6">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList"/>
+    <tp:added version="0.21.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections in which contacts can be placed in
         user-defined groups.</p>
+
+      <p>The most basic functionality of this interface is to list and monitor
+        a contact's set of groups. To do this, use the
+        <tp:member-ref>GroupsChanged</tp:member-ref> signal, and the
+        <tp:token-ref>groups</tp:token-ref> contact attribute (this should
+        usually be done by connecting to the GroupsChanged signal, then
+        calling <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.ContactList"
+          >GetContactListAttributes</tp:dbus-ref> with this interface
+        included in the Interfaces argument). Simple user interfaces can
+        limit themselves to displaying that information, and ignore the rest
+        of this interface: to ensure that this works,
+        <tp:member-ref>GroupsChanged</tp:member-ref> is emitted for every
+        change, even if that change could be inferred from another signal
+        such as <tp:member-ref>GroupsRemoved</tp:member-ref>.</p>
+
+      <p>Looking at contacts' lists of groups is sufficient to present a
+        user interface resembling XMPP's data model, in which groups behave
+        like tags applied to contacts, and so an empty group cannot exist
+        or is not interesting. However, some protocols model groups as
+        objects in their own right. User interfaces may either track
+        the set of groups via the <tp:member-ref>Groups</tp:member-ref>
+        property and the <tp:member-ref>GroupsCreated</tp:member-ref> and
+        <tp:member-ref>GroupsRemoved</tp:member-ref> signals, or ignore
+        this extra information.</p>
+
+      <p>Similarly, in some protocols it is possible to rename a group as
+        a single atomic operation. Simpler user interfaces will
+        see the new name being created, the old name being removed, and the
+        members moving to the new name, via the signals described above.
+        More advanced user interfaces can optionally distinguish between an
+        atomic rename and a create/remove pair, and display renamed groups
+        differently, by monitoring the
+        <tp:member-ref>GroupRenamed</tp:member-ref> signal.</p>
+
+      <p>This interface also provides various methods to manipulate
+        user-defined groups, which can be expected to work if
+        <tp:member-ref>GroupStorage</tp:member-ref> is not None.</p>
+
+      <p>Depending on the protocol, some methods might be implemented by
+        more than one protocol operation; for instance, in a
+        "contact-centric" protocol like XMPP,
+        <tp:member-ref>SetContactGroups</tp:member-ref> is a single
+        protocol operation and <tp:member-ref>SetGroupMembers</tp:member-ref>
+        requires a protocol operation per contact, whereas in a more
+        "group-centric" protocol it might be the other way around. User
+        interfaces SHOULD call whichever method most closely resembles the
+        way in which the user's action was represented in the UI, and
+        let the connection manager deal with the details.</p>
     </tp:docstring>
 
     <property name="DisjointGroups" tp:name-for-bindings="Disjoint_Groups"
@@ -65,6 +113,26 @@
       </tp:docstring>
     </tp:contact-attribute>
 
+    <signal name="GroupsChanged" tp:name-for-bindings="Groups_Changed">
+      <tp:docstring>
+        Emitted when contacts' groups change.
+      </tp:docstring>
+
+      <arg name="Contact" type="au" tp:type="Contact_Handle">
+        <tp:docstring>The relevant contacts.</tp:docstring>
+      </arg>
+
+      <arg name="Added" type="as">
+        <tp:docstring>The names of groups to which the contacts were
+          added.</tp:docstring>
+      </arg>
+
+      <arg name="Removed" type="as">
+        <tp:docstring>The names of groups from which the contacts were
+          removed.</tp:docstring>
+      </arg>
+    </signal>
+
     <property name="Groups" type="as" access="read"
       tp:name-for-bindings="Groups">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -79,11 +147,9 @@
           distinguish between a create/remove pair and a renamed group by
           receiving <tp:member-ref>GroupRenamed</tp:member-ref>.</p>
 
-        <p>This property's value is not meaningful until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this property to be meaningful by calling
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"
-            >RequestContactList</tp:dbus-ref>.</p>
+        <p>This property's value is not meaningful until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> has become Success.</p>
       </tp:docstring>
     </property>
 
@@ -101,7 +167,9 @@
 
     <signal name="GroupRenamed" tp:name-for-bindings="Group_Renamed">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a group is renamed.</p>
+        <p>Emitted when a group is renamed, in protocols where this can
+          be distinguished from group creation, removal and membership
+          changes.</p>
 
         <p>Immediately after this signal is emitted,
           <tp:member-ref>GroupsCreated</tp:member-ref> MUST signal the
@@ -112,7 +180,7 @@
         <tp:rationale>
           <p>Emitting these extra signals, in this order, means that clients
             that are interested in the set of groups that exist (but treat a
-            rename and a create/remove pair identically) to ignore the
+            rename and a create/remove pair identically) can ignore the
             GroupRenamed signal entirely.</p>
         </tp:rationale>
 
@@ -168,26 +236,6 @@
       </arg>
     </signal>
 
-    <signal name="GroupsChanged" tp:name-for-bindings="Groups_Changed">
-      <tp:docstring>
-        Emitted when contacts' groups change.
-      </tp:docstring>
-
-      <arg name="Contact" type="au" tp:type="Contact_Handle">
-        <tp:docstring>The relevant contacts.</tp:docstring>
-      </arg>
-
-      <arg name="Added" type="as">
-        <tp:docstring>The names of groups to which the contacts were
-          added.</tp:docstring>
-      </arg>
-
-      <arg name="Removed" type="as">
-        <tp:docstring>The names of groups from which the contacts were
-          removed.</tp:docstring>
-      </arg>
-    </signal>
-
     <method name="SetContactGroups" tp:name-for-bindings="Set_Contact_Groups">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Add the given contact to the given groups (creating new groups
@@ -213,6 +261,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Contact" type="u" tp:type="Contact_Handle" direction="in">
@@ -239,6 +295,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -265,6 +322,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -286,6 +351,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -306,6 +372,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -326,6 +400,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -341,6 +416,14 @@
         <p>Any <tp:member-ref>GroupsChanged</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -366,6 +449,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -378,6 +462,14 @@
         <p>Any <tp:member-ref>GroupsChanged</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -393,6 +485,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -412,6 +505,14 @@
         <p>Any <tp:member-ref>GroupRenamed</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Old_Name" type="s" direction="in">
@@ -439,6 +540,7 @@
           <tp:docstring>Raised if there is already a group with the new
             name.</tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Contact_List.xml b/spec/Connection_Interface_Contact_List.xml
index 9db86aa2..d602c19f 100644
--- a/spec/Connection_Interface_Contact_List.xml
+++ b/spec/Connection_Interface_Contact_List.xml
@@ -18,10 +18,9 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"
-    tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:added version="0.19.8">(draft 2)</tp:added>
+    <tp:added version="0.21.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections that have any concept of a list of
@@ -35,7 +34,7 @@
         <p>In some protocols (like link-local XMPP), while there might not be
           any server or roster, it's possible to list "nearby" contacts.</p>
 
-        <p>In Telepathy 0.18 and older, we represented contact lists as a
+        <p>In Telepathy 0.20 and older, we represented contact lists as a
           collection of <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Type"
             >ContactList</tp:dbus-ref> channels. This is remarkably difficult to
@@ -46,87 +45,115 @@
       </tp:rationale>
 
       <p>The list of contacts is not exposed as a D-Bus property; it can be
-        fetched using <tp:member-ref>RequestContactList</tp:member-ref>.
+        fetched using <tp:member-ref>GetContactListAttributes</tp:member-ref>.
       </p>
 
       <tp:rationale>
         <p>In some protocols, such as XMPP, the contact list may not be
           available immediately. The
-          <tp:member-ref>RequestContactList</tp:member-ref> method
-          will wait until the contact list is available before returning.
+          <tp:member-ref>GetContactListAttributes</tp:member-ref> method
+          will fail until the contact list is available.
           Using a method also allows extra attributes to be retrieved at
           the same time.</p>
       </tp:rationale>
     </tp:docstring>
 
-    <method name="RequestContactList"
-      tp:name-for-bindings="Request_Contact_List">
-      <tp:changed version="0.19.8">(in draft: renamed from
-        GetContactListAttributes)</tp:changed>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Return some contact attributes for a list of contacts somehow
-          associated with the user.</p>
+    <tp:enum name="Contact_List_State" type="u">
+      <tp:docstring>
+        The progress made in retrieving the contact list.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring>The connection has not started to retrieve the contact
+          list. If <tp:member-ref>GetContactListAttributes</tp:member-ref> is
+          called in this state, it will raise NotYet.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Waiting" value="1">
+        <tp:docstring>The connection has started to retrieve the contact
+          list, but has not yet succeeded or failed.
+          If <tp:member-ref>GetContactListAttributes</tp:member-ref> is called
+          in this state, it will raise NotYet.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Failure" value="2">
+        <tp:docstring>
+          <p>The connection has tried and failed to retrieve the contact
+            list. If <tp:member-ref>GetContactListAttributes</tp:member-ref>
+            is called in this state, it will immediately raise an error
+            indicating the reason for failure.</p>
+
+          <p>The connection manager SHOULD try again to obtain the contact
+            list, if appropriate for the protocol. If it succeeds later,
+            the <tp:member-ref>ContactListState</tp:member-ref> MUST advance
+            to Success.</p>
+        </tp:docstring>
+      </tp:enumvalue>
 
-        <p>This definition is deliberately vague: in practice, most user
-          interfaces should display some subset of this list, by filtering it
-          by some contact attributes (for instance, displaying all contacts
-          whose "subscribe" attribute is Yes is expected to be a common case).
-          This list MAY contain any contacts whatsoever, but MUST contain
-          at least the following:</p>
+      <tp:enumvalue suffix="Success" value="3">
+        <tp:docstring>The connection has successfully retrieved the contact
+          list. If <tp:member-ref>GetContactListAttributes</tp:member-ref>
+          is called in this state, it will return successfully.</tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="ContactListState" tp:name-for-bindings="Contact_List_State"
+      type="u" tp:type="Contact_List_State" access="read">
+      <tp:docstring>
+        The progress made in retrieving the contact list.
+        Change notification is via
+        <tp:member-ref>ContactListStateChanged</tp:member-ref>.
+      </tp:docstring>
+    </property>
+
+    <signal name="ContactListStateChanged"
+      tp:name-for-bindings="Contact_List_State_Changed">
+      <tp:docstring>
+        Emitted when <tp:member-ref>ContactListState</tp:member-ref>
+        changes.
+      </tp:docstring>
+
+      <arg name="Contact_List_State" type="u" tp:type="Contact_List_State">
+        <tp:docstring>
+          The new value of <tp:member-ref>ContactListState</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="GetContactListAttributes"
+      tp:name-for-bindings="Get_Contact_List_Attributes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Return some contact attributes for a list of contacts
+          associated with the user. This list MUST include at least:</p>
 
         <ul>
-          <li>all contacts whose "subscribe" attribute is Ask or Yes</li>
-          <li>all contacts whose "publish" attribute is Ask or Yes</li>
-          <li>all contacts with a persistently-stored stored alias, if
-            supported</li>
-          <li>all contacts in user-defined contact groups, if supported</li>
+          <li>all contacts whose <tp:token-ref>subscribe</tp:token-ref>
+            attribute is not No</li>
+          <li>all contacts whose <tp:token-ref>publish</tp:token-ref>
+            attribute is not No</li>
         </ul>
 
-        <p>This list does not need to contain every visible contact: for
-          instance, contacts seen in XMPP or IRC chatrooms SHOULD NOT appear
-          here. Blocked contacts SHOULD NOT appear here either, unless they
-          are still stored in a persistent roster/contact list as well as
-          being blocked.</p>
+        <p>but MAY contain other contacts.</p>
 
         <tp:rationale>
-          <p>This is basically the union of the historical <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type"
-              >ContactList</tp:dbus-ref> subscribe, publish and stored
-            channels.</p>
-
-          <p>For example, XMPP, it's the roster; on link-local XMPP, it's the
-            set of visible users on the local network; on MSN, it's the union
-            of the forward and reverse buddy lists.</p>
-
-          <p>An easy way for an application to display a contact list is to
-            call this method with at least this interface in the Interfaces
-            argument, then check which subset of contacts should be displayed
-            (perhaps based on their subscribe attribute, for instance) and display
-            them. Any additional information required to display the contact
-            list, like aliases or presence, can be retrieved at the same
-            time.</p>
-
-          <p>In practice, most user interfaces for the contact list will
-            usually display a large proportion of this list
-            (for instance, most contacts on the contact list will usually
-            have subscribe=Yes in practice, so contact lists that display
-            subscribe=Yes contacts need to display almost the entire list),
-            so the overhead of returning information about too many contacts
-            is small.</p>
+          <p>For instance, on XMPP, all contacts on the roster would appear
+            here even if they have subscription="none", unless there's
+            reason to believe the user does not want to see them (such as
+            having been blocked).</p>
         </tp:rationale>
 
-        <p>This method SHOULD NOT return before the contact list has been
-          retrieved, on protocols where this is possible. As a result,
-          clients SHOULD use a longer-than-default timeout for this method
-          call, since retrieving the contact list can take a significant
-          time on some servers.</p>
+        <p>This list does not need to contain every visible contact: for
+          instance, contacts seen in XMPP or IRC chatrooms SHOULD NOT appear
+          here. Blocked contacts SHOULD NOT appear here, unless they still
+          have a non-<tt>No</tt> <tp:token-ref>subscribe</tp:token-ref> or
+          <tp:token-ref>publish</tp:token-ref> attribute
+          for some reason.</p>
 
         <tp:rationale>
-          <p>This makes it possible for clients to wait for the contact list.
-            For instance, on XMPP this method shouldn't return until the
-            roster has been retrieved, which is an asynchronous process.
-            However, on link-local XMPP you can't know when you have the
-            complete list, so this method would have to return immediately.</p>
+          <p>It's reasonable to assume that blocked contacts should not be
+            visible to the user unless they specifically go looking for them,
+            at least in protocols like XMPP where blocking a contact
+            suppresses presence.</p>
         </tp:rationale>
       </tp:docstring>
 
@@ -150,12 +177,6 @@
             Equivalent to the corresponding argument to <tp:dbus-ref
               namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
               >GetContactAttributes</tp:dbus-ref>.</p>
-
-          <p><em>FIXME: if we do distributed refcounting, we should probably
-              rename this to 'Reference' and implement handle-refcounting
-              semantics first? On the other hand, if we make handles persist
-              for the lifetime of the connection, we can just remove this
-              parameter.</em></p>
         </tp:docstring>
       </arg>
 
@@ -171,31 +192,64 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+            <p>The <tp:member-ref>ContactListState</tp:member-ref> is
+              None or Waiting. In particular, this error is raised if the
+              <tp:dbus-ref namespace="ofdT.Connection">Status</tp:dbus-ref>
+              is not yet Connection_Status_Connected.</p>
+          </tp:docstring>
+        </tp:error>
       </tp:possible-errors>
     </method>
 
-    <tp:enum name="Presence_State" type="u">
+    <tp:enum name="Subscription_State" type="u">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A tristate indicating whether presence subscription is denied,
+        <p>An enumeration indicating whether presence subscription is denied,
           denied but pending permission, or allowed. The exact semantics
-          vary according to where this type is used.</p>
+          vary according to where this type is used: see the
+          <tp:token-ref>subscribe</tp:token-ref> and
+          <tp:token-ref>publish</tp:token-ref> contact attributes for
+          details.</p>
       </tp:docstring>
 
-      <tp:enumvalue suffix="No" value="0">
-        <tp:docstring>Presence information cannot be seen.</tp:docstring>
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring>The presence subscription state is
+          unknown.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="No" value="1">
+        <tp:docstring>Presence information cannot be seen, and either the
+          subscription state Removed_Remotely does not apply, or it is
+          not known whether that state applies.
+        </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Ask" value="1">
-        <tp:docstring>Presence information cannot be seen, but permission
-          to see presence information has been requested.</tp:docstring>
+
+      <tp:enumvalue suffix="Removed_Remotely" value="2">
+        <tp:docstring>Presence information cannot be seen because the
+          remote contact took action: either the local user's request to
+          see the remote contact's presence was denied, or the remote
+          contact requested to see the local user's presence but then
+          cancelled their request.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Ask" value="3">
+        <tp:docstring>Presence information cannot be seen. Permission
+          to see presence information has been requested, and the request
+          has not yet been declined or accepted.</tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Yes" value="2">
+
+      <tp:enumvalue suffix="Yes" value="4">
         <tp:docstring>Presence information can be seen.</tp:docstring>
       </tp:enumvalue>
     </tp:enum>
 
     <tp:contact-attribute name="subscribe"
-      type="u" tp:type="Presence_State">
+      type="u" tp:type="Subscription_State">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If this attribute on a contact is Yes, this connection can
           expect to receive their presence, along with any other information
@@ -207,7 +261,7 @@
             the local user's buddy list" in ICQ, for example.</p>
         </tp:rationale>
 
-        <p>If this attribute is No or Ask, the local user cannot generally
+        <p>If this attribute is not Yes, the local user cannot generally
           expect to receive presence from this contact. Their presence status
           as returned by <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.SimplePresence">GetPresences</tp:dbus-ref>
@@ -229,18 +283,30 @@
             asked during the current session will ever have Ask status.</p>
         </tp:rationale>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>If this attribute is Removed_Remotely, this indicates that the
+          local user has asked to receive the contact's presence at some time,
+          but the remote contact has rejected that request, and a local
+          user interface has not yet acknowledged this. It is
+          implementation-dependent whether contacts' subscribe attributes can
+          remain set to Removed_Remotely, or are reset to No, when the
+          connection disconnects.</p>
+
+        <p>After notifying the user, user interfaces MAY acknowledge a change
+          to <tt>subscribe</tt>=Removed_Remotely by calling either
+          <tp:member-ref>Unsubscribe</tp:member-ref> or
+          <tp:member-ref>RemoveContacts</tp:member-ref>, which will set
+          <tt>subscribe</tt> to No (and perhaps remove the contact). This
+          allows user interfaces to detect that the user has been notified
+          about the rejected request.</p>
+
+        <p>This attribute's value will be Unknown or omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
     <tp:contact-attribute name="publish"
-      type="u" tp:type="Presence_State">
+      type="u" tp:type="Subscription_State">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If this attribute on a contact is Yes, the local user's presence
           is published to that contact, along with any other information that
@@ -254,12 +320,12 @@
             the contact's buddy list" in ICQ, for example.</p>
         </tp:rationale>
 
-        <p>If this attribute is No or Ask, the
+        <p>If this attribute is not Yes, the
           local user's presence is not published to that contact; however,
           if it is Ask, the contact has requested that the local user's
           presence is made available to them.</p>
 
-        <p>It is implementation-dependent whether contacts' publish
+        <p>It is implementation-dependent whether contacts' <tt>publish</tt>
           attributes can remain set to Ask, or are reset to No, when the
           connection disconnects.</p>
 
@@ -270,21 +336,32 @@
             during the current session will ever have Ask status.</p>
         </tp:rationale>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>If this attribute is Removed_Remotely, this indicates that the
+          remote contact has asked to receive the user's presence at some time,
+          but has then cancelled that request before a response was given by
+          the local user. User interfaces MAY reset <tt>publish</tt> from
+          Removed_Remotely to No, by calling either
+          <tp:member-ref>Unpublish</tp:member-ref> or
+          <tp:member-ref>RemoveContacts</tp:member-ref>.</p>
+
+        <p>If multiple factors affect whether a contact can receive the local
+          user's presence, this attribute SHOULD reflect the overall
+          result. For instance, an XMPP contact with subscription="to" or
+          subscription="both", but who has been blocked via
+          <a href="http://xmpp.org/extensions/xep-0016.html">XEP-0016 Privacy
+            Lists</a>, SHOULD have publish=No.</p>
+
+        <p>This attribute's value will be Unknown or omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
     <tp:contact-attribute name="publish-request" type="s">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If the "publish" attribute is Ask, an optional message that was
-          sent by the contact asking to receive the local user's presence;
-          omitted if none was given.</p>
+        <p>If the <tp:token-ref>publish</tp:token-ref> attribute is Ask, an
+          optional message that was sent by the contact asking to receive the
+          local user's presence; omitted if none was given.</p>
 
         <tp:rationale>
           <p>If the contact asking to receive our presence is also using
@@ -294,17 +371,14 @@
 
         <p>Otherwise, this SHOULD be omitted.</p>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received. Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>This attribute will also be omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
-    <property name="SubscriptionsPersist"
-      tp:name-for-bindings="Subscriptions_Persist" type="b" access="read">
+    <property name="ContactListPersists"
+      tp:name-for-bindings="Contact_List_Persists" type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, presence subscriptions (in both directions) on this
           connection are stored by the server or other infrastructure.</p>
@@ -323,17 +397,17 @@
             presence from everyone else) so nothing is ever stored.</p>
         </tp:rationale>
 
-        <p>If <tp:member-ref>CanChangeSubscriptions</tp:member-ref>
+        <p>If <tp:member-ref>CanChangeContactList</tp:member-ref>
           is true, Telepathy clients (e.g. user interfaces or address books)
           MAY keep a record of permission to publish and requests to subscribe
           locally, and attempt to restore it for each Connection. If
-          SubscriptionsPersist is false, clients MAY do this for all contacts;
-          if SubscriptionsPersist is true, clients SHOULD NOT change the state
+          ContactListPersists is false, clients MAY do this for all contacts;
+          if ContactListPersists is true, clients SHOULD NOT change the state
           of contacts that were not changed locally.</p>
 
         <tp:rationale>
-          <p>In SIMPLE (SIP), SubscriptionsPersist is false, but
-            CanChangeSubscriptions is true. Presence will not be received
+          <p>In SIMPLE (SIP), ContactListPersists is false, but
+            CanChangeContactList is true. Presence will not be received
             unless clients renew any subscriptions they have for each
             connection, in the way described. There is no server-side storage,
             so clients have no alternative but to maintain independent contact
@@ -359,10 +433,45 @@
     </property>
 
     <tp:enum name="Contact_Metadata_Storage_Type" type="u">
-      <tp:docstring>
-        Values of this enumeration indicate the extent to which metadata
-        such as aliases and group memberships can be stored for the contacts
-        on a particular connection.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Values of this enumeration indicate the extent to which metadata
+          such as aliases and group memberships can be stored for the contacts
+          on a particular connection.</p>
+
+        <p>On some protocols, certain metadata (for instance, contact aliases)
+          can only be stored for contacts on the contact list, or contacts
+          with a particular contact list state.</p>
+
+        <p>To make it easier to deal with such protocols, if clients set
+          metadata on a contact who is not in the required state, the
+          Connection MUST cache the metadata for the duration of the session.
+          If clients request the attributes of that contact after the
+          appropriate "set" method has returned successfully, the Connection
+          MUST return the new (cached) value.</p>
+
+        <p>If the contact is later placed in the required state to store
+          metadata (for instance, if subscription to the contact's presence
+          is requested, on a protocol like MSN where the alias has storage type
+          Subscribed_Or_Pending), the connection MUST store the cached
+          metadata at that time.</p>
+
+        <tp:rationale>
+          <p>If the Connection didn't cache changes in this way, a client
+            intending to change the alias on MSN would have to wait until
+            the server acknowledged the subscription request; in the meantime,
+            other clients would still display the old alias.</p>
+        </tp:rationale>
+
+        <p>The only exception to that general rule is that if the Connection
+          cannot store particular metadata at all (i.e. the
+          storage type is None), it MUST reject attempts to set it.</p>
+
+        <tp:rationale>
+          <p>If the implementation knows that metadata can't be stored at
+            all, it's useful to report that, which can be done
+            synchronously. In general, user interfaces should detect
+            storage type None and not display editing controls at all.</p>
+        </tp:rationale>
       </tp:docstring>
 
       <tp:enumvalue suffix="None" value="0">
@@ -391,22 +500,6 @@
           <tp:rationale>
             <p>Contact aliases and groups on MSN have this behaviour.</p>
           </tp:rationale>
-
-          <p>If this type of metadata is set on a contact with subscribe=No,
-            the Connection MUST cache it until disconnected, and return it
-            if requested. If subscription to the contact's presence is
-            subsequently requested, making it possible to store this metadata,
-            the Connection MUST store the cached value at that time.</p>
-
-          <tp:rationale>
-            <p>This supports the recommended calling pattern for adding a
-              new contact, in which alias and groups are set (without
-              necessarily waiting for a reply) before requesting the
-              contact's presence. Until the subscription request is
-              processed by the server, the alias and groups will be cached
-              in memory; when the subscription request has been processed,
-              the connection manager will store the metadata on the server.</p>
-          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -419,19 +512,6 @@
             <p>No service with this behaviour is currently known, but it's a
               stricter form of Subscribed_Or_Pending.</p>
           </tp:rationale>
-
-          <p>If this type of metadata is set on a contact with subscribe != Yes,
-            the Connection MUST cache it until disconnected, and return it
-            if requested. If subscription to the contact's presence is
-            subsequently allowed, making it possible to store this metadata,
-            the Connection MUST store the cached value at that time.</p>
-
-          <tp:rationale>
-            <p>The same rationale applies as for Subscribed_Or_Pending,
-              except that metadata must be stored until the subscription
-              request is not only processed by the server, but also allowed
-              by the remote user.</p>
-          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -455,13 +535,13 @@
         A single contact's subscribe, publish and publish-request attributes.
       </tp:docstring>
 
-      <tp:member name="Subscribe" type="u" tp:type="Presence_State">
+      <tp:member name="Subscribe" type="u" tp:type="Subscription_State">
         <tp:docstring>
           The new value of the contact's "subscribe" attribute.
         </tp:docstring>
       </tp:member>
 
-      <tp:member name="Publish" type="u" tp:type="Presence_State">
+      <tp:member name="Publish" type="u" tp:type="Subscription_State">
         <tp:docstring>
           The new value of the contact's "publish" attribute.
         </tp:docstring>
@@ -500,19 +580,32 @@
         <p>Emitted when the contact list becomes available, when contacts'
           basic stored properties change, when new contacts are added to the
           list that would be returned by
-          <tp:member-ref>RequestContactList</tp:member-ref>,
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>,
           or when contacts are removed from that list.</p>
 
         <tp:rationale>
           <p>This provides change notification for that list, and for
-            contacts' "subscribe", "publish" and
-            "publish-request" attributes.</p>
+            contacts' <tp:token-ref>subscribe</tp:token-ref>,
+            <tp:token-ref>publish</tp:token-ref> and
+            <tp:token-ref>publish-request</tp:token-ref> attributes.</p>
+        </tp:rationale>
+
+        <p>Connection managers SHOULD also emit this signal when a contact
+          requests that the user's presence is published to them, even if
+          that contact's <tp:token>publish</tp:token> attribute is already
+          Ask and the <tp:token>publish-request</tp:token> has not changed.</p>
+
+        <tp:rationale>
+          <p>If the same contact sends 10 identical requests, 10 identical
+            signals should be emitted.</p>
         </tp:rationale>
       </tp:docstring>
 
       <arg type="a{u(uus)}" name="Changes" tp:type="Contact_Subscription_Map">
         <tp:docstring>
-          The new subscribe, publish and publish-request attributes of all the
+          The new <tp:token-ref>subscribe</tp:token-ref>,
+            <tp:token-ref>publish</tp:token-ref> and
+            <tp:token-ref>publish-request</tp:token-ref> attributes of all the
           contacts that have been added, and all the contacts for which those
           attributes have changed.
         </tp:docstring>
@@ -522,15 +615,15 @@
         <tp:docstring>
           The contacts that have been removed from the list that would be
           returned by
-          <tp:member-ref>RequestContactList</tp:member-ref>.
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.
           This also implies that they have subscribe = No and publish = No;
           contacts MUST NOT be listed both here and in Changes.
         </tp:docstring>
       </arg>
     </signal>
 
-    <property name="CanChangeSubscriptions" type="b" access="read"
-      tp:name-for-bindings="Can_Change_Subscriptions">
+    <property name="CanChangeContactList" type="b" access="read"
+      tp:name-for-bindings="Can_Change_Contact_List">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, presence subscription and publication can be changed
           using the
@@ -590,10 +683,10 @@
           request, with the given message, if allowed by the underlying
           protocol.</p>
 
-        <p>For contacts with subscribe=No, this method SHOULD request that
-          the contact allows the local user to subscribe to their presence;
-          in general, this will change their publish attribute from No
-          to Ask (although it could change directly from No to Yes in some
+        <p>For contacts with subscribe=No or subscribe=Rejected, this method
+          SHOULD request that the contact allows the local user to subscribe
+          to their presence; in general, this will change their publish
+          attribute to Ask (although it could change directly to Yes in some
           situations).</p>
 
         <p>Any state changes that immediately result from this request MUST
@@ -606,9 +699,20 @@
         </tp:rationale>
 
         <p>If the remote contact accepts the request, their subscribe
-          attribute will later change from Ask to Yes; if they explicitly
-          reject the request (in protocols that allow this), their subscribe
-          attribute will later change from Ask to No.</p>
+          attribute will later change from Ask to Yes.</p>
+
+        <p>If the remote contact explicitly rejects the request (in protocols
+          that allow this), their subscribe attribute will later change from
+          Ask to Rejected.</p>
+
+        <p>If the subscription request is cancelled by the local user, the
+          contact's subscribe attribute will change from Ask to No.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -643,10 +747,16 @@
         <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
         <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
+          </tp:docstring>
+        </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -714,6 +824,12 @@
           <p>This makes it easy for user interfaces to see what practical
             effect this method had.</p>
         </tp:rationale>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -730,7 +846,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -745,7 +867,7 @@
         <p>If possible, this method SHOULD set the contacts' subscribe and
           publish attributes to No, remove any stored aliases for those
           contacts, and remove the contacts from the result of
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
 
         <p>This method SHOULD succeed even if it was not possible to carry out
           the request entirely or for all contacts (for instance, if there is an
@@ -764,6 +886,12 @@
             contact list's state), then consult its local cache of the
             contact list's state to see whether the contact is still there.</p>
         </tp:rationale>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -780,7 +908,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -801,6 +935,12 @@
           entirely or for all contacts; however, all signals that
           immediately result from this method call MUST be emitted before it
           returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -817,7 +957,7 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -838,6 +978,12 @@
           entirely or for all contacts; however, all signals that
           immediately result from this method call MUST be emitted before it
           returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -854,7 +1000,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
diff --git a/spec/Connection_Interface_Power_Saving.xml b/spec/Connection_Interface_Power_Saving.xml
new file mode 100644
index 00000000..ae82d2fa
--- /dev/null
+++ b/spec/Connection_Interface_Power_Saving.xml
@@ -0,0 +1,110 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Power_Saving"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"
+  >
+  <tp:copyright> Copyright (C) 2007 Collabora Limited </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface
+    name="org.freedesktop.Telepathy.Connection.Interface.PowerSaving.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.19.12"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Some protocols support mechanisms for reducing bandwidth usage—and
+        hence power usage, on mobile devices—when the user is not directly
+        interacting with their IM client. For instance, Google Talk's XMPP
+        server supports queueing incoming presence updates at the client's
+        instruction; the client can instruct the server to deliver all
+        outstanding presence updates at a later time. This interface may be
+        used to instruct the connection manager to enable and disable such
+        protocol-level features when a screensaver is activated, the device
+        screen is locked, and so on, by calling the
+        <tp:member-ref>SetPowerSaving</tp:member-ref> method.</p>
+
+      <p>Enabling power saving SHOULD NOT change behaviour in any way
+        that is noticable to a user not actively interacting with their client.
+        For example, delaying presence updates somewhat is unlikely to be
+        noticed by a user not staring at their device waiting for a contact to
+        come online; on the other hand, requesting that the server queue
+        incoming messages would be noticable by the user, so is not an
+        acceptable effect of calling
+        <tp:member-ref>SetPowerSaving</tp:member-ref>.</p>
+    </tp:docstring>
+
+    <method name="SetPowerSaving" tp:name-for-bindings="Set_Power_Saving">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Turn power saving mode on or off.</p>
+
+        <tp:rationale>
+          <p>Depending on the device's activity level, the
+            connection can have its power saving mode turned on or off.</p>
+        </tp:rationale>
+
+        <p>Errors raised by this method indicate that power saving could not be
+          enabled, which SHOULD NOT generally be treated as fatal.</p>
+
+        <tp:rationale>
+          If the CM cannot switch modes, either because of the
+          protocol (<code>NotImplemented</code>), or because of the service
+          (<code>NotAvailable</code>), Mission Control (or whoever manages this)
+          should be made aware. The error could be ignored or, in the extreme,
+          be fascist and disconnect the account.
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Activate" type="b">
+        <tp:docstring>
+          <code>True</code> if protocol-level power saving features should be
+          activated; <code>False</code> if they should be de-activated.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The current connection has no power saving features.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="PowerSavingActive" type="b" access="read"
+              tp:name-for-bindings="Power_Saving_Active">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p><code>True</code> if protocol-level power saving features are
+          currently activated. This property can be changed using the
+          <tp:member-ref>SetPowerSaving</tp:member-ref> method; change
+          notifications is via the
+          <tp:member-ref>PowerSavingChanged</tp:member-ref> signal.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="PowerSavingChanged"
+            tp:name-for-bindings="Power_Saving_Changed">
+      <arg name="Active" type="b">
+        <tp:docstring>
+          The new state of the power saving feature.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The <tp:member-ref>PowerSavingActive</tp:member-ref>
+        property changed.
+      </tp:docstring>
+    </signal>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Resources.xml b/spec/Connection_Interface_Resources.xml
new file mode 100644
index 00000000..716089cd
--- /dev/null
+++ b/spec/Connection_Interface_Resources.xml
@@ -0,0 +1,212 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Resources"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.Resources.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.21.1">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface on connections to show contact attributes for
+        specific resources of a contact, if the protocol supports
+        multiple resources. Resources are most common in XMPP, hence the
+        name of this interface, but they are also present in MSN, where
+        they are called points of presence.</p>
+
+      <p>When a client requests some attribute of a contact using its
+        handle on the connection, the CM uses an algorithm to choose the
+        most appropriate resource for the job. If there is only one
+        resource, then the choice is obvious. If, however, there is more
+        than one resource connected at any one time, the CM either
+        aggregates all appropriate information to return (in the case of
+        capabilities), or chooses one specific resource (in the case of
+        presence).</p>
+
+      <p>Resources in XMPP have names, and it can be extremely useful
+        for the user to be able to know which resources of a contact are
+        online, providing the names are human-readable. Before now,
+        resources have not been exposed in Telepathy, but this interface
+        attempts to change this.</p>
+
+      <p>When using this interface, it is a little like using the
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface"
+        >Contacts</tp:dbus-ref> interface, but only resource-specific
+        attributes are ever returned. The resource-specific contact
+        attributes are decided on by the CM, but XMPP's are listed
+        below:</p>
+
+      <ul>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence/presence</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities/capabilities</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ClientTypes/client-types</tp:dbus-ref></li>
+      </ul>
+
+    </tp:docstring>
+
+    <method name="GetResources" tp:name-for-bindings="Get_Resources">
+      <tp:docstring>
+        Return the resource information of the given contacts. If any
+        of the contact attributes for specific resources of the given
+        contacts' are not known return immediately without waiting for
+        a reply.
+      </tp:docstring>
+
+      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          The contacts whose resource attributes should be returned.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Resources" type="a{ua{sa{sv}}}"
+        tp:type="Resources_Attributes_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The contacts' resources and the contact attributes specific
+            to each resource. If contact attributes are not immediately
+            known, the behaviour is defined by the interface; the
+            attribute should either be omitted from the result or
+            replaced with a default value.</p>
+
+          <p>For every contact handle passed into this method, it is
+            guaranteed that there will be a key in the returned map
+            that corresponds to said handle. If there is no information
+            regarding the contact the resource information map will be
+            empty.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+      </tp:possible-errors>
+    </method>
+
+    <tp:enum name="Resources_Human_Readability" type="u">
+      <tp:enumvalue suffix="Never" value="0">
+        <tp:docstring>
+          The resource string is never human-readable.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Maybe" value="1">
+        <tp:docstring>
+          The resource string might be human-readable.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="ResourcesHumanReadable" type="u" access="read"
+      tp:type="Resources_Human_Readability"
+      tp:name-for-bindings="Resources_Human_Readable">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Whether the resources returned from <tp:member-ref>GetResources</tp:member-ref>
+          are human readable or not.</p>
+
+        <p>If the connection manager knows that all resource names are
+          automatically generated, then the resource strings mean
+          nothing to the user. Showing these strings in the UI would
+          be confusing, so by setting this to
+          Resources_Human_Readability_Never, the UI is advised not to
+          show resources.</p>
+
+        <p>If on the other hand, all resources are set to nice names
+          (such as "office" or "home") then it might be wise to expose
+          these strings in the UI, so this property would be set to
+          Resources_Human_Readability_Maybe. This is the case in XMPP --
+          most resources are set in a way that the user can deduce some
+          information from them. The absence of an Always enum value is
+          because in the case of XMPP, the resource string could be
+          partially human-readable (as on Google Talk, where a resource
+          of "home" is changed by the server to a unique string like
+          "home_1234fdec") or not at all human-readable.</p>
+
+      </tp:docstring>
+    </property>
+
+    <signal name="ResourcesUpdated" tp:name-for-bindings="Resources_Updated">
+      <tp:docstring>
+        Emitted when a contact has a resource added or removed, or any
+        contact attribute for any resource changes.
+      </tp:docstring>
+
+      <arg name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact.
+        </tp:docstring>
+      </arg>
+      <arg name="Resources" tp:type="Resource_Information_Map"
+        type="a{sa{sv}}">
+        <tp:docstring>
+          The contact's resource information. All resource information
+          is given, not just the details which have changed.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:mapping name="Resource_Information_Map">
+      <tp:docstring>
+        A map of a contact's resources to their resource-specific
+        information.
+      </tp:docstring>
+
+      <tp:member name="Key" type="s">
+        <tp:docstring>
+          <p>The name of the resource.</p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Contact_Attributes" type="a{sv}"
+        tp:type="Single_Contact_Attributes_Map">
+        <tp:docstring>
+          A map of contact attributes whose data is specific to this
+          resource.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:mapping name="Resources_Attributes_Map">
+      <tp:docstring>Mapping returned by
+        <tp:member-ref>GetResources</tp:member-ref>, representing a
+        collection of Contacts, their resources, and their
+        resource-specific contact attributes.</tp:docstring>
+
+      <tp:member type="u" tp:type="Contact_Handle" name="Contact">
+        <tp:docstring>
+          A contact.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="a{sa{sv}}" tp:type="Resource_Information_Map"
+        name="Resources">
+        <tp:docstring>
+          A map of the contact's resources to their resource-specific
+          information.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:contact-attribute name="resources" type="a{sa{sv}}"
+      tp:type="Resource_Information_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same mapping that would be returned by
+          <tp:member-ref>GetResources</tp:member-ref> for this contact.</p>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Simple_Presence.xml
index 5c7ae978..7788161e 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Simple_Presence.xml
@@ -349,17 +349,95 @@
       </tp:enumvalue>
     </tp:enum>
 
+    <tp:enum name="Access_Control_Type" type="u"
+             array-name="Access_Control_Type_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A type for communication access control. These control
+          policies are used in
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">CommunicationPolicy.DRAFT</tp:dbus-ref>
+          as well as most rich presence interfaces.</p>
+
+        <p>New interfaces should use this type, and NOT
+          <tp:type>Rich_Presence_Access_Control_Type</tp:type>.</p>
+      </tp:docstring>
+      <tp:enumvalue suffix="Whitelist" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Only allow contacts that are in a certain whitelist.</p>
+
+          <p>The associated variant
+            in <tp:type>Access_Control</tp:type> is a list of
+            <tp:type>Contact_Handle</tp:type> representing
+            the whitelist, with signature <code>au</code>.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Publish_List" value="1">
+        <tp:docstring>
+          Allow contacts in the user's 'publish' list. The associated
+          variant in <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Group" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Only allow contacts that are in a certain group.</p>
+
+          <p>The associated variant in <tp:type>Access_Control</tp:type> is a
+            <tp:type>Group_Handle</tp:type> representing the permitted
+            group.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Open" value="3">
+        <tp:docstring>
+          Allow all contacts.  The associated
+          variant in <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Subscribe_Or_Publish_List" value="4">
+        <tp:docstring>
+          Allow all contacts in the user's 'subscribe' or 'publish'
+          list. The associated variant in <tp:type>Access_Control</tp:type> is
+          ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Closed" value="5">
+        <tp:docstring>
+          Forbid all contacts. The associated variant in
+          <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Not_Understood" value="6">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The access control rule is too complex to be represented
+            in the current Telepathy API. The associated variant is
+            meaningless. Setting this mode is never valid; the
+            connection manager MUST raise an error if this is attempted.</p>
+
+          <tp:rationale>
+            XEP-0016 Privacy Lists can easily produce access control
+            mechanisms that can't be expressed in a simpler API. We
+            need to be able to at least indicate that fact.
+          </tp:rationale>
+
+          <p>The associated variant in <tp:type>Access_Control</tp:type> is
+            ignored.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
     <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
-        variant.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A type of access control for Rich_Presence_Access_Control.
+          For most types, the exact access control is given by an associated
+          variant.</p>
 
         <tp:rationale>
-          These are the access control types from XMPP publish/subscribe
-          (XEP-0060).
+          <p>These are the access control types from XMPP publish/subscribe
+          (XEP-0060).</p>
         </tp:rationale>
+
+        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
+          uses this for historical reasons, new interfaces will use
+          <tp:type>Access_Control_Type</tp:type>.</p>
       </tp:docstring>
 
       <tp:enumvalue suffix="Whitelist" value="0">
@@ -389,13 +467,42 @@
       </tp:enumvalue>
     </tp:enum>
 
+    <tp:struct name="Access_Control">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An access control mode for extended presence items like geolocation.
+          This type isn't actually used by the SimplePresence interface, but
+          it's included here so it can be referenced by rich presence
+          interfaces.</p>
+
+        <p>New interfaces should use this type, and NOT
+          <tp:type>Rich_Presence_Access_Control</tp:type>.</p>
+      </tp:docstring>
+
+      <tp:member name="Type" type="u" tp:type="Access_Control_Type">
+        <tp:docstring>
+          The type of access control to apply.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Detail" type="v">
+        <tp:docstring>
+          Any additional information required by the Type. The required
+          type and semantics are defined for each
+          <tp:type>Access_Control_Type</tp:type>.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
     <tp:struct name="Rich_Presence_Access_Control">
-      <tp:docstring>
-        An access control mode for extended presence items like geolocation.
-        This type isn't actually used by the SimplePresence interface, but
-        it's included here so it can be referenced by rich presence interfaces
-        such as <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An access control mode for extended presence items like geolocation.
+          This type isn't actually used by the SimplePresence interface, but
+          it's included here so it can be referenced by rich presence interfaces
+          such as <tp:dbus-ref
+                     namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>.</p>
+
+        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
+          uses this for historical reasons, new interfaces will use
+          <tp:type>Access_Control_Type</tp:type>.</p>
       </tp:docstring>
 
       <tp:member name="Type" type="u" tp:type="Rich_Presence_Access_Control_Type">
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 50562c9b..e37fe224 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -216,6 +216,20 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
           Jabber/XMPP (including Google Talk), or <code>tel</code> for
           the <abbr title="Public Switched Telephone Network">PSTN</abbr>.</p>
 
+        <p>A more exhaustive list of addressable vCard fields can be found in
+          the Protocol's Addressing interface's
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableVCardFields</tp:dbus-ref>.</p>
+
+        <p>It is not necessarily valid to interpret contacts' identifiers
+          as values of this vCard field. For instance, telepathy-sofiasip
+          supports contacts whose identifiers are of the form
+          sip:jenny@example.com or tel:8675309, which would not normally
+          both be represented by any single vCard field. Arbitrary
+          handles/identifiers as vCard fields are represented
+          through the Connection's
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Addressing.DRAFT</tp:dbus-ref>
+          contact attributes.</p>
+
         <tp:rationale>
           <p>This is taken from Mission Control profiles as used on Maemo 5.
             One valid use of this field is to answer the question: given a
@@ -225,14 +239,6 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
             protocols that handle x-jabber, then offer the user a list of
             accounts for those protocols and/or the option to create a new
             account for one of those protocols.</p>
-
-          <p>It is not necessarily valid to interpret contacts' identifiers
-            as values of this vCard field. For instance, telepathy-sofiasip
-            supports contacts whose identifiers are of the form
-            sip:jenny@example.com or tel:8675309, which would not normally
-            both be represented by any single vCard field. Representing
-            arbitrary handles/identifiers as vCard fields is a topic for
-            future work.</p>
         </tp:rationale>
 
         <p>Connection managers with a <code>.manager</code> file
@@ -423,6 +429,6 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       </tp:possible-errors>
     </method>
 
-  </interface>
+ </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Protocol_Interface_Addressing.xml b/spec/Protocol_Interface_Addressing.xml
new file mode 100644
index 00000000..3722c3b8
--- /dev/null
+++ b/spec/Protocol_Interface_Addressing.xml
@@ -0,0 +1,300 @@
+<?xml version="1.0" ?>
+<node name="/Protocol_Interface_Addressing"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+      02110-1301, USA.</p>
+  </tp:license>
+
+  <interface
+     name="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT"
+     tp:causes-havoc="experimental">
+    <tp:added version="0.19.12">(as draft)</tp:added>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface for protocols that support multiple forms of
+        addressing contacts, for example through vCard addresses and URIs.</p>
+
+      <p>If the ConnectionManager has a <tt>.manager</tt> file, and it
+        supports this interface, the interface's immutable properties
+        must be represented in the file; the representation is described as
+        part of the documentation for each property.</p>
+
+      <p>For instance, a SIP connection manager might have the
+        following lines in the <tt>.manager</tt> file.</p>
+
+<pre>
+[Protocol sip]
+AddressableVCardFields=tel;x-sip;
+AddressableURISchemes=tel;sip;
+</pre>
+    </tp:docstring>
+
+    <property name="AddressableVCardFields"
+              tp:name-for-bindings="Addressable_VCard_Fields"
+              access="read" type="as">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The vCard fields that can be used to request a contact with
+          normalized to lower case. If the <code>URL</code> vCard
+          field is addressable, a colon, followed by the supported URI
+          schemes will be concatenated.</p>
+
+          <p>For example: <code>["tel", "x-sip"]</code>.</p>
+
+          <p>The <code>url</code> vCard field MUST NOT appear here; see
+            <tp:member-ref>AddressableURISchemes</tp:member-ref> instead.</p>
+
+          <tp:rationale>
+            <p>In practice, protocols have a limited set of URI
+              schemes that make sense to resolve as a contact.</p>
+          </tp:rationale>
+
+        <p>This property should only be used when the connection is
+          offline. When it is connected the addressable fields should be
+          retrieved from the
+          <tp:dbus-ref
+             namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.RequestableChannelClasses</tp:dbus-ref>'s
+             TargetVCardField fixed-property instead.</p>
+
+        <p>Connection managers with a <code>.manager</code> file
+          MUST cache this property in the protocol's section of the
+          <code>.manager</code> file if it is non-empty, using the key
+          <code>AddressableVCardFields</code>. The corresponding value
+          is a list of strings, each followed with a semicolon and in the
+          syntax of the "localestring" type from the Desktop Entry
+          Specification.</p>
+
+        <p>Well-known vCard fields:</p>
+
+        <dl>
+          <dt><code>tel</code></dt>
+          <dd>The TEL vCard field. Used for phone numbers.</dd>
+          <dt><code>x-sip</code></dt>
+          <dd>The X-SIP vCard field. Used for SIP addresses.</dd>
+          <dt><code>x-aim</code></dt>
+          <dd>The X-AIM vCard field. Used for AIM user IDs.</dd>
+          <dt><code>x-icq</code></dt>
+          <dd>The X-ICQ vCard field. Used for ICQ UINs.</dd>
+          <dt><code>x-skype</code></dt>
+          <dd>The X-SKYPE vCard field. Used for Skype user names or
+          telephone numbers. There is also a X-SKYPE-USERNAME field,
+          but for Telepathy purposes, <code>x-skype</code> is preferred</dd>
+          <dt><code>x-groupwise</code></dt>
+          <dd>The X-GROUPWISE vCard field. Used for Groupwise contacts.</dd>
+          <dt><code>x-gadugadu</code></dt>
+          <dd>The X-GADUGADU vCard field. Used for Gadu-Gadu contacts.</dd>
+          <dt><code>x-jabber</code></dt>
+          <dd>The X-JABBER vCard field. Used for XMPP JIDs.</dd>
+          <dt><code>x-msn</code></dt>
+          <dd>The X-MSN vCard field. Used for MSN contacts.</dd>
+          <dt><code>x-yahoo</code></dt>
+          <dd>The X-YAHOO vCard field. Used for Yahoo! IDs.</dd>
+        </dl>
+
+      </tp:docstring>
+    </property>
+
+    <property name="AddressableURISchemes"
+              tp:name-for-bindings="Addressable_URI_Schemes"
+              access="read" type="as">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The URI schemes that are supported by this protocol.</p>
+
+        <p>For example: <code>["tel", "sip"]</code>.</p>
+
+        <p>This property should only be used when the connection is
+          offline. When it is connected the addressable URI schemes should be
+          retrieved from the
+          <tp:dbus-ref
+             namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.RequestableChannelClasses</tp:dbus-ref>'s
+             TargetURIScheme fixed-property instead.</p>
+
+        <p>Connection managers with a <code>.manager</code> file
+          MUST cache this property in the protocol's section of the
+          <code>.manager</code> file if it is non-empty, using the key
+          <code>AddressableURISchemes</code>. The corresponding value
+          is a list of strings, each followed with a semicolon and in the
+          syntax of the "localestring" type from the Desktop Entry
+          Specification.</p>
+
+        <p>Well-known URI schemes:</p>
+
+        <dl>
+          <dt><code>sip</code></dt>
+          <dd>SIP protocol.
+            For example: <code>sip:julien@example.com</code>.</dd>
+          <dt><code>sips</code></dt>
+          <dd>Secure (encrypted) SIP protocol.
+            For example: <code>sips:julien@example.com</code>.</dd>
+          <dt><code>tel</code></dt>
+          <dd>Used for telephone numbers.
+            For example: <code>tel:+12065551234</code>.</dd>
+          <dt><code>xmpp</code></dt>
+          <dd>XMPP protocol.
+            For example: <code>xmpp:julien@example.com</code>.</dd>
+          <dt><code>msnim</code></dt>
+          <dd>For the purposes of
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            and
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            the verb part is ignored, and SHOULD be <code>add</code>; the
+            <code>contact</code> field in the query string is used to
+            identify the contact.
+            For example: <code>msnim:add?contact=julien</code>.</dd>
+          <dt><code>aim</code></dt>
+          <dd>For the purposes of
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            and
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            the verb part is ignored, and SHOULD be <code>addbuddy</code>; the
+            <code>screenname</code> field in the query string is used to
+            identify the contact.
+            For example: <code>aim:addbuddy?screenname=julien</code>.</dd>
+          <dt><code>skype</code></dt>
+          <dd>Skype protocol.
+            For example: <code>skype:julien</code>.</dd>
+          <dt><code>ymsgr</code></dt>
+          <dd>For the purposes of
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            and
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            the verb part is ignored, and SHOULD be <code>addfriend</code>; the
+            query string is used to identify the contact.
+            For example: <code>ymsgr:addfriend?julien</code>.</dd>
+          <dt><code>gg</code></dt>
+          <dd>Gadu-Gadu protocol.
+            For example: <code>gg:julien</code>.</dd>
+        </dl>
+      </tp:docstring>
+    </property>
+
+    <method name="NormalizeVCardAddress"
+      tp:name-for-bindings="Normalize_VCard_Address">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Attempt to normalize the given vCard address. Where possible, this
+          SHOULD return an address that would appear in the
+          <code>org.freedesktop.Telepathy.Connection.Interface.Addressing.DRAFT/addresses</code>
+          attribute for a contact on a connected
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.
+        </p>
+
+        <p>If full normalization requires network activity or is otherwise
+          impossible to do without a <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
+          this method SHOULD perform a best-effort normalization.</p>
+
+        <p>An example would be a vCard TEL field with a formatted
+          number in the form of <code>+1 (206) 555 1234</code>, this would be
+          normalized to <code>+12065551234</code>.</p>
+
+        <p>This method MAY simply raise NotImplemented on some
+        protocols, if it has no use.</p>
+      </tp:docstring>
+
+      <arg direction="in" name="VCard_Field" type="s">
+        <tp:docstring>
+          The vCard field of the address we are normalizing. The
+          field name SHOULD be in lower case, and MUST appear in
+          <tp:member-ref>AddressableVCardFields</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="VCard_Address" type="s">
+        <tp:docstring>
+          The address to normalize.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Normalized_VCard_Address" type="s">
+        <tp:docstring>
+          The vCard address, normalized as much as possible.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The vCard field is not supported (it is not in
+            <tp:member-ref>AddressableVCardFields</tp:member-ref>).
+          </tp:docstring>
+        </tp:error>
+
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The address is syntactically incorrect.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="NormalizeURI"
+      tp:name-for-bindings="Normalize_URI">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Attempt to normalize the given contact URI. Where possible, this
+          SHOULD return an address that would appear in the
+          <code>org.freedesktop.Telepathy.Connection.Interface.Addressing.DRAFT/uris</code>
+          attribute for a contact on a connected
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.
+        </p>
+
+        <p>If full normalization requires network activity or is otherwise
+          impossible to do without a <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
+          this method SHOULD perform a best-effort normalization.</p>
+
+        <p>Example: <code>xmpp:eitan@EXAMPLE.COM</code> would be normalized to
+        <code>xmpp:eitan@example.com</code>.</p>
+
+        <p>This method MAY simply raise NotImplemented on some
+        protocols, if it has no use.</p>
+      </tp:docstring>
+
+      <arg direction="in" name="URI" type="s">
+        <tp:docstring>
+          The URI to normalize. The URI's scheme (i.e. the part before
+          the first colon) MUST appear in
+          <tp:member-ref>AddressableURISchemes</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Normalized_URI" type="s">
+        <tp:docstring>
+          A URI, normalized as much as possible.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The URI scheme is not supported (it is not in
+            <tp:member-ref>AddressableURISchemes</tp:member-ref>).
+          </tp:docstring>
+        </tp:error>
+
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The URI is syntactically incorrect.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+ </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/all.xml b/spec/all.xml
index 0dd70c6f..2709a412 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.19.11.1</tp:version>
+<tp:version>0.21.1</tp:version>
 
 <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>
@@ -33,6 +33,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  </tp:docstring>
  <xi:include href="Connection_Manager.xml"/>
  <xi:include href="Protocol.xml"/>
+ <xi:include href="Protocol_Interface_Addressing.xml"/>
  <xi:include href="Protocol_Interface_Avatars.xml"/>
  <xi:include href="Protocol_Interface_Presence.xml"/>
 
@@ -44,6 +45,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </tp:docstring>
   <xi:include href="Connection.xml"/>
   <xi:include href="Connection_Future.xml"/>
+  <xi:include href="Connection_Interface_Addressing.xml"/>
   <xi:include href="Connection_Interface_Aliasing.xml"/>
   <xi:include href="Connection_Interface_Anonymity.xml"/>
   <xi:include href="Connection_Interface_Avatars.xml"/>
@@ -51,6 +53,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <xi:include href="Connection_Interface_Capabilities.xml"/>
   <xi:include href="Connection_Interface_Cellular.xml"/>
   <xi:include href="Connection_Interface_Client_Types.xml"/>
+  <xi:include href="Connection_Interface_Communication_Policy.xml"/>
   <xi:include href="Connection_Interface_Contact_Capabilities.xml"/>
   <xi:include href="Connection_Interface_Contact_Groups.xml"/>
   <xi:include href="Connection_Interface_Contact_Info.xml"/>
@@ -59,8 +62,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <xi:include href="Connection_Interface_Forwarding.xml"/>
   <xi:include href="Connection_Interface_Location.xml"/>
   <xi:include href="Connection_Interface_Mail_Notification.xml"/>
+  <xi:include href="Connection_Interface_Power_Saving.xml"/>
   <xi:include href="Connection_Interface_Presence.xml"/>
   <xi:include href="Connection_Interface_Renaming.xml"/>
+  <xi:include href="Connection_Interface_Resources.xml"/>
   <xi:include href="Connection_Interface_Requests.xml"/>
   <xi:include href="Connection_Interface_Service_Point.xml"/>
   <xi:include href="Connection_Interface_Simple_Presence.xml"/>
@@ -110,6 +115,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
      depending on its type:
     </p>
    </tp:docstring>
+   <xi:include href="Channel_Interface_Addressing.xml"/>
    <xi:include href="Channel_Interface_Anonymity.xml"/>
    <xi:include href="Channel_Interface_Call_State.xml"/>
    <xi:include href="Channel_Interface_Chat_State.xml"/>
@@ -124,6 +130,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    <xi:include href="Channel_Interface_Messages.xml"/>
    <xi:include href="Channel_Interface_Password.xml"/>
    <xi:include href="Channel_Interface_Room.xml"/>
+   <xi:include href="Channel_Interface_SMS.xml"/>
    <xi:include href="Channel_Interface_Service_Point.xml"/>
    <xi:include href="Channel_Interface_Splittable.xml"/>
    <xi:include href="Channel_Interface_Tube.xml"/>
@@ -174,6 +181,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  <xi:include href="Account.xml"/>
  <xi:include href="Account_Interface_Avatar.xml"/>
  <xi:include href="Account_Interface_Storage.xml"/>
+ <xi:include href="Account_Interface_Minimum_Presence.xml"/>
 </tp:section>
 
 <tp:section name="The Channel Dispatcher">
@@ -185,9 +193,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </p>
  </tp:docstring>
  <xi:include href="Channel_Dispatcher.xml"/>
+ <xi:include href="Channel_Dispatcher_Future.xml"/>
  <xi:include href="Channel_Dispatcher_Interface_Operation_List.xml"/>
  <xi:include href="Channel_Dispatch_Operation.xml"/>
  <xi:include href="Channel_Request.xml"/>
+ <xi:include href="Channel_Request_Future.xml"/>
 </tp:section>
 
 <tp:section name="Clients">
diff --git a/spec/errors.xml b/spec/errors.xml
index e14dacbe..a5368c02 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -293,7 +293,7 @@
     <tp:added version="0.19.11"/>
     <tp:docstring>
       Raised if the length in bytes of the server certificate, or the depth of the
-      sever certificate chain exceed the limits imposed by the crypto
+      server certificate chain exceeds the limits imposed by the crypto
       library.
       <tp:rationale>
         This corresponds to Cert_Limit_Exceeded in the
@@ -483,6 +483,14 @@
     </tp:docstring>
   </tp:error>
 
+  <tp:error name="Not Yet">
+    <tp:added version="0.19.12"/>
+    <tp:docstring>
+      Raised when the requested functionality is not yet available, but is
+      likely to become available after some time has passed.
+    </tp:docstring>
+  </tp:error>
+
   <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/generic-types.xml b/spec/generic-types.xml
index c017ba59..014f8ada 100644
--- a/spec/generic-types.xml
+++ b/spec/generic-types.xml
@@ -195,4 +195,21 @@
     </tp:docstring>
   </tp:simple-type>
 
+  <tp:mapping name="Object_Immutable_Properties_Map"
+    array-name="Object_Immutable_Properties_Map_List">
+    <tp:added version="0.19.12"/>
+    <tp:docstring>A mapping from object path to the immutable properties of
+        the object.</tp:docstring>
+    <tp:member type="o" name="Path">
+      <tp:docstring>
+        The object path of an object
+      </tp:docstring>
+    </tp:member>
+    <tp:member type="a{sv}" name="Immutable_Properties" tp:type="Qualified_Property_Value_Map">
+      <tp:docstring>
+        The immutable properties of the object
+      </tp:docstring>
+    </tp:member>
+  </tp:mapping>
+
 </tp:generic-types>