Update to spec 0.19.12

- NotYet error is generated
- Object_Immutable_Properties_Map is generated
- TP_PROP_CONNECTION_INTERFACE_CELLULAR_OVERRIDE_MESSAGE_SERVICE_CENTRE

24 files changed, 1974 insertions, 171 deletions

diff --git a/spec/Account_Interface_Minimum_Presence.xml b/spec/Account_Interface_Minimum_Presence.xml
new file mode 100644
index 000000000..eb829b824
--- /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/Channel.xml b/spec/Channel.xml
index 897b68353..b1772d7d4 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 000000000..701b42470
--- /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 000000000..494fd7bf0
--- /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_DTMF.xml b/spec/Channel_Interface_DTMF.xml
index bd20f6ed3..c74dd5136 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_SMS.xml b/spec/Channel_Interface_SMS.xml
new file mode 100644
index 000000000..b0dce6647
--- /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_Request_Future.xml b/spec/Channel_Request_Future.xml
new file mode 100644
index 000000000..d75c7e0ce
--- /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 f1d0f0e06..68dc7ffc7 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 1d705c552..7b1202a01 100644
--- a/spec/Channel_Type_Server_TLS_Connection.xml
+++ b/spec/Channel_Type_Server_TLS_Connection.xml
@@ -55,6 +55,16 @@
       </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 544565912..aa2b90345 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 10a16bd69..2cceed170 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_Interface_Requests.xml b/spec/Client_Interface_Requests.xml
index f4c11087d..cfab58de7 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 912edaf4f..01fee8b9f 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_Interface_Addressing.xml b/spec/Connection_Interface_Addressing.xml
new file mode 100644
index 000000000..497c6d0d9
--- /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 bf0f1a9c8..3dc29e329 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_Contact_Groups.xml b/spec/Connection_Interface_Contact_Groups.xml
index 87ab7528c..856dec178 100644
--- a/spec/Connection_Interface_Contact_Groups.xml
+++ b/spec/Connection_Interface_Contact_Groups.xml
@@ -21,7 +21,7 @@
   <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups.DRAFT"
     tp:causes-havoc="experimental">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT3"/>
     <tp:added version="0.19.6">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -79,11 +79,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.DRAFT3"
+            >ContactListState</tp:dbus-ref> has become Success.</p>
       </tp:docstring>
     </property>
 
@@ -213,6 +211,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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Contact" type="u" tp:type="Contact_Handle" direction="in">
@@ -239,6 +245,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 +272,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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -286,6 +301,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 +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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -326,6 +350,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 +366,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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -366,6 +399,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 +412,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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -393,6 +435,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 +455,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.DRAFT3"
+            >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.DRAFT3"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Old_Name" type="s" direction="in">
@@ -439,6 +490,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 9db86aa2c..3366b57e2 100644
--- a/spec/Connection_Interface_Contact_List.xml
+++ b/spec/Connection_Interface_Contact_List.xml
@@ -18,10 +18,10 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT3"
     tp:causes-havoc="experimental">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:added version="0.19.8">(draft 2)</tp:added>
+    <tp:added version="0.19.12">(draft 3)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections that have any concept of a list of
@@ -46,87 +46,119 @@
       </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>
+
+      <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:added version="0.19.12">(in draft 3)</tp:added>
+      <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:added version="0.19.12">(in draft 3)</tp:added>
+      <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>
 
-        <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>
+    <method name="GetContactListAttributes"
+      tp:name-for-bindings="Get_Contact_List_Attributes">
+      <tp:changed version="0.19.12">(semantics changed in draft
+        3)</tp:changed>
+      <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 +182,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 +197,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="Ask" value="1">
-        <tp:docstring>Presence information cannot be seen, but permission
-          to see presence information has been requested.</tp:docstring>
+
+      <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="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="Yes" value="2">
+
+      <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="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 +266,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 +288,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 +325,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 +341,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 +376,15 @@
 
         <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:changed version="0.19.12">(renamed in draft 3)</tp:changed>
       <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 +403,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
@@ -392,11 +472,12 @@
             <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>
+          <p>If this type of metadata is set on a contact with subscribe=No
+            or subscribe=Rejected, 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
@@ -455,13 +536,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 +581,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 +616,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 +684,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 +700,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 +748,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 +825,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 +847,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 +868,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 +887,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 +909,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 +936,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 +958,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 +979,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 +1001,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 000000000..30b25f403
--- /dev/null
+++ b/spec/Connection_Interface_Power_Saving.xml
@@ -0,0 +1,101 @@
+<?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>An interface for telling the connection when to enter and
+      leave power saving mode.</p>
+
+      <p>Power saving mode should be used when the user is not
+        directly interacting with the interface. For example, when
+        the screen saver is active, or when device screen is
+        locked.</p>
+
+      <p>Connection managers should implement this feature in a way
+        that is not noticeable by end users. For example, a protocol
+        might allow server-side blocking presence updates from
+        contacts to reduce network chatter. This would not affect the
+        user, since they are not interacting with their device when it
+        is in power saving mode.</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 it's 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>
+          True when activating power saving, false when deactivating.
+        </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>The current state of power saving. 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/Makefile.am b/spec/Makefile.am
index 4343e06b2..40d58ee8b 100644
--- a/spec/Makefile.am
+++ b/spec/Makefile.am
@@ -1,5 +1,6 @@
 EXTRA_DIST = \
     Account_Interface_Avatar.xml \
+    Account_Interface_Minimum_Presence.xml \
     Account_Interface_Storage.xml \
     Account_Manager.xml \
     Account.xml \
@@ -14,9 +15,11 @@ EXTRA_DIST = \
     Call_Stream_Endpoint.xml \
     Channel_Dispatch_Operation.xml \
     Channel_Dispatcher.xml \
+    Channel_Dispatcher_Future.xml \
     Channel_Dispatcher_Interface_Operation_List.xml \
     Channel_Future.xml \
     Channel_Handler.xml \
+    Channel_Interface_Addressing.xml \
     Channel_Interface_Anonymity.xml \
     Channel_Interface_Call_State.xml \
     Channel_Interface_Chat_State.xml \
@@ -32,10 +35,12 @@ EXTRA_DIST = \
     Channel_Interface_Password.xml \
     Channel_Interface_Room.xml \
     Channel_Interface_Service_Point.xml \
+    Channel_Interface_SMS.xml \
     Channel_Interface_Splittable.xml \
     Channel_Interface_Transfer.xml \
     Channel_Interface_Tube.xml \
     Channel_Request.xml \
+    Channel_Request_Future.xml \
     Channel_Type_Call.xml \
     Channel_Type_Contact_List.xml \
     Channel_Type_Contact_Search.xml \
@@ -55,6 +60,7 @@ EXTRA_DIST = \
     Client_Interface_Requests.xml \
     Client_Observer.xml \
     Connection_Future.xml \
+    Connection_Interface_Addressing.xml \
     Connection_Interface_Aliasing.xml \
     Connection_Interface_Anonymity.xml \
     Connection_Interface_Avatars.xml \
@@ -70,6 +76,7 @@ EXTRA_DIST = \
     Connection_Interface_Forwarding.xml \
     Connection_Interface_Location.xml \
     Connection_Interface_Mail_Notification.xml \
+    Connection_Interface_Power_Saving.xml \
     Connection_Interface_Presence.xml \
     Connection_Interface_Privacy.xml \
     Connection_Interface_Renaming.xml \
@@ -85,6 +92,7 @@ EXTRA_DIST = \
     Media_Stream_Handler.xml \
     Properties_Interface.xml \
     Protocol.xml \
+    Protocol_Interface_Addressing.xml \
     Protocol_Interface_Avatars.xml \
     Protocol_Interface_Presence.xml \
     template.xml
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 50562c9b6..e37fe224d 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 000000000..3722c3b81
--- /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 af6863b4b..2a7673bb7 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</tp:version>
+<tp:version>0.19.12</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"/>
@@ -59,6 +61,7 @@ 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_Requests.xml"/>
@@ -110,6 +113,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 +128,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 +179,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 +191,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 e14dacbe5..a5368c02f 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 c017ba595..014f8ada4 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>