Update to spec 0.21.4

57 files changed, 6000 insertions, 1153 deletions

diff --git a/spec/Account.xml b/spec/Account.xml
index 5917c6f..acd8c30 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -407,16 +407,23 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>The presence status that this account should have if it is brought
           online.</p>
 
+        <tp:rationale>
+          In ITOS2007 and ITOS2008 this is a global preference, not visible
+          on D-Bus (the "default presence"). "Automatic presence" better
+          describes when it is used.
+        </tp:rationale>
+
         <p>Setting this property MUST NOT actually change the account's
           status until the next time it is (re)connected for some reason.</p>
 
-        <p>The <tp:type>Connection_Presence_Type</tp:type> in the structure
-          SHOULD NOT be Offline or Unset.</p>
+        <p>The value of this property MUST be one that would be acceptable
+          for <tp:member-ref>RequestedPresence</tp:member-ref>,
+          with the additional restriction that the
+          <tp:type>Connection_Presence_Type</tp:type> MUST NOT be Offline.</p>
 
         <tp:rationale>
-          In ITOS2007 and ITOS2008 this is a global preference, not visible
-          on D-Bus (the "default presence"). "Automatic presence" better
-          describes when it is used.
+          <p>Otherwise, it would not be possible to use this presence to bring
+            the account online for a channel request.</p>
         </tp:rationale>
       </tp:docstring>
     </property>
@@ -553,11 +560,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <property name="CurrentPresence" type="(uss)" access="read"
       tp:type="Simple_Presence" tp:name-for-bindings="Current_Presence">
       <tp:docstring>
-        The actual presence. If the connection is not online, this should be
-        (Connection_Presence_Type_Offline, "", "").
+        The actual presence. If the connection is not online, the
+        <tp:type>Connection_Presence_Type</tp:type> SHOULD be
+        Connection_Presence_Type_Offline.
         If the connection is online but does not support the <tp:dbus-ref
         namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
-        interface, this should be (Connection_Presence_Type_Unset, "", "").
+        interface, the type SHOULD be Connection_Presence_Type_Unset.
         The account manager is expected to set this by observing signals
         from the Connection.
 
@@ -585,6 +593,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           This corresponds to e.g. GetPresence and GetPresenceMessage
           in NMC 4.x.
         </tp:rationale>
+
+        <p>The <tp:type>Connection_Presence_Type</tp:type> in this property
+          MUST NOT be Unset, Unknown or Error.</p>
+
+        <tp:rationale>
+          <p>Requesting those presence types doesn't make sense.</p>
+        </tp:rationale>
       </tp:docstring>
     </property>
 
diff --git a/spec/Account_Interface_Minimum_Presence.xml b/spec/Account_Interface_Minimum_Presence.xml
new file mode 100644
index 0000000..eb829b8
--- /dev/null
+++ b/spec/Account_Interface_Minimum_Presence.xml
@@ -0,0 +1,108 @@
+<?xml version="1.0" ?>
+<node name="/Account_Interface_Minimum_Presence"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2010 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+<p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Account.Interface.MinimumPresence.DRAFT2"
+    tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+    <tp:added version="0.19.12">(draft 2)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface extends the core Account interface to provide a way
+        for applications to request minimum presence on the account.</p>
+
+      <tp:rationale>
+        <p>Some applications, for example mail notifiers or address book
+          synchronisation, can make use of account's connection even while
+          the user is nominally offline.</p>
+      </tp:rationale>
+
+      <p>Each client's unique name may set a minimum desired presence on the
+        account. The combined presence is the most available presence
+        of the minimum presences set and of <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Account">RequestedPresence</tp:dbus-ref>
+        set by the user. The account manager should attempt to manipulate
+        the connection to set the combined presence.</p>
+    </tp:docstring>
+
+    <property name="MinimumPresenceRequests"
+      tp:name-for-bindings="MinimumPresenceRequests" access="read"
+      type="a{s(uss)}" tp:type="Minimum_Presence_Request_Map">
+      <tp:docstring>
+        Active requests for minimum presence status, a map of client unique
+        name to the (non-offline) minimum presence they set.
+      </tp:docstring>
+    </property>
+
+    <method name="SetMinimumPresence" tp:name-for-bindings="Set_Minimum_Presence">
+      <tp:docstring>
+        <p>Set a minimum presence needed by the client for this account. Setting
+          (Offline, "offline", "") removes the minimum presence requirement for
+          the client's unique name.</p>
+      </tp:docstring>
+
+      <arg direction="in" name="status" type="(uss)" tp:type="Simple_Presence">
+        <tp:docstring>
+          Requested presence status.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <signal name="MinimumPresenceRequestsChanged"
+      tp:name-for-bindings="Minimum_Presence_Requests_Changed">
+      <tp:docstring>
+        Emitted when the
+        <tp:member-ref>MinimumPresenceRequests</tp:member-ref> property
+        changes.
+      </tp:docstring>
+
+      <arg name="MinimumPresenceRequests" type="a{s(uss)}"
+        tp:type="Minimum_Presence_Request_Map">
+        <tp:docstring>
+          A new value of MinimumPresenceRequests property.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:mapping name="Minimum_Presence_Request_Map">
+      <tp:docstring>
+        <p>A map of active minimum presence requests.</p>
+      </tp:docstring>
+      <tp:member type="s" name="Key" tp:type="DBus_Unique_Name">
+        <tp:docstring>
+          <p>Client unique name.</p>
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="(uss)" name="Value" tp:type="Simple_Presence">
+        <tp:docstring>
+          <p>Requested minimum presence.</p>
+
+          <tp:rationale>
+            <p>Some applications may want to monitor the currently active
+              minimum presences required. An example is an tool allowing
+              the user to inspect applications maintaining open connections and
+              close those applications.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Authentication_TLS_Certificate.xml b/spec/Authentication_TLS_Certificate.xml
new file mode 100644
index 0000000..db1d76f
--- /dev/null
+++ b/spec/Authentication_TLS_Certificate.xml
@@ -0,0 +1,305 @@
+<?xml version="1.0" ?>
+<node name="/Authentication_TLS_Certificate" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Limited</tp:copyright>
+  <tp:license>
+    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
+Lesser 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.Authentication.TLSCertificate">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
+
+    <tp:docstring>
+      This object represents a TLS certificate.
+    </tp:docstring>
+
+    <tp:simple-type name="Certificate_Data" array-name="Certificate_Data_List"
+                    type="ay">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The raw data contained in a TLS certificate.</p>
+
+        <p>For X.509 certificates (<tp:member-ref>CertificateType</tp:member-ref>
+        = "x509"), this MUST be in DER format, as defined by the
+        <a href="http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf">X.690</a>
+        ITU standard.</p>
+
+        <p>For PGP certificates (<tp:member-ref>CertificateType</tp:member-ref>
+        = "pgp"), this MUST be a binary OpenPGP key as defined by section 11.1
+        of <a href="http://www.rfc-editor.org/rfc/4880.txt">RFC 4880</a>.</p>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <tp:struct name="TLS_Certificate_Rejection" array-name="TLS_Certificate_Rejection_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Struct representing one reason why a TLS certificate was rejected.</p>
+        <p>Since there can be multiple things wrong with a TLS certificate,
+        arrays of this type are used to represent lists of reasons for
+        rejection. In that case, the most important reason SHOULD be placed
+        first in the list.</p>
+      </tp:docstring>
+
+      <tp:member name="Reason" type="u"
+                 tp:type="TLS_Certificate_Reject_Reason">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The value of the TLS_Certificate_Reject_Reason enumeration for
+          this certificate rejection.
+          <tp:rationale>
+            Clients that do not understand the <code>Error</code> member,
+            which may be implementation-specific, can use this property to
+            classify rejection reasons into common categories.
+          </tp:rationale>
+	  </p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Error" type="s"
+                 tp:type="DBus_Error_Name">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The DBus error name for this certificate rejection.</p>
+          <p>This MAY correspond to the value of the <code>Reason</code> member,
+          or MAY be a more specific D-Bus error name, perhaps implementation-specific.</p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Details" type="a{sv}"
+                 tp:type="String_Variant_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Additional information about why the certificate was rejected.
+          This MAY also include one or more of the following well-known keys:</p>
+          <p>
+          <dl>
+            <dt>user-requested (b)</dt>
+            <dd>True if the error was due to an user-requested rejection of
+            the certificate; False if there was an unrecoverable error in the
+            verification process.</dd>
+            <dt>expected-hostname (s)</dt>
+            <dd>If the rejection reason is Hostname_Mismatch, the hostname that
+            the server certificate was expected to have.</dd>
+            <dt>certificate-hostname (s)</dt>
+            <dd>If the rejection reason is Hostname_Mismatch, the hostname of
+            the certificate that was presented.
+            <tp:rationale>
+              <p>For instance, if you try to connect to gmail.com but are presented
+              with a TLS certificate issued to evil.example.org, the error details
+              for Hostname_Mismatch MAY include:</p>
+              <pre>
+                {
+                  'expected-hostname': 'gmail.com',
+                  'certificate-hostname': 'evil.example.org',
+                }
+              </pre>
+            </tp:rationale>
+            </dd>
+            <dt>debug-message (s)</dt>
+            <dd>Debugging information on the error, corresponding to the
+            message part of a D-Bus error message, which SHOULD NOT be
+            displayed to users under normal circumstances</dd>
+          </dl>
+          </p>
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:enum type="u" name="TLS_Certificate_State">
+      <tp:docstring>
+        The possible states for a <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
+        object.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Pending" value="0">
+        <tp:docstring>
+          The certificate is currently waiting to be accepted or rejected.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Accepted" value="1">
+        <tp:docstring>
+          The certificate has been verified.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Rejected" value="2">
+        <tp:docstring>
+          The certificate has been rejected.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:enum type="u" name="TLS_Certificate_Reject_Reason">
+      <tp:docstring>
+        Possible reasons to reject a TLS certificate.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring>
+          The certificate has been rejected for another reason
+          not listed in this enumeration.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Untrusted" value="1">
+        <tp:docstring>
+          The certificate is not trusted.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Expired" value="2">
+        <tp:docstring>
+          The certificate is expired.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Not_Activated" value="3">
+        <tp:docstring>
+          The certificate is not active yet.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Fingerprint_Mismatch" value="4">
+        <tp:docstring>
+          The certificate provided does not have the expected
+          fingerprint.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Hostname_Mismatch" value="5">
+        <tp:docstring>
+          The hostname certified does not match the provided one.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Self_Signed" value="6">
+        <tp:docstring>
+          The certificate is self-signed.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Revoked" value="7">
+        <tp:docstring>
+          The certificate has been revoked.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Insecure" value="8">
+        <tp:docstring>
+          The certificate uses an insecure cipher algorithm, or is
+          cryptographically weak.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Limit_Exceeded" value="9">
+        <tp:docstring>
+          The length in bytes of the certificate, or the depth of the
+          certificate chain exceed the limits imposed by the crypto
+          library.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="State" type="u" access="read"
+              tp:type="TLS_Certificate_State"
+              tp:name-for-bindings="State">
+      <tp:docstring>
+        The current state of this certificate.
+        State change notifications happen by means of the
+        <tp:member-ref>Accepted</tp:member-ref> and
+        <tp:member-ref>Rejected</tp:member-ref> signals.
+      </tp:docstring>
+    </property>
+
+    <property name="Rejections" type="a(usa{sv})" access="read"
+              tp:type="TLS_Certificate_Rejection[]" tp:name-for-bindings="Rejections">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If the <tp:member-ref>State</tp:member-ref> is Rejected,
+        an array of <tp:type>TLS_Certificate_Rejection</tp:type>
+        structures containing the reason why the certificate is rejected.</p>
+        <p>If the <tp:member-ref>State</tp:member-ref> is not Rejected,
+        this property is not meaningful, and SHOULD be set to an empty
+        array.</p>
+        <p>The first rejection in the list MAY be assumed to be
+        the most important; if the array contains more than one
+        element, the CM MAY either use the values after the first,
+        or ignore them.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CertificateType" type="s" access="read"
+              tp:name-for-bindings="Certificate_Type">
+      <tp:docstring>
+        The type of this TLS certificate (e.g. 'x509' or 'pgp').
+        <p>This property is immutable</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CertificateChainData" type="aay" access="read"
+              tp:type="Certificate_Data[]" tp:name-for-bindings="Certificate_Chain_Data">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>One or more TLS certificates forming a trust chain, each encoded as
+        specified by <tp:type>Certificate_Data</tp:type>.</p>
+        <p>The first certificate in the chain MUST be the server certificate,
+        followed by the issuer's certificate, followed by the issuer's issuer
+        and so on.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="Accepted"
+            tp:name-for-bindings="Accepted">
+      <tp:docstring>
+        The <tp:member-ref>State</tp:member-ref> of this certificate has changed to Accepted.
+      </tp:docstring>
+    </signal>
+
+    <signal name="Rejected"
+            tp:name-for-bindings="Rejected">
+      <tp:docstring>
+        The <tp:member-ref>State</tp:member-ref> of this certificate has changed to Rejected.
+      </tp:docstring>
+      <arg name="Rejections" type="a(usa{sv})" tp:type="TLS_Certificate_Rejection[]">
+        <tp:docstring>
+          The new value of the <tp:member-ref>Rejections</tp:member-ref> property.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="Accept" tp:name-for-bindings="Accept">
+      <tp:docstring>
+        Accepts this certificate, i.e. marks it as verified.
+      </tp:docstring>
+    </method>
+
+    <method name="Reject" tp:name-for-bindings="Reject">
+      <tp:docstring>
+        Rejects this certificate.
+      </tp:docstring>
+      <arg direction="in" type="a(usa{sv})" name="Rejections"
+           tp:type="TLS_Certificate_Rejection[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The new value of the <tp:member-ref>Rejections</tp:member-ref> property.</p>
+          <p>This MUST NOT be an empty array.</p>
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Raised when the method is called on an object whose <tp:member-ref>State</tp:member-ref>
+            is not <code>Pending</code>, or when the provided rejection list is empty.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content.xml b/spec/Call_Content.xml
index 3e585b4..17ed710 100644
--- a/spec/Call_Content.xml
+++ b/spec/Call_Content.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Content"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -25,52 +25,147 @@
     <tp:added version="0.19.0">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      This object represents one Content inside a Call. For example in an
-      audio/video call there would be one audio and one video content. Each
-      content has one or more <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Call">Stream.DRAFT</tp:dbus-ref>
-      objects which represent the actual transport to one or more contacts.
-
+      This object represents one Content inside a <tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>. For
+      example, in an audio/video call there would be one audio content
+      and one video content. Each content has one or more <tp:dbus-ref
+      namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref> objects which
+      represent the actual transport to one or more remote contacts.
     </tp:docstring>
 
+    <tp:enum name="Content_Removal_Reason" type="u">
+      <tp:added version="0.21.2"/>
+      <tp:docstring>
+        A representation of the reason for a content to be removed,
+        which may be used by simple clients, or used as a fallback
+        when the DBus_Reason is not understood. This enum will be
+        extended with future reasons as and when appropriate, so
+        clients SHOULD keep up to date with its values, but also be
+        happy to fallback to the Unknown value when an unknown value
+        is encountered.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          We just don't know. Unknown values of this enum SHOULD also be
+          treated like this.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="User_Requested" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The local user requests that this content is removed
+            from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Error" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>There is an error with the content which means that it
+            has to be removed from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Unsupported" value="3">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Some aspect of the content is unsupported so has to be
+            removed from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
     <method name="Remove" tp:name-for-bindings="Remove">
-      <tp:docstring>Remove the content from the call.</tp:docstring>
+      <tp:changed version="0.21.2">previously there were no
+        arguments</tp:changed>
+      <tp:docstring>
+        Remove the content from the call.
+      </tp:docstring>
+
+      <arg direction="in" name="Reason" type="u"
+        tp:type="Content_Removal_Reason">
+        <tp:docstring>
+          A generic hangup reason.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Detailed_Removal_Reason" type="s"
+        tp:type="DBus_Error_Name">
+        <tp:docstring>
+          A more specific reason for the content removal, if one is
+          available, or an empty string.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Message" type="s">
+        <tp:docstring>
+          A human-readable message for the reason of removing the
+          content, such as "Fatal streaming failure" or "no codec
+          intersection". This property can be left empty if no reason
+          is to be given.
+        </tp:docstring>
+      </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError">
-        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
-            Raised when a Call doesn't support removing contents (e.g. a Google Talk video call)
+            Raised when a Call doesn't support removing contents
+            (e.g. a Google Talk video call).
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
     </method>
 
-    <property name="Name" tp:name-for-bindings="Name" type="s" access="read">
+    <signal name="Removed" tp:name-for-bindings="Removed">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The name of the content.
-          [FIXME: rationale?]</p>
+        <p>Emitted when the content is removed from the call. This
+          is the same as the <tp:dbus-ref
+          namespace="ofdT.Channel.Type">Call.DRAFT.ContentRemoved</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </signal>
+
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:added version="0.19.11"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this content, such as <tp:dbus-ref
+          namespace="ofdT.Call">Content.Interface.Media.DRAFT</tp:dbus-ref> or
+          <tp:dbus-ref namespace="ofdT.Call">Content.Interface.Mute.DRAFT</tp:dbus-ref>.
+          This SHOULD NOT include the Content interface itself, and cannot
+          change once the content has been created.</p>
       </tp:docstring>
     </property>
 
-    <property name="Type" tp:name-for-bindings="Type"
-        type="u" tp:type="Media_Stream_Type" access="read">
+    <property name="Name" tp:name-for-bindings="Name" type="s" access="read"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The media type of this content</p>
+        <p>The name of the content.</p>
+
+        <tp:rationale>
+          The content name property should be meaningful, so should be
+          given a name which is significant to the user. The name
+          could be the "audio" or "video" string localized, or perhaps
+          include some string identifying the source, such as a webcam
+          identifier.
+        </tp:rationale>
       </tp:docstring>
     </property>
 
-    <property name="Creator" tp:name-for-bindings="Creator"
-        type="u" tp:type="Contact_Handle" access="read">
+    <property name="Type" tp:name-for-bindings="Type"
+        type="u" tp:type="Media_Stream_Type" access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The creator of this content</p>
+        <p>The media type of this content.</p>
       </tp:docstring>
     </property>
 
     <tp:enum name="Call_Content_Disposition" type="u">
       <tp:docstring>
-        [FIXME]
+        The disposition of this content, which defines whether to
+        automatically start sending data on the streams when
+        <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
+        called on the channel.
       </tp:docstring>
 
       <tp:enumvalue suffix="None" value="0">
@@ -79,52 +174,57 @@
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Early_Media" value="1">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          [FIXME: what does this mean?]
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Initial" value="2">
+      <tp:enumvalue suffix="Initial" value="1">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The content was initially part of the call. When <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"
-              >Accept</tp:dbus-ref> is called on the channel, all streams of
-            this content where the self-handle's sending state in <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Call.Stream.DRAFT"
-              >Senders</tp:dbus-ref> is Sending_State_Pending_Send
-            will be moved to Sending_State_Sending as if <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Call.Stream.DRAFT"
-              >SetSending</tp:dbus-ref>(TRUE) had been called.</p>
+          <p>The content was initially part of the call. When
+          <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          is called on the channel, all streams of this content with
+          <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
+          set to <tp:type>Sending_State</tp:type>_Pending_Send will be
+          moved to <tp:type>Sending_State</tp:type>_Sending as if
+          <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">SetSending</tp:dbus-ref>
+          (True) had been called.</p>
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
 
     <property name="Disposition" tp:name-for-bindings="Disposition"
-        type="u" tp:type="Call_Content_Disposition" access="read">
+        type="u" tp:type="Call_Content_Disposition" access="read"
+        tp:immutable="yes">
       <tp:docstring>
-        The disposition of this content. This property cannot change.
+        The disposition of this content.
       </tp:docstring>
     </property>
 
-    <signal name="StreamAdded" tp:name-for-bindings="Stream_Added">
+    <signal name="StreamsAdded" tp:name-for-bindings="Streams_Added">
+      <tp:changed version="0.21.2">plural version, renamed from
+        StreamAdded</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-         <p>Emitted when a stream is added to a call</p>
+         <p>Emitted when streams are added to a call.</p>
       </tp:docstring>
-      <arg name="Stream" type="o">
+      <arg name="Streams" type="ao">
          <tp:docstring>
-           The stream which was added
+           The <tp:dbus-ref
+           namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
+           added.
          </tp:docstring>
        </arg>
     </signal>
 
-    <signal name="StreamRemoved" tp:name-for-bindings="Stream_Removed">
+    <signal name="StreamsRemoved" tp:name-for-bindings="Streams_Removed">
+      <tp:changed version="0.21.2">plural version, renamed from
+        StreamRemoved</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-         <p>Emitted when a stream is added to a call</p>
+         <p>Emitted when streams are removed from a call</p>
       </tp:docstring>
-      <arg name="Stream" type="o">
+      <arg name="Streams" type="ao">
          <tp:docstring>
-           The stream which was removed
+           The <tp:dbus-ref
+           namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
+           removed.
          </tp:docstring>
        </arg>
     </signal>
@@ -132,22 +232,58 @@
     <property name="Streams" tp:name-for-bindings="Streams"
       type="ao" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The list of
-           <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Call">Stream.DRAFT</tp:dbus-ref>
-           objects that exist in this content.</p>
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call"
+          >Stream.DRAFT</tp:dbus-ref> objects that exist in this
+          content.</p>
 
         <tp:rationale>
-          <p>In a conference call multiple parties can share one media content
-            (say, audio), but the streaming of that media can either be shared
-            or separate. For example, in a multicast conference all contacts
-            would share one stream, while in a Muji conference there would be
-            a stream for each participant.</p>
+          In a conference call multiple parties can share one media
+          content (say, audio), but the streaming of that media can
+          either be shared or separate. For example, in a multicast
+          conference all contacts would share one stream, while in a
+          Muji conference there would be a stream for each
+          participant.
         </tp:rationale>
 
-        <p>Change notification is via
-          <tp:member-ref>StreamAdded</tp:member-ref> and
-          <tp:member-ref>StreamRemoved</tp:member-ref>.</p>
+        <p>Change notification is through the
+          <tp:member-ref>StreamsAdded</tp:member-ref> and
+          <tp:member-ref>StreamsRemoved</tp:member-ref> signals.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:enum name="Call_Content_Packetization_Type" type="u">
+      <tp:added version="0.21.2"/>
+      <tp:docstring>
+        A packetization method that can be used for a content.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="RTP" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Real-time Transport Protocol, as documented by RFC 3550.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Raw" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Raw media.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="MSN_Webcam" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          MSN webcam. This is the video-only one-way type which was
+          used in earlier versions of WLM. Although no longer used,
+          modern WLM clients still support the MSN webcam protocol.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="Packetization" tp:name-for-bindings="Packetization"
+      type="u" tp:type="Call_Content_Packetization_Type" access="read"
+      tp:immutable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The packetization method in use for this content.</p>
       </tp:docstring>
     </property>
   </interface>
diff --git a/spec/Call_Content_Codec_Offer.xml b/spec/Call_Content_Codec_Offer.xml
index 31ff0b3..e0a791f 100644
--- a/spec/Call_Content_Codec_Offer.xml
+++ b/spec/Call_Content_Codec_Offer.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Content_Codec_Offer"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -26,15 +26,27 @@
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       This object represents an offer of a Codec payload mapping.
-      FIXME add Accept and Reject signals ?
     </tp:docstring>
 
     <method name="Accept" tp:name-for-bindings="Accept">
       <arg name="Codecs" direction="in"
-        type="a(usuua{ss})" tp:type="Codec[]" />
+        type="a(usuua{ss})" tp:type="Codec[]">
+        <tp:docstring>
+          The local codec mapping to send to the remote contacts and
+          to use in the <tp:dbus-ref
+          namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
+        </tp:docstring>
+      </arg>
       <tp:docstring>
-        Accept the updated Codec mapping and update the local mapping
+        Accept the updated Codec mapping and update the local mapping.
       </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The codecs given as the argument are invalid in some way.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
     </method>
 
     <method name="Reject" tp:name-for-bindings="Reject">
@@ -44,11 +56,22 @@
       </tp:docstring>
     </method>
 
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this codec offer.  This SHOULD
+          NOT include the CodecOffer interface itself, and cannot change
+          once the content has been created.</p>
+      </tp:docstring>
+    </property>
+
     <property name="RemoteContactCodecMap"
       tp:name-for-bindings="Remote_Contact_Codec_Map"
-      type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read">
+      type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read"
+      tp:immutable="yes">
       <tp:docstring>
-        A map from remote contacts to the lists of codecs they support.
+        A map from remote contact to the list of codecs he or she
+        supports.
       </tp:docstring>
     </property>
 
diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call_Content_Interface_Media.xml
index 8b9a17c..24811fd 100644
--- a/spec/Call_Content_Interface_Media.xml
+++ b/spec/Call_Content_Interface_Media.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Content_Interface_Media"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -23,65 +23,85 @@
   <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT"
       tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Content"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      Interface to use by a software implementation of media streaming.
+      <p>Interface to use by a software implementation of media
+        streaming. The reason behind splitting the members of this
+        interface out from the main <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> interface is
+        that the software is not necessarily what controls the
+        media. An example of this is in GSM phones, where the CM just
+        tells the phone to dial a number and it does the audio routing
+        in a device specific hardware way and the CM does not need
+        to concern itself with codecs.</p>
+
+      <p>On new <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels,
+        handlers should wait for <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        objects to appear (one will either already be present, or will
+        appear at some point in the channel's lifetime).</p>
+
+      <p>If the Call is incoming, then the codec offer's <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecMap</tp:dbus-ref>
+        will already be filled with the codec information of the
+        remote contacts. Depending on the protocol, an outgoing call's
+        <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecMap</tp:dbus-ref>
+        will either be filled with remote contact codec information, or
+        it will be empty. If empty, then this SHOULD be interpreted to
+        mean that all codecs are supported. Once a compatible list of
+        codecs has been decided, <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT.Accept</tp:dbus-ref>
+        should be called with the details of these codecs.</p>
 
-      FIXME: How should the streaming implementation know when it is its turn
-      to set the codecs.
     </tp:docstring>
 
     <tp:struct name="Codec" array-name="Codec_List">
       <tp:docstring>
         A description of a codec.
       </tp:docstring>
-
       <tp:member name="Identifier" type="u">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           Numeric identifier for the codec. This will be used as the PT in the
           SDP or content description.
         </tp:docstring>
       </tp:member>
-
       <tp:member name="Name" type="s">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           The name of the codec.
         </tp:docstring>
       </tp:member>
-
       <tp:member name="Clockrate" type="u">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          The clockrate of the codec
+          The clockrate of the codec.
         </tp:docstring>
       </tp:member>
       <tp:member name="Channels" type="u">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          Number of channels of the codec if applicable, otherwise 0
+          Number of channels of the codec if applicable, otherwise 0.
         </tp:docstring>
       </tp:member>
-
       <tp:member name="Parameters" type="a{ss}" tp:type="String_String_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          Extra parameters for this codec
+          Extra parameters for this codec.
         </tp:docstring>
       </tp:member>
     </tp:struct>
 
     <tp:mapping name="Contact_Codec_Map">
       <tp:docstring>
-        A map from contacts to the lists of codecs they support.
+        A map from contact to the list of codecs he or she supports.
       </tp:docstring>
-
       <tp:member name="Handle" type="u" tp:type="Contact_Handle">
         <tp:docstring>
-          A contact
+          A contact handle.
         </tp:docstring>
       </tp:member>
-
       <tp:member name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
         <tp:docstring>
-          The codecs that the contact supports
+          The codecs that the contact supports.
         </tp:docstring>
       </tp:member>
     </tp:mapping>
@@ -90,20 +110,17 @@
       <tp:docstring>
         A codec offer and its corresponding remote contact codec map.
       </tp:docstring>
-
       <tp:member name="Codec_Offer" type="o">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          The object path to the
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Content"
-              >CodecOffer.DRAFT</tp:dbus-ref>
+          The object path to the <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT</tp:dbus-ref>
         </tp:docstring>
       </tp:member>
-
       <tp:member name="Remote_Contact_Codec_Map" type="a{ua(usuua{ss})}"
           tp:type="Contact_Codec_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          The <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Content"
-            >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property
+          The <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property
           of the codec offer.
         </tp:docstring>
       </tp:member>
@@ -118,16 +135,15 @@
           signal implies that the <tp:member-ref>CodecOffer</tp:member-ref>
           property has changed to <code>('/', {})</code>.</p>
       </tp:docstring>
-
       <arg name="Updated_Codecs" type="a{ua(usuua{ss})}"
         tp:type="Contact_Codec_Map">
         <tp:docstring>
-          A map from contacts to their codecs. Each pair in this map is added
-          to the <tp:member-ref>ContactCodecMap</tp:member-ref> property,
+          A map from contact to his or her codecs. Each pair in this
+          map is added to the
+          <tp:member-ref>ContactCodecMap</tp:member-ref> property,
           replacing any previous pair with that key.
         </tp:docstring>
       </arg>
-
       <arg name="Removed_Contacts" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
           A list of keys which were removed from the
@@ -137,17 +153,24 @@
       </arg>
     </signal>
 
-    <method name="SetCodecs" tp:name-for-bindings="Set_Codecs">
+    <method name="UpdateCodecs" tp:name-for-bindings="Update_Codecs">
       <tp:docstring>
-        Set or update the local codec mapping.
+        Update the local codec mapping. This method should only be
+        used during an existing call to update the codec mapping.
       </tp:docstring>
-
       <arg name="Codecs" direction="in"
         type="a(usuua{ss})" tp:type="Codec[]">
         <tp:docstring>
           The codecs now supported by the local user.
         </tp:docstring>
       </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Raised when not used during an existing call to update the codec mapping.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
     </method>
 
     <property name="ContactCodecMap" tp:name-for-bindings="Contact_Codec_Map"
@@ -156,45 +179,44 @@
         <p>A map from contact handles (including the local user's own handle)
           to the codecs supported by that contact.</p>
 
-        <p>Change notification is via
-          <tp:member-ref>CodecsChanged</tp:member-ref>.</p>
+        <p>Change notification is via the
+          <tp:member-ref>CodecsChanged</tp:member-ref> signal.</p>
       </tp:docstring>
     </property>
 
     <signal name="NewCodecOffer" tp:name-for-bindings="New_Codec_Offer">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a new <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content"
-            >CodecOffer.DRAFT</tp:dbus-ref> appears. The streaming
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT</tp:dbus-ref> appears. The streaming
           implementation MUST respond by calling the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content.CodecOffer.DRAFT"
-            >Accept</tp:dbus-ref> or <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content.CodecOffer.DRAFT"
-            >Reject</tp:dbus-ref> method on the codec offer object.</p>
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >Accept</tp:dbus-ref> or <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >Reject</tp:dbus-ref> method on the codec offer object.</p>
 
         <p>Emission of this signal indicates that the
           <tp:member-ref>CodecOffer</tp:member-ref> property has changed to
           <code>(Offer, Codecs)</code>.</p>
       </tp:docstring>
-
       <arg name="Offer" type="o">
         <tp:docstring>
           The object path of the new codec offer. This replaces any previous
           codec offer.
         </tp:docstring>
       </arg>
-
       <arg name="Codecs" type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Content"
-              >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property
+          <p>The <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property
             of the codec offer.</p>
 
-          <tp:rationale>
-            <p>Having the RemoteContactCodecMap property here saves a D-Bus
-              round-trip - it shouldn't be necessary to get the property
-              from the CodecOffer object, in practice.</p>
-          </tp:rationale>
+        <tp:rationale>
+          Having the <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecMap</tp:dbus-ref>
+          property here saves a D-Bus round-trip - it shouldn't be
+          necessary to get the property from the CodecOffer object, in
+          practice.
+        </tp:rationale>
         </tp:docstring>
       </arg>
     </signal>
@@ -203,25 +225,26 @@
       type="(oa{ua(usuua{ss})})" tp:type="Codec_Offering" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The object path to the current
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content"
-              >CodecOffer.DRAFT</tp:dbus-ref> object, and its
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Content"
-              >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property.
+          <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT</tp:dbus-ref> object, and its
+            <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContactCodecMap</tp:dbus-ref> property.
             If the object path is "/" then there isn't an outstanding
-          codec offer, and the mapping MUST be empty.</p>
+            codec offer, and the mapping MUST be empty.</p>
 
         <tp:rationale>
-          <p>Having the RemoteContactCodecMap property here saves a D-Bus
-            round-trip - it shouldn't be necessary to get the property
-            from the CodecOffer object, in practice.</p>
+          Having the <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecMap</tp:dbus-ref>
+          property here saves a D-Bus round-trip - it shouldn't be
+          necessary to get the property from the CodecOffer object, in
+          practice.
         </tp:rationale>
 
-        <p>Change notification is via
+        <p>Change notification is via the
           <tp:member-ref>NewCodecOffer</tp:member-ref> (which replaces the
           value of this property with a new codec offer), and
           <tp:member-ref>CodecsChanged</tp:member-ref> (which implies that
-          there is no longer any active codec offer).</p>
+          there is no longer any active codec offer) signals.</p>
       </tp:docstring>
     </property>
   </interface>
diff --git a/spec/Call_Content_Interface_Mute.xml b/spec/Call_Content_Interface_Mute.xml
index eea724f..f926e03 100644
--- a/spec/Call_Content_Interface_Mute.xml
+++ b/spec/Call_Content_Interface_Mute.xml
@@ -20,6 +20,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
   <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Mute.DRAFT" tp:causes-havoc="experimental">
     <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Interface for calls which may be muted.  This only makes sense
@@ -31,22 +32,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <p>Although it's client's responsibility to actually mute the microphone
         or turn off the camera, using this interface the client can also
         inform the CM and other clients of that fact.</p>
-        <tp:rationale>
-          <p>For some protocols, the fact that the content is muted needs to be
-          transmitted to the peer; for others, the notification to the peer is
-          only informational (eg. XMPP), and some protocols may have no notion
-          of muting at all.</p>
-        </tp:rationale>
+
+      <tp:rationale>
+        For some protocols, the fact that the content is muted needs
+        to be transmitted to the peer; for others, the notification
+        to the peer is only informational (eg. XMPP), and some
+        protocols may have no notion of muting at all.
+      </tp:rationale>
     </tp:docstring>
 
-   <signal name="MuteStateChanged" tp:name-for-bindings="Mute_State_Changed">
+    <signal name="MuteStateChanged" tp:name-for-bindings="Mute_State_Changed">
       <tp:docstring>
         Emitted to indicate that the mute state has changed for this call content.
         This may occur as a consequence of the client calling
-        <tp:member-ref>Muted</tp:member-ref>, or as an indication that another
+        <tp:member-ref>SetMuted</tp:member-ref>, or as an indication that another
         client has (un)muted the content.
       </tp:docstring>
-
       <arg name="MuteState" type="b">
         <tp:docstring>
           True if the content is now muted.
@@ -61,16 +62,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
-    <method name="Muted" tp:name-for-bindings="Muted">
+    <method name="SetMuted" tp:name-for-bindings="Set_Muted">
+      <tp:changed version="0.21.2">renamed from SetMuted to Mute</tp:changed>
+      <tp:changed version="0.21.3">renamed back from Mute to SetMuted</tp:changed>
       <arg direction="in" name="Muted" type="b">
         <tp:docstring>
           True if the client has muted the content.
         </tp:docstring>
       </arg>
-
       <tp:docstring>
         <p>Inform the CM that the call content has been muted or unmuted by
-          che client.</p>
+          the client.</p>
 
         <p>It is the client's responsibility to actually mute or unmute the
           microphone or camera used for the content. However, the client
diff --git a/spec/Call_Stream.xml b/spec/Call_Stream.xml
index dc7d784..1d7b281 100644
--- a/spec/Call_Stream.xml
+++ b/spec/Call_Stream.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Stream"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -25,38 +25,43 @@
     <tp:added version="0.19.0">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      One stream inside a content
-      FIXME, direction should be a mapping of contact -> (bool)sending ?
+      One stream inside a <tp:dbus-ref
+      namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
     </tp:docstring>
 
     <method name="SetSending" tp:name-for-bindings="Set_Sending">
       <tp:docstring>
         Set the stream to start or stop sending media from the local
-          user to other contacts.
+        user to other contacts.
       </tp:docstring>
 
       <arg name="Send" type="b" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>If true, the local user's sending state should change
-            to Sending, if it isn't already.</p>
+          <p>If True, the
+            <tp:member-ref>LocalSendingState</tp:member-ref> should
+            change to <tp:type>Sending_State</tp:type>_Sending, if it isn't
+            already.</p>
 
-          <p>If false, the local user's sending state should change to None,
-            if it isn't already.</p>
+          <p>If False, the
+            <tp:member-ref>LocalSendingState</tp:member-ref> should
+            change to <tp:type>Sending_State</tp:type>_None, if it isn't
+            already.</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            [FIXME: when?]
-          </tp:docstring>
-        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented" />
       </tp:possible-errors>
     </method>
 
     <method name="RequestReceiving" tp:name-for-bindings="Request_Receiving">
       <tp:docstring>
-        Request that a remote contact stops or starts sending on this stream.
+        <p>Request that a remote contact stops or starts sending on
+          this stream.</p>
+
+        <p>The <tp:member-ref>CanRequestReceiving</tp:member-ref>
+          property defines whether the protocol allows the local user to
+          request the other side start sending on this stream.</p>
       </tp:docstring>
 
       <arg name="Contact" type="u" tp:type="Contact_Handle" direction="in">
@@ -73,44 +78,69 @@
       </arg>
 
       <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The request contact is valid but is not involved in this
+            stream.
+          </tp:docstring>
+        </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
-            [FIXME: when?]
+            The protocol does not allow the local user to request the
+            other side starts sending on this stream.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
     </method>
 
-    <signal name="SendersChanged"
-        tp:name-for-bindings="Senders_Changed">
+    <signal name="RemoteMembersChanged"
+        tp:name-for-bindings="Remote_Members_Changed">
+      <tp:changed version="0.21.2">renamed from SendersChanged to MembersChanged</tp:changed>
+      <tp:changed version="0.21.3">renamed from MembersChanged to RemoteMembersChanged</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        Emitted when <tp:member-ref>Senders</tp:member-ref> changes.
+        Emitted when <tp:member-ref>RemoteMembers</tp:member-ref> changes.
       </tp:docstring>
 
       <arg name="Updates" type="a{uu}" tp:type="Contact_Sending_State_Map">
         <tp:docstring>
           A mapping from channel-specific handles to their updated sending
-          state, whose keys include at least the senders who were added,
-          and the senders whose states changed.
+          state, whose keys include at least the members who were added,
+          and the members whose states changed.
         </tp:docstring>
       </arg>
       <arg name="Removed" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
-          The channel-specific handles that were removed from
-          the keys of the Senders property, as a result of the
-          contact leaving this stream
+          The channel-specific handles that were removed from the keys
+          of the <tp:member-ref>RemoteMembers</tp:member-ref>
+          property, as a result of the contact leaving this stream
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="LocalSendingStateChanged"
+        tp:name-for-bindings="Local_Sending_State_Changed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Emitted when <tp:member-ref>LocalSendingState</tp:member-ref> changes.
+      </tp:docstring>
+
+      <arg name="State" type="u" tp:type="Sending_State">
+        <tp:docstring>
+          The new value of
+          <tp:member-ref>LocalSendingState</tp:member-ref>.
         </tp:docstring>
       </arg>
     </signal>
 
     <tp:enum name="Sending_State" type="u">
       <tp:docstring>
-        Tristate indicating whether a contact is sending media.
+        Enum indicating whether a contact is sending media.
       </tp:docstring>
 
       <tp:enumvalue suffix="None" value="0">
         <tp:docstring>
-          The contact is not sending media and has not been asked to do so.
+          The contact is not sending media and has not been asked to
+          do so.
         </tp:docstring>
       </tp:enumvalue>
 
@@ -125,35 +155,51 @@
           The contact is sending media.
         </tp:docstring>
       </tp:enumvalue>
+
+      <tp:enumvalue suffix="Pending_Stop_Sending" value="3">
+        <tp:docstring>
+          The contact has been asked to stop sending media.
+        </tp:docstring>
+      </tp:enumvalue>
     </tp:enum>
 
     <tp:mapping name="Contact_Sending_State_Map">
       <tp:docstring>
-        A map from contacts to their sending state.
+        A map from a contact to his or her sending state.
       </tp:docstring>
       <tp:member name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact handle.
+        </tp:docstring>
       </tp:member>
       <tp:member name="Sending" type="u" tp:type="Sending_State">
          <tp:docstring>
+           The sending state of the contact.
          </tp:docstring>
       </tp:member>
     </tp:mapping>
 
-    <property name="Senders" tp:name-for-bindings="Senders"
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:added version="0.19.11"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this stream, such as <tp:dbus-ref
+            namespace="ofdT.Call">Stream.Interface.Media.DRAFT</tp:dbus-ref>.
+          This SHOULD NOT include the Stream interface itself, and cannot
+          change once the stream has been created.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteMembers" tp:name-for-bindings="Remote_Members"
         type="a{uu}" access="read" tp:type="Contact_Sending_State_Map">
+      <tp:changed version="0.21.2">renamed from Senders</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A map from contacts to their sending state.</p>
-
-        <p>The local user's handle in this map (the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Group.SelfHandle</tp:dbus-ref> if the channel implements
-          Group, or the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy"
-            >Connection.SelfHandle</tp:dbus-ref> otherwise) indicates
-          whether the local user is sending media. Media sent on this stream
-          should be assumed to be received, directly or indirectly, by every
-          other contact in the Senders mapping. Sending_State_Pending_Send
-          indicates that another contact has asked the local user to send
+        <p>A map from remote contacts to their sending state. The
+          local user's sending state is shown in
+          <tp:member-ref>LocalSendingState</tp:member-ref>.</p>
+
+        <p><tp:type>Sending_State</tp:type>_Pending_Send indicates
+          that another contact has asked the local user to send
           media.</p>
 
         <p>Other contacts' handles in this map indicate whether they are
@@ -162,6 +208,54 @@
           have been asked to do so.</p>
       </tp:docstring>
     </property>
+
+    <property name="LocalSendingState" tp:name-for-bindings="Local_Sending_State"
+        type="u" access="read" tp:type="Sending_State">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The local user's sending state. Media sent on this stream
+          should be assumed to be received, directly or indirectly, by
+          every other contact in the
+          <tp:member-ref>RemoteMembers</tp:member-ref> mapping. Change
+          notification is given via the
+          <tp:member-ref>LocalSendingStateChanged</tp:member-ref>
+          signal.</p>
+
+        <tp:rationale>
+          Implementations of the first Call draft had the self handle
+          in the <tp:member-ref>RemoteMembers</tp:member-ref> (then
+          called Members) map and this showed that it's annoying
+          having to keep track of the self handle so that it can be
+          special-cased.
+        </tp:rationale>
+
+        <p>A value of <tp:type>Sending_State</tp:type>_Pending_Send for
+          this property indicates that the other side requested the
+          local user start sending media, which can be done by calling
+          <tp:member-ref>SetSending</tp:member-ref>. When a call is
+          accepted, all initial contents with streams that have a
+          local sending state of
+          <tp:type>Sending_State</tp:type>_Pending_Send are
+          automatically set to sending. For example, on an incoming
+          call it means you need to <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          to start the actual call, on an outgoing call it might mean
+          you need to call <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          before actually starting the call.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CanRequestReceiving" tp:name-for-bindings="Can_Request_Receiving"
+        type="b" access="read" tp:immutable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, the user can request that a remote contact starts
+          sending on this stream.</p>
+
+        <tp:rationale>Not all protocols allow the user to ask the
+          other side to start sending media.</tp:rationale>
+      </tp:docstring>
+    </property>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Stream_Endpoint.xml b/spec/Call_Stream_Endpoint.xml
index fbab2cf..4818168 100644
--- a/spec/Call_Stream_Endpoint.xml
+++ b/spec/Call_Stream_Endpoint.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Stream_Endpoint"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -21,73 +21,160 @@
   </tp:license>
 
   <interface name="org.freedesktop.Telepathy.Call.Stream.Endpoint.DRAFT"
-      tp:causes-havoc="experimental">
+    tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      This object represents a set of candidates of one end-point.
+      <p>This object represents an endpoint for a stream. In a one-to-one
+        call, there will be one (bidirectional) stream per content and
+        one endpoint per stream (as there is only one remote
+        contact). In a multi-user call there is a stream for each remote
+        contact and each stream has one endpoint as it refers to the one
+        physical machine on the other end of the stream.</p>
+
+      <p>The multiple endpoint use case appears when SIP call forking
+        is used. Unlike jingle call forking (which is just making
+        multiple jingle calls to different resources appear as one
+        call), SIP call forking is actually done at the server so you
+        have one stream to the remote contact and then and endpoint for
+        each SIP client to be called.</p>
     </tp:docstring>
 
     <property name="RemoteCredentials"
       tp:name-for-bindings="Remote_Credentials"
       type="(ss)" tp:type="Stream_Credentials" access="read">
+      <tp:docstring>
+        The ICE credentials used for all candidates. If each candidate
+        has different credentials, then this property SHOULD be ("",
+        ""). Per-candidate credentials are set in the
+        <tp:type>Candidate</tp:type>'s
+        <tp:type>Candidate_Info</tp:type> a{sv}.
+      </tp:docstring>
     </property>
 
     <signal name="RemoteCredentialsSet"
-        tp:name-for-bindings="Remote_Credentials_Set">
-      <arg name="Username" type="s" />
-      <arg name="Password" type="s" />
+      tp:name-for-bindings="Remote_Credentials_Set">
+      <arg name="Username" type="s">
+        <tp:docstring>
+          The username set.
+        </tp:docstring>
+      </arg>
+      <arg name="Password" type="s">
+        <tp:docstring>
+          The password set.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Emitted when the remote ICE credentials for the endpoint are
+        set. If each candidate has different credentials, then this
+        signal will never be fired.
+      </tp:docstring>
     </signal>
 
     <property name="RemoteCandidates" tp:name-for-bindings="Remote_Candidates"
       type="a(usqa{sv})" tp:type="Candidate[]" access="read">
+      <tp:docstring>
+        A list of candidates for this endpoint.
+      </tp:docstring>
     </property>
 
     <signal name="RemoteCandidatesAdded"
-        tp:name-for-bindings="Remote_Candidates_Added">
+      tp:name-for-bindings="Remote_Candidates_Added">
+      <tp:docstring>
+        Emitted when remote candidates are added to the
+        <tp:member-ref>RemoteCandidates</tp:member-ref> property.
+      </tp:docstring>
       <arg name="Candidates"
-        type="a(usqa{sv})" tp:type="Candidate[]"/>
+        type="a(usqa{sv})" tp:type="Candidate[]">
+        <tp:docstring>
+          The candidates that were added.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <signal name="CandidateSelected"
-        tp:name-for-bindings="Candidate_Selected">
+      tp:name-for-bindings="Candidate_Selected">
+      <tp:docstring>
+        Emitted when a candidate is selected for use in the stream.
+      </tp:docstring>
       <arg name="Candidate"
-        type="(usqa{sv})" tp:type="Candidate"/>
+        type="(usqa{sv})" tp:type="Candidate">
+        <tp:docstring>
+          The candidate that has been selected.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <property name="SelectedCandidate"
-        tp:name-for-bindings="Selected_Candidate"
+      tp:name-for-bindings="Selected_Candidate"
       type="(usqa{sv})" tp:type="Candidate" access="read">
+      <tp:docstring>
+        The candidate that has been selected for use to stream packets
+        to the remote contact. Change notification is given via the
+        the <tp:member-ref>CandidateSelected</tp:member-ref> signal.
+      </tp:docstring>
     </property>
 
     <method name="SetSelectedCandidate"
-        tp:name-for-bindings="Set_Selected_Candidate">
+      tp:name-for-bindings="Set_Selected_Candidate">
+      <tp:docstring>
+        Set the value of
+        <tp:member-ref>CandidateSelected</tp:member-ref>.
+      </tp:docstring>
       <arg name="Candidate"
         type="(usqa{sv})" tp:type="Candidate" direction="in">
         <tp:docstring>
+          The candidate that has been selected.
         </tp:docstring>
       </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+      </tp:possible-errors>
     </method>
 
     <property name="StreamState" tp:name-for-bindings="Stream_State"
       type="u" tp:type="Media_Stream_State"
       access="read">
+      <tp:docstring>
+        The stream state of the endpoint.
+      </tp:docstring>
     </property>
 
     <signal name="StreamStateChanged"
-        tp:name-for-bindings="Stream_State_Changed">
-      <arg name="state"
-      type="u" tp:type="Media_Stream_State"/>
+      tp:name-for-bindings="Stream_State_Changed">
+      <tp:docstring>
+        Emitted when the <tp:member-ref>StreamState</tp:member-ref>
+        property changes.
+      </tp:docstring>
+      <arg name="state" type="u" tp:type="Media_Stream_State">
+        <tp:docstring>
+          The new <tp:member-ref>StreamState</tp:member-ref> value.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <method name="SetStreamState"
-        tp:name-for-bindings="Set_Stream_State">
-      <arg name="State" type="u" tp:type="Media_Stream_State"
-        direction="in" />
+      tp:name-for-bindings="Set_Stream_State">
+      <tp:docstring>
+        Change the <tp:member-ref>StreamState</tp:member-ref> of the
+        endpoint.
+      </tp:docstring>
+      <arg direction="in" name="State" type="u" tp:type="Media_Stream_State">
+        <tp:docstring>
+          The requested stream state.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+      </tp:possible-errors>
     </method>
 
     <property name="Transport" tp:name-for-bindings="Transport"
-        type="u" tp:type="Stream_Transport_Type" access="read">
+      type="u" tp:type="Stream_Transport_Type" access="read">
+      <tp:docstring>
+        The transport type for the stream endpoint.
+      </tp:docstring>
     </property>
 
   </interface>
diff --git a/spec/Call_Stream_Interface_Media.xml b/spec/Call_Stream_Interface_Media.xml
index b1b9e19..3d4fb13 100644
--- a/spec/Call_Stream_Interface_Media.xml
+++ b/spec/Call_Stream_Interface_Media.xml
@@ -1,8 +1,8 @@
 <?xml version="1.0" ?>
 <node name="/Call_Stream_Interface_Media"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-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
@@ -23,30 +23,35 @@
   <interface name="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT"
       tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Stream"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Stream.DRAFT"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       [FIXME]
     </tp:docstring>
 
-    <tp:method name="SetCredentials" tp:name-for-bindings="Set_Credentials">
-      <tp:docstring>
-        Used to set the username fragment and password for streams that have
-        global credentials.
-
-        <tp:rationale>
-          [FIXME: rationale?]
-        </tp:rationale>
+    <method name="SetCredentials" tp:name-for-bindings="Set_Credentials">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Used to set the username fragment and password for streams that have
+          global credentials.</p>
       </tp:docstring>
-      <arg name="Username" type="s" direction="in"/>
-      <arg name="Password" type="s" direction="in" />
-    </tp:method>
+      <arg name="Username" type="s" direction="in">
+        <tp:docstring>
+          The username to use when authenticating on the stream.
+        </tp:docstring>
+      </arg>
+      <arg name="Password" type="s" direction="in">
+        <tp:docstring>
+          The password to use when authenticating on the stream.
+        </tp:docstring>
+      </arg>
+    </method>
 
     <tp:mapping name="Candidate_Info">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        Extra information about the candidate. Allowed and mandatory keys
-        depend on the transport protocol used. The following keys are commenly
-        used:
+        <p>Extra information about the candidate. Allowed and mandatory keys
+          depend on the transport protocol used. The following keys are commenly
+          used:</p>
+
         <dl>
           <dt>Type (u)</dt>
           <dd>type of candidate (host, srflx, prflx, relay)</dd>
@@ -78,41 +83,39 @@
       </tp:docstring>
       <tp:member name="Key" type="s">
         <tp:docstring>One of the well-known keys documented here, or an
-          implementation-specific key</tp:docstring>
+          implementation-specific key.</tp:docstring>
       </tp:member>
       <tp:member name="Value" type="v">
-        <tp:docstring>The value corresponding to that key</tp:docstring>
+        <tp:docstring>The value corresponding to that key.</tp:docstring>
       </tp:member>
     </tp:mapping>
 
     <tp:struct name="Candidate" array-name="Candidate_List">
-      <tp:docstring>A Stream Candidate</tp:docstring>
-
+      <tp:docstring>A Stream Candidate.</tp:docstring>
       <tp:member name="Component" type="u">
-        <tp:docstring>The component number</tp:docstring>
+        <tp:docstring>The component number.</tp:docstring>
       </tp:member>
       <tp:member name="IP" type="s">
-        <tp:docstring>The IP address to use</tp:docstring>
+        <tp:docstring>The IP address to use.</tp:docstring>
       </tp:member>
       <tp:member name="Port" type="q">
-        <tp:docstring>The port number to use</tp:docstring>
+        <tp:docstring>The port number to use.</tp:docstring>
       </tp:member>
       <tp:member name="Info" type="a{sv}" tp:type="Candidate_Info">
-        <tp:docstring>Additional information about the candidate</tp:docstring>
+        <tp:docstring>Additional information about the candidate.</tp:docstring>
       </tp:member>
     </tp:struct>
 
     <method name="AddCandidates" tp:name-for-bindings="Add_Candidates">
       <tp:docstring>
-        Add candidates to <tp:member-ref>LocalCandidates</tp:member-ref>
-        and signal them to the remote contact(s).
+        Add candidates to the
+        <tp:member-ref>LocalCandidates</tp:member-ref> property and
+        signal them to the remote contact(s).
       </tp:docstring>
-
-      <arg name="candidates" direction="in"
+      <arg name="Candidates" direction="in"
         type="a(usqa{sv})" tp:type="Candidate[]">
         <tp:docstring>
-          Candidates to be appended to
-          <tp:member-ref>LocalCandidates</tp:member-ref>
+          The candidates to be added.
         </tp:docstring>
       </arg>
     </method>
@@ -120,43 +123,34 @@
     <method name="CandidatesPrepared"
       tp:name-for-bindings="Candidates_Prepared">
       <tp:docstring>
-        This indicates to the CM that the initial batch of candidates has been
-        added.
-
-        <tp:rationale>
-          [FIXME: rationale]
-        </tp:rationale>
+        This indicates to the CM that the initial batch of candidates
+        has been added.
       </tp:docstring>
     </method>
 
     <tp:enum type="u" name="Stream_Transport_Type">
+      <tp:changed version="0.21.2">WLM_8_5 was removed</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         A transport that can be used for streaming.
       </tp:docstring>
-
       <tp:enumvalue suffix="Raw_UDP" value="0">
         <tp:docstring>
           Raw UDP, with or without STUN. All streaming clients are assumed to
           support this transport, so there is no handler capability token for
-          it in the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type"
-            >Call.DRAFT</tp:dbus-ref> interface.
+          it in the <tp:dbus-ref namespace="ofdT.Channel.Type"
+          >Call.DRAFT</tp:dbus-ref> interface.
           [This corresponds to "none" or "stun" in the old Media.StreamHandler
           interface.]
         </tp:docstring>
       </tp:enumvalue>
-
       <tp:enumvalue suffix="ICE" value="1">
         <tp:docstring>
-          Interactive Connectivity Establishment, as defined by the IETF MMUSIC
-          working group.
-          [FIXME: do we want this to cover both ICE-UDP and ICE-TCP, or split
-          them?]
-          [This corresponds to "ice-udp" in the old Media.StreamHandler
-          interface.]
+          Interactive Connectivity Establishment, as defined by RFC
+          5245. Note that this value covers ICE-UDP only.
+          [This corresponds to "ice-udp" in the old
+          Media.StreamHandler interface.]
         </tp:docstring>
       </tp:enumvalue>
-
       <tp:enumvalue suffix="GTalk_P2P" value="2">
         <tp:docstring>
           Google Talk peer-to-peer connectivity establishment, as implemented
@@ -165,17 +159,7 @@
           interface.]
         </tp:docstring>
       </tp:enumvalue>
-
-      <tp:enumvalue suffix="WLM_8_5" value="3">
-        <tp:docstring>
-          The transport used by Windows Live Messenger 8.5 or later, which
-          resembles ICE draft 6.
-          [This corresponds to "wlm-8.5" in the old Media.StreamHandler
-          interface.]
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="WLM_2009" value="4">
+      <tp:enumvalue suffix="WLM_2009" value="3">
         <tp:docstring>
           The transport used by Windows Live Messenger 2009 or later, which
           resembles ICE draft 19.
@@ -183,79 +167,100 @@
           interface.]
         </tp:docstring>
       </tp:enumvalue>
+      <tp:enumvalue suffix="SHM" value="4">
+        <tp:added version="0.21.2"/>
+        <tp:docstring>
+          Shared memory transport, as implemented by the GStreamer
+          shmsrc and shmsink plugins.
+        </tp:docstring>
+      </tp:enumvalue>
     </tp:enum>
 
     <property name="Transport" tp:name-for-bindings="Transport"
-        type="u" tp:type="Stream_Transport_Type" access="read">
+        type="u" tp:type="Stream_Transport_Type" access="read" tp:immutable="yes">
       <tp:docstring>
-        The transport for this stream. This property is immutable.
+        The transport for this stream.
       </tp:docstring>
     </property>
 
     <property name="LocalCandidates" tp:name-for-bindings="Local_Candidates"
       type="a(usqa{sv})" tp:type="Candidate[]" access="read">
       <tp:docstring>
-        [FIXME]. Change notification is via
-        <tp:member-ref>LocalCandidatesAdded</tp:member-ref>.
+        [FIXME]. Change notification is via the
+        <tp:member-ref>LocalCandidatesAdded</tp:member-ref> signal.
       </tp:docstring>
     </property>
 
     <signal name="LocalCandidatesAdded"
       tp:name-for-bindings="Local_Candidates_Added">
       <tp:docstring>
-        Emitted when local candidates are added to
-        <tp:member-ref>LocalCandidates</tp:member-ref>.
+        Emitted when local candidates are added to the
+        <tp:member-ref>LocalCandidates</tp:member-ref> property.
       </tp:docstring>
-
-      <arg name="Candidates"
-        type="a(usqa{sv})" tp:type="Candidate[]">
+      <arg name="Candidates" type="a(usqa{sv})" tp:type="Candidate[]">
         <tp:docstring>
-          Candidates that have been appended to
-          <tp:member-ref>LocalCandidates</tp:member-ref>
+          Candidates that have been added.
         </tp:docstring>
       </arg>
     </signal>
 
     <tp:struct name="Stream_Credentials">
-      <tp:docstring>A username/password pair.</tp:docstring>
+      <tp:docstring>A username and password pair.</tp:docstring>
 
       <tp:member name="Username" type="s">
-        <tp:docstring>The username</tp:docstring>
+        <tp:docstring>The username.</tp:docstring>
       </tp:member>
 
       <tp:member name="Password" type="s">
-        <tp:docstring>The password</tp:docstring>
+        <tp:docstring>The password.</tp:docstring>
       </tp:member>
     </tp:struct>
 
     <property name="LocalCredentials" tp:name-for-bindings="Local_Credentials"
       type="(ss)" tp:type="Stream_Credentials" access="read">
       <tp:docstring>
-        [FIXME]. Change notification is via
-        <tp:member-ref>LocalCredentialsSet</tp:member-ref>.
+        [FIXME]. Change notification is via the
+        <tp:member-ref>LocalCredentialsChanged</tp:member-ref> signal.
       </tp:docstring>
-
     </property>
 
-    <signal name="LocalCredentialsSet"
-      tp:name-for-bindings="Local_Credentials_Set">
+    <signal name="LocalCredentialsChanged"
+      tp:name-for-bindings="Local_Credentials_Changed">
+      <tp:changed version="0.21.2">renamed from LocalCredentailsSet</tp:changed>
       <tp:docstring>
         Emitted when the value of
         <tp:member-ref>LocalCredentials</tp:member-ref> changes.
       </tp:docstring>
-
       <arg name="Username" type="s" />
       <arg name="Password" type="s" />
     </signal>
 
+    <signal name="RelayInfoChanged"
+      tp:name-for-bindings="Relay_Info_Changed">
+      <tp:docstring>
+        Emitted when the value of
+        <tp:member-ref>RelayInfo</tp:member-ref> changes.
+      </tp:docstring>
+      <arg name="Relay_Info" type="aa{sv}" tp:type="String_Variant_Map[]" />
+    </signal>
+
+    <signal name="STUNServersChanged"
+      tp:name-for-bindings="STUN_Servers_Changed">
+      <tp:docstring>
+        Emitted when the value of
+        <tp:member-ref>STUNServers</tp:member-ref> changes.
+      </tp:docstring>
+      <arg name="Servers" type="a(sq)" tp:type="Socket_Address_IP[]" />
+    </signal>
+
     <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
       type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
-      <tp:docstring>
-        The IP addresses of possible STUN servers to use for NAT traversal, as
-        dotted-quad IPv4 address literals or RFC2373 IPv6 address literals.
-        This property cannot change once the stream has been created, so there
-        is no change notification. The IP addresses MUST NOT be given as DNS
-        hostnames.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The IP addresses of possible STUN servers to use for NAT
+          traversal, as dotted-quad IPv4 address literals or RFC2373
+          IPv6 address literals.  Change notification is via the
+          <tp:member-ref>STUNServersChanged</tp:member-ref>
+          signal. The IP addresses MUST NOT be given as DNS hostnames.</p>
 
         <tp:rationale>
           High-quality connection managers already need an asynchronous
@@ -334,7 +339,11 @@
           if Transport is GTalk_P2P, this is a Google relay server;
           otherwise, the meaning of RelayInfo is undefined.</p>
 
-        <p>If relaying is not possible for this stream, the list is empty.</p>
+        <p>If relaying is not possible for this stream, the list is
+          empty.</p>
+
+        <p>Change notification is given via the
+          <tp:member-ref>RelayInfoChanged</tp:member-ref> signal.</p>
       </tp:docstring>
     </property>
 
@@ -343,40 +352,38 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Signals that the initial information about STUN and Relay servers
           has been retrieved, i.e. the
-          <tp:member-ref>RetrievedServerInfo</tp:member-ref> property is now
-          true.</p>
+          <tp:member-ref>HasServerInfo</tp:member-ref> property is
+          now true.</p>
       </tp:docstring>
     </signal>
 
-    <property name="RetrievedServerInfo" type="b"
-        tp:name-for-bindings="Retrieved_Server_Info" access="read">
+    <property name="HasServerInfo" type="b"
+        tp:name-for-bindings="Has_Server_Info" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>True if the initial information about STUN servers and Relay servers
-          has been retrieved. Change notification is via the
+        <p>True if all the initial information about STUN servers and Relay
+          servers has been retrieved. Change notification is via the
           <tp:member-ref>ServerInfoRetrieved</tp:member-ref> signal.</p>
 
         <tp:rationale>
-          <p>Streaming implementations that can't cope with STUN and relay
-            servers being added later SHOULD wait for this property
-            to become true before proceeding.</p>
+          Streaming implementations that can't cope with STUN and
+          relay servers being added later SHOULD wait for this
+          property to become true before proceeding.
         </tp:rationale>
       </tp:docstring>
     </property>
 
     <signal name="EndpointsChanged"
-        tp:name-for-bindings="Endpoints_Changed">
+      tp:name-for-bindings="Endpoints_Changed">
       <tp:docstring>
         Emitted when the <tp:member-ref>Endpoints</tp:member-ref> property
         changes.
       </tp:docstring>
-
-      <arg name="EndpointsAdded" type="ao">
+      <arg name="Endpoints_Added" type="ao">
         <tp:docstring>
           Endpoints that were added.
         </tp:docstring>
       </arg>
-
-      <arg name="EndpointsRemoved" type="ao">
+      <arg name="Endpoints_Removed" type="ao">
         <tp:docstring>
           Endpoints that no longer exist.
         </tp:docstring>
@@ -386,12 +393,9 @@
     <property name="Endpoints" tp:name-for-bindings="Endpoints"
       type="ao" access="read">
       <tp:docstring>
-        <p> The list of endpoints
-           <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Call.Stream"
-              >Endpoint.DRAFT</tp:dbus-ref>
-           that exist for this stream.
-        </p>
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call.Stream"
+          >Endpoint.DRAFT</tp:dbus-ref> objects that exist for this
+          stream.</p>
 
         <p>Change notification is via the
           <tp:member-ref>EndpointsChanged</tp:member-ref> signal.</p>
diff --git a/spec/Channel.xml b/spec/Channel.xml
index 897b683..b1772d7 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 0000000..701b424
--- /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_Dispatcher_Interface_Operation_List.xml b/spec/Channel_Dispatcher_Interface_Operation_List.xml
index d61123f..be06f5c 100644
--- a/spec/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/spec/Channel_Dispatcher_Interface_Operation_List.xml
@@ -66,7 +66,7 @@
 
           <tp:rationale>
             <p>The rationale is the same as for
-              <tp:type-ref>Channel_Details</tp:type-ref>.</p>
+              <tp:type>Channel_Details</tp:type>.</p>
           </tp:rationale>
 
           <p>Each dictionary MUST contain at least the following keys:</p>
@@ -108,7 +108,7 @@
         type="a{sv}" tp:type="Qualified_Property_Value_Map">
         <tp:docstring>
           The same properties that would appear in the Properties member of
-          <tp:type-ref>Dispatch_Operation_Details</tp:type-ref>.
+          <tp:type>Dispatch_Operation_Details</tp:type>.
         </tp:docstring>
       </arg>
     </signal>
diff --git a/spec/Channel_Interface_Addressing.xml b/spec/Channel_Interface_Addressing.xml
new file mode 100644
index 0000000..494fd7b
--- /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_Call_State.xml b/spec/Channel_Interface_Call_State.xml
index b569a7f..b0aea59 100644
--- a/spec/Channel_Interface_Call_State.xml
+++ b/spec/Channel_Interface_Call_State.xml
@@ -126,6 +126,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           outgoing call has reached a gateway, for instance.
         </tp:docstring>
       </tp:flag>
+
+      <tp:flag suffix="Conference_Host" value="32">
+        <tp:added version='0.19.11'/>
+        <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>
 
   </interface>
diff --git a/spec/Channel_Interface_Conference.xml b/spec/Channel_Interface_Conference.xml
index 92d962d..abda59e 100644
--- a/spec/Channel_Interface_Conference.xml
+++ b/spec/Channel_Interface_Conference.xml
@@ -20,16 +20,18 @@
       02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.0">(draft 1)</tp:added>
+    name="org.freedesktop.Telepathy.Channel.Interface.Conference">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:requires
       interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can "continue
-        from" one or more individual channels.</p>
+        from" one or more individual channels. This could be used to invite
+        other contacts to an existing 1-1 text conversation, combine two phone
+        calls into one conference call, and so on, with roughly the same API in
+        each case.</p>
 
       <tp:rationale>
         <p>This interface addresses freedesktop.org <a
@@ -37,71 +39,45 @@
             #24906</a> (GSM-compatible conference calls) and <a
             href="http://bugs.freedesktop.org/show_bug.cgi?id=24939">bug
             #24939</a> (upgrading calls and chats to multi-user).
-          See those bugs for rationale and use cases.</p>
-
-        <p>Examples of usage:</p>
-
-        <p>Active and held GSM calls C1, C2 can be merged into a single
-          channel Cn with the Conference interface, by calling
-          <code>CreateChannel({...ChannelType: ...Call,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]})</code>
-          which returns Cn.</p>
-
-        <p>An XMPP 1-1 conversation C1 can be continued in a newly created
-          multi-user chatroom Cn by calling
-          <code>CreateChannel({...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns Cn.</p>
-
-        <p>An XMPP 1-1 conversation C1 can be continued in a specified
-          multi-user chatroom by calling
-          <code>CreateChannel({...ChannelType: ...Text, ...HandleType: ROOM,
-            ...TargetID: 'telepathy@conf.example.com',
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns a Conference channel.</p>
-
-        <p>Either of the XMPP cases could work for Call channels, to
-          upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
-          could in principle work for link-local XMPP (XEP-0174).</p>
-
-        <p>The underlying switchboard representing an MSN 1-1 conversation C1
-          with a contact X can be moved to a representation as a nameless
-          chatroom, Cn, to which more contacts can be invited, by calling
-          <code>CreateChannel({...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1]})</code>
-          which returns Cn. C1 SHOULD remain open, with no underlying
-          switchboard attached. If X establishes a new switchboard with the
-          local user, C1 SHOULD pick up that switchboard rather than letting
-          it create a new channel.
-          <strong>[FIXME: should it?]</strong>
-          Similarly, if the local user sends a message in C1, then
-          a new switchboard to X should be created and associated with C1.</p>
-
-        <p>XMPP and MSN do not natively have a concept of merging two or more
-          channels C1, C2... into one channel, Cn. However, the GSM-style
-          merging API can be supported on XMPP and MSN, as an API short-cut
-          for upgrading C1 into a conference Cn (which invites the
-          TargetHandle of C1 into Cn), then immediately inviting the
-          TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
-
-        <p>With a suitable change of terminology, Skype has behaviour similar
-          to MSN.</p>
+          See those bugs for more rationale and use cases.</p>
       </tp:rationale>
 
+      <p>Existing channels are upgraded by requesting a new channel of the same
+        <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>,
+        listing the channels to be merged into the new conference in the
+        <tp:member-ref>InitialChannels</tp:member-ref> property of the request.
+        If <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
+        <var>Allowed_Properties</var> in <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>,
+        ad-hoc conferences to a set of contacts may be created by requesting a
+        channel, specifying
+        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and/or
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> to be the contacts in
+        question. A request may specify these alongside
+        <tp:member-ref>InitialChannels</tp:member-ref>, to simultaneously
+        upgrade a channel to a conference and invite others to join it.</p>
+
+      <p>Channels with this interface MAY also implement <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>MergeableConference.DRAFT</tp:dbus-ref>
+        to support merging more 1-1 channels into an ongoing conference.
+        Similarly, 1-1 channels MAY implement <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>Splittable.DRAFT</tp:dbus-ref> to
+        support being broken out of a Conference channel.</p>
+
       <p>The <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Group</tp:dbus-ref> MAY have channel-specific handles for participants;
-        clients SHOULD support both Conferences that have channel-specific handles,
-        and those that do not.</p>
+          >Group</tp:dbus-ref> interface on Conference channels MAY use
+          channel-specific handles for participants; clients SHOULD support
+          both Conferences that have channel-specific handles, and those that
+          do not.</p>
 
       <tp:rationale>
         <p>In the GSM case, the Conference's Group interface MAY have
-          channel-specific handles, to reflect the fact that the identities of
-          the participants might not be known - it can be possible to know that
-          there is another participant in the Conference, but not know who
-          they are.
-          <strong>[FIXME: fact check from GSM gurus needed]</strong>
-        </p>
+          channel-specific handles, to represent the fact that the same
+          phone number may be in a conference twice (for instance, it could be
+          the number of a corporate switchboard).</p>
 
         <p>In the XMPP case, the Conference's Group interface SHOULD have
           channel-specific handles, to reflect the fact that the participants
@@ -132,6 +108,164 @@
           be misleading.</p>
       </tp:rationale>
 
+      <h4>Examples of usage</h4>
+
+      <p>A pair of 1-1 GSM calls <var>C1</var> and <var>C2</var> can be merged
+        into a single conference call by calling:</p>
+
+      <blockquote>
+        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...Call,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]
+          })</code>
+      </blockquote>
+
+      <p>which returns a new channel <var>Cn</var> implementing the conference
+        interface. (As a quirk of GSM, both 1-1 will cease to function normally
+        until they are <tp:dbus-ref
+          namespace="ofdT.Channel.Interface.Splittable.DRAFT">Split</tp:dbus-ref>
+        from the conference, or the conference ends.)</p>
+
+      <p>An XMPP 1-1 conversation <var>C3</var> (with
+        <tt>chris@example.com</tt>, say) can be continued in a newly created
+        multi-user chatroom by calling:</p>
+
+      <blockquote>
+        <code>CreateChannel({
+            ...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
+          })</code>
+      </blockquote>
+
+      <p>Or, to invite <tt>emily@example.net</tt> to join the newly-created MUC
+        at the same time:</p>
+
+      <blockquote>
+        <code>CreateChannel({
+            ...ChannelType: ...Text,
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3],
+            ...<tp:member-ref>InitialInviteeIDs</tp:member-ref>: ['emily@example.net']
+          })</code>
+      </blockquote>
+
+      <p>To continue <var>C3</var> in a particular multi-user
+        chatroom (rather than the implementation inventing a unique name for
+        the room), call:</p>
+
+      <blockquote>
+        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>({
+            ...ChannelType: ...Text,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: ...Room,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: 'telepathy@conf.example.com',
+            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
+          })</code>
+      </blockquote>
+
+      <p>Note the use of EnsureChannel — if a channel for
+        <tt>telepathy@conf.example.com</tt> is already open, this SHOULD be
+        equivalent to inviting <tt>chris@example.com</tt> to the existing
+        channel.</p>
+
+      <p>In the above cases, the text channel <var>C3</var> SHOULD remain open
+        and fully functional (until explicitly closed by a client); new
+        incoming 1-1 messages from <tt>chris@example.com</tt> SHOULD appear in
+        <var>C3</var>, and messages sent using <var>C3</var> MUST be relayed
+        only to <tt>chris@example.com</tt>.</p>
+
+      <tp:rationale>
+        <p>If there is an open 1-1 text channel with a contact, in every
+          other situation new messages will appear in that channel. Given
+          that the old channel remains open — which is the least surprising
+          behaviour, and eases us towards a beautiful world where channels
+          never close themselves — it stands to reason that it should be
+          where new messages from Chris should appear. On MSN, creating a
+          conference from <var>C3</var> should migrate the underlying
+          switchboard from <var>C3</var> to the new channel; this is an
+          implementation detail, and should not affect the representation on
+          D-Bus. With a suitable change of terminology, Skype has the same
+          behaviour.</p>
+
+        <p>If the current handler of that channel doesn't want this to happen
+          (maybe it transformed the existing tab into the group chat window,
+          and so there'd be no UI element still around to show new messages),
+          then it should just <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> the
+          old 1-1 channel; it'll respawn if necessary.</p>
+      </tp:rationale>
+
+      <p>Either of the XMPP cases could work for Call channels, to
+        upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
+        could in principle work for link-local XMPP (XEP-0174).</p>
+
+      <p>XMPP and MSN do not natively have a concept of merging two or more
+        channels C1, C2... into one channel, Cn. However, the GSM-style
+        merging API can be supported on XMPP and MSN, as an API short-cut
+        for upgrading C1 into a conference Cn (which invites the
+        TargetHandle of C1 into Cn), then immediately inviting the
+        TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
+
+      <h4>Sample <tp:dbus-ref namespace='ofdT.Connection.Interface.Requests'
+                             >RequestableChannelClasses</tp:dbus-ref></h4>
+
+      <p>A GSM connection might advertise the following channel class for
+        conference calls:</p>
+
+      <blockquote>
+        <code>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref><br/>
+  },<br/>
+  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:dbus-ref namespace='ofdT.Channel.Type.StreamedMedia'
+                          >InitialAudio</tp:dbus-ref>
+            ]<br/>
+)
+        </code>
+      </blockquote>
+
+      <p>This indicates support for starting audio-only conference calls by
+        merging two or more existing channels (since
+        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are not allowed).</p>
+
+      <p>An XMPP connection might advertise the following classes for ad-hoc
+        multi-user text chats:</p>
+
+      <blockquote>
+        <code>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref><br/>
+  },<br/>
+  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
+              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
+              <tp:member-ref>InvitationMessage</tp:member-ref>
+            ]<br/>
+),<br/>
+( Fixed = {<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+      Room<br/>
+  },<br/>
+  Allowed = [ <tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
+              <tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref>,<br/>
+              <tp:member-ref>InitialChannels</tp:member-ref>,
+              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
+              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
+              <tp:member-ref>InvitationMessage</tp:member-ref>
+            ]<br/>
+)
+        </code>
+      </blockquote>
+
+      <p>The first class indicates support for starting ad-hoc (nameless) chat
+        rooms, upgraded from existing 1-1 channels and/or inviting new
+        contacts, along with a message to be sent along with the invitations.
+        The second indicates support for upgrading to a particular named chat
+        room.</p>
     </tp:docstring>
 
     <property name="Channels" tp:name-for-bindings="Channels"
@@ -145,10 +279,18 @@
               namespace="org.freedesktop.Telepathy.Channel"
               >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
 
-        <p>This property MUST NOT be requestable.
-          <strong>[FIXME: or would it be better for this one, and not IC, to be
-            requestable?]</strong>
-        </p>
+        <p>This property MUST NOT be requestable; instead, the
+          <tp:member-ref>InitialChannels</tp:member-ref> property may be
+          specified when requesting a channel.</p>
+
+        <tp:rationale>
+          <p>This is consistent with requesting
+            <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+            <tp:member-ref>InitialInviteeIDs</tp:member-ref>, rather than
+            requesting <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.Members</tp:dbus-ref>
+            and some hypothetical ID version of that property.</p>
+       </tp:rationale>
 
         <p>Change notification is via the
           <tp:member-ref>ChannelMerged</tp:member-ref> and
@@ -166,6 +308,22 @@
         <tp:docstring>The channel that was added to
           <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
       </arg>
+
+      <arg name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
+        <tp:docstring>A new channel-specific handle for the <tp:dbus-ref
+          namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> of
+          <var>Channel</var>, as will appear in
+          <tp:member-ref>OriginalChannels</tp:member-ref>, or <tt>0</tt> if a
+          global handle is used for
+          <var>Channel</var>'s TargetHandle on the <tp:dbus-ref
+            namespace="ofdT.Channel.Interface">Group</tp:dbus-ref> interface
+          of this channel.</tp:docstring>
+      </arg>
+
+      <arg name="Properties" type="a{sv}"
+           tp:type="Qualified_Property_Value_Map">
+        <tp:docstring><var>Channel</var>'s immutable properties.</tp:docstring>
+      </arg>
     </signal>
 
     <signal name="ChannelRemoved" tp:name-for-bindings="Channel_Removed">
@@ -176,35 +334,50 @@
             namespace="org.freedesktop.Telepathy.Channel.Interface"
             >Splittable.DRAFT.Split</tp:dbus-ref> method.</p>
 
-        <p><strong>[FIXME: relative ordering of this vs. Closed? Do we
-            care?]</strong></p>
+        <p>If a channel is removed because it was closed, <tp:dbus-ref
+          namespace='ofdT.Channel'>Closed</tp:dbus-ref> should be emitted
+          before this signal.</p>
       </tp:docstring>
 
       <arg name="Channel" type="o">
         <tp:docstring>The channel that was removed from
           <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
       </arg>
+
+      <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Additional information about the removal, which may include
+          the same well-known keys as the Details argument of
+          <tp:dbus-ref namespace="ofdT.Channel.Interface.Group"
+            >MembersChangedDetailed</tp:dbus-ref>, with the same semantics.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <property name="InitialChannels" tp:name-for-bindings="Initial_Channels"
-      access="read" type="ao">
+      access="read" type="ao" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The initial value of <tp:member-ref>Channels</tp:member-ref>.</p>
 
         <p>This property SHOULD be requestable. Omitting it from a request is
           equivalent to providing it with an empty list as value. Requests
-          where its value has at least two elements SHOULD be expected to
-          succeed on any implementation of this interface.</p>
-
-        <p>Whether a request with 0 or 1 elements in the list will succeed is
-          indicated by <tp:member-ref>SupportsNonMerges</tp:member-ref>.</p>
+          where its value has at least two channel paths SHOULD be expected to
+          succeed on any implementation of this interface. If
+          <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
+          <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
+          <var>Allowed_Properties</var> in <tp:dbus-ref
+            namespace='ofdT.Connection.Interface.Requests'
+            >RequestableChannelClasses</tp:dbus-ref>, then requests with zero
+          or one channel paths SHOULD also succeed; otherwise, clients SHOULD
+          NOT make requests with zero or one paths for this property.</p>
 
         <tp:rationale>
-          <p>In GSM, a pair of calls can be merged into a conference. In XMPP
-            and MSN, you can create a new chatroom, or upgrade one 1-1 channel
-            into a chatroom; however, on these protocols, it is also possible
-            to fake GSM-style merging by upgrading the first channel, then
-            inviting the targets of all the other channels into it.</p>
+          <p>In GSM, a pair of calls can be merged into a conference, but you
+            can't start a conference call from zero or one existing calls. In
+            XMPP and MSN, you can create a new chatroom, or upgrade one 1-1
+            channel into a chatroom; however, on these protocols, it is also
+            possible to fake GSM-style merging by upgrading the first channel,
+            then inviting the targets of all the other channels into it.</p>
         </tp:rationale>
 
         <p>If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD
@@ -213,9 +386,7 @@
           them in this property's value or by calling
           <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.
-          <strong>[FIXME: there's nothing in RequestableChannelClasses yet
-            to say what will happen, see #24906 comment 6]</strong></p>
+            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.</p>
 
         <tp:rationale>
           <p>In Jingle, nothing special will happen to merged calls. UIs MAY
@@ -223,10 +394,6 @@
             the desired behaviour; this SHOULD always work. Not doing
             an implicit hold/unhold seems to preserve least-astonishment.</p>
 
-          <p><strong>[FIXME: check whether ring supports faking Hold on both
-              channels, as it probably should: see #24906 comment 6]</strong>
-          </p>
-
           <p>In GSM, the calls that are merged go into a state similar to
             Hold, but they cannot be unheld, only split from the conference
             call using <tp:dbus-ref namespace="org.freedesktop.Telepathy"
@@ -246,25 +413,32 @@
             we arbitrarily mandate that it SHOULD choose the first channel in
             the list as the one to continue.</p>
         </tp:rationale>
-
-        <p>This property is immutable.</p>
       </tp:docstring>
     </property>
 
     <property name="InitialInviteeHandles"
       tp:name-for-bindings="Initial_Invitee_Handles"
-      access="read" type="au" tp:type="Contact_Handle[]">
+      access="read" type="au" tp:type="Contact_Handle[]" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of additional contacts invited to this conference when it
           was created.</p>
 
-        <p>This property SHOULD be requestable, and appear in the allowed
+        <p>If it is possible to invite new contacts when creating a conference
+          (as opposed to merging several channels into one new conference
+          channel), this property SHOULD be requestable, and appear in the allowed
           properties in <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-            >RequestableChannelClasses</tp:dbus-ref>, in all connection
-          managers that can implement its semantics (in practice, this is
-          likely to mean exactly those connection managers where
-          <tp:member-ref>SupportsNonMerges</tp:member-ref> will be true).</p>
+            >RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property
+          SHOULD NOT be requestable, and its value SHOULD always be the empty
+          list.</p>
+
+        <tp:rationale>
+          <p>On GSM you have to place a 1-1 call before you can merge it into a
+            conference; on the other hand, you can invite new contacts to XMPP
+            Muji calls and XMPP/MSN/Skype ad-hoc chat rooms without starting a
+            1-1 channel with them first.</p>
+        </tp:rationale>
 
         <p>If included in a request, the given contacts are automatically
           invited into the new channel, as if they had been added with
@@ -285,8 +459,6 @@
           property, together with any other contacts invited at the same time
           (if that information is known).</p>
 
-        <p>This property is immutable.</p>
-
         <p>InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be
           combined in a single request.</p>
 
@@ -321,13 +493,13 @@
 
     <property name="InitialInviteeIDs"
       tp:name-for-bindings="Initial_Invitee_IDs"
-      access="read" type="as">
+      access="read" type="as" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of additional contacts invited to this conference when it
           was created.</p>
 
-        <p>This property SHOULD be requestable as an alternative to, or
-          combined with, <tp:member-ref>InitialInviteeHandles</tp:member-ref>.
+        <p>This property SHOULD be requestable if and only if
+          <tp:member-ref>InitialInviteeHandles</tp:member-ref> is requestable.
           Its semantics are the same, except that it takes a list of the
           string representations of contact handles; invitations are sent to
           any contact present in either or both of these properties.</p>
@@ -337,13 +509,11 @@
           means that the value of InitialInviteeIDs will include the TargetID
           of each channel in InitialChannels, and the ID corresponding to each
           handle in InitialInviteeHandles.</p>
-
-        <p>This property is immutable.</p>
       </tp:docstring>
     </property>
 
     <property name="InvitationMessage" tp:name-for-bindings="Invitation_Message"
-      access="read" type="s">
+      access="read" type="s" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The message that was sent to the
           <tp:member-ref>InitialInviteeHandles</tp:member-ref> when they were
@@ -364,65 +534,95 @@
         <p>If the local user was not the initiator of this channel, the
           message with which they were invited (if any) SHOULD appear in the
           value of this property.</p>
-
-        <p>This property is immutable.</p>
       </tp:docstring>
     </property>
 
-    <property name="SupportsNonMerges"
-      tp:name-for-bindings="Supports_Non_Merges"
-      access="read" type="b">
+    <property name="OriginalChannels" tp:name-for-bindings="Original_Channels"
+              type="a{uo}" tp:type="Channel_Originator_Map"
+              access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p><strong>[FIXME: needs a better name; or perhaps it could be implied
-            by InitialInviteeHandles being requestable in XMPP/MSN but not in
-            GSM?]</strong></p>
-
-        <p>If true, requests with <tp:member-ref>InitialChannels</tp:member-ref>
-          omitted, empty, or one element long should be expected to succeed.</p>
-
-        <p>This property SHOULD appear in <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-              >RequestableChannelClasses</tp:dbus-ref> for
-          conference channels if and only if its value on those channels will
-          be true.</p>
+        <p>On GSM conference calls, it is possible to have the same phone
+          number in a conference twice; for instance, it could be the number of
+          a corporate switchboard. This is represented using channel-specific
+          handles; whether or not a channel uses channel-specific handles is
+          reported in <tp:dbus-ref
+          namespace='ofdT.Channel.Interface'>Group.GroupFlags</tp:dbus-ref>.
+          The <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref>
+          property specifies the mapping from opaque channel-specific handles
+          to actual numbers; this property specifies the original 1-1 channel
+          corresponding to each channel-specific handle in the conference.</p>
+
+        <p>In protocols where this situation cannot arise, such as XMPP,
+          this property MAY remain empty.</p>
+
+        <p>For example, consider this situation:</p>
+
+        <ol>
+          <li>Place a call (with path <tt>/call/to/simon</tt>) to the contact
+            <tt>+441234567890</tt> (which is assigned the handle <var>h</var>,
+            say), and ask to be put through to Simon McVittie;</li>
+          <li>Put that call on hold;</li>
+          <li>Place another call (with path <tt>/call/to/jonny</tt>) to
+            <tt>+441234567890</tt>, and ask to be put
+            through to Jonny Lamb;</li>
+          <li>Request a new channel with
+            <tp:member-ref>InitialChannels</tp:member-ref>:
+            <tt>['/call/to/simon', '/call/to/jonny']</tt>.</li>
+        </ol>
+
+        <p>The new channel will have the following properties, for some handles
+          <var>s</var> and <var>j</var>:</p>
+
+        <blockquote>
+          <code>{<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>:
+                Channel_Specific_Handles | (other flags),<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>:
+                [self_handle, s, j],<br/>
+            ...<tp:dbus-ref
+              namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>:
+                { s: h, j: h },<br/>
+            ...<tp:member-ref>InitialChannels</tp:member-ref>:
+                ['/call/to/simon', '/call/to/jonny'],<br/>
+            ...<tp:member-ref>Channels</tp:member-ref>:
+                ['/call/to/simon', '/call/to/jonny'],<br/>
+            ...<tp:member-ref>OriginalChannels</tp:member-ref>:
+                { s: '/call/to/simon', j: '/call/to/jonny' },<br/>
+            # ...standard properties like ChannelType: Group elided...<br/>
+          }</code>
+        </blockquote>
 
-        <tp:rationale>
-          <p>Putting this in <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-              >RequestableChannelClasses</tp:dbus-ref> means clients can find
-            out whether their request will succeed early enough to do
-            something about it.</p>
-
-          <p>In XMPP, you can request a channel of type ROOM without
-            incorporating any 1-1 chats at all - indeed, this is the normal
-            way to do it - or as a continuation of a single 1-1 chat, and then
-            invite other people in later.</p>
-
-          <p>The sense of this property is a bit awkward, but it avoids making it
-            an anti-capability. If the sense were inverted, then its presence in
-            RequestableChannelClasses would imply that the protocol <em>lacks</em>
-            a feature; as it stands, it is additive. (Contrast with
-            <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"
-              >ImmutableStreams</tp:dbus-ref>, which is the wrong way around for
-            backwards-compatibility reasons.)</p>
-        </tp:rationale>
-
-        <p>If false, <tp:member-ref>InitialChannels</tp:member-ref> SHOULD be
-          supplied in all requests for this channel class, and contain at least
-          two channels. Requests where this requirement is not met SHOULD fail
-          with NotImplemented.
-        </p>
-
-        <tp:rationale>
-          <p>In GSM, you can only make a conference call by merging at least
-            two channels.
-            <strong>[FIXME: the CM could conceivably fake it, but that would be
-              rather nasty]</strong>
-          </p>
-        </tp:rationale>
+        <p>Change notification is via the
+          <tp:member-ref>ChannelMerged</tp:member-ref> and
+          <tp:member-ref>ChannelRemoved</tp:member-ref> signals: if
+          <var>Channel_Specific_Handle</var> in the former is non-zero, this
+          property SHOULD be updated to map that handle to the merged channel's
+          path.</p>
       </tp:docstring>
     </property>
 
+    <tp:mapping name="Channel_Originator_Map">
+      <tp:member name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          A channel-specific handle for a participant in this conference.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Original_Channel" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The object path of <tp:member-ref>Channels</tp:member-ref>
+          representing the original 1-1 channel with
+          <var>Channel_Specific_Handle</var>.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        A mapping from members of a conference to the original 1-1 channel with
+        that contact, if any. See
+        <tp:member-ref>OriginalChannels</tp:member-ref> for details.
+      </tp:docstring>
+    </tp:mapping>
   </interface>
 </node>
diff --git a/spec/Channel_Interface_DTMF.xml b/spec/Channel_Interface_DTMF.xml
index bd20f6e..d74ea6f 100644
--- a/spec/Channel_Interface_DTMF.xml
+++ b/spec/Channel_Interface_DTMF.xml
@@ -19,7 +19,15 @@ 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.DTMF">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+    <tp:xor-requires>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
+    </tp:xor-requires>
+    <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 +38,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 +88,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
@@ -117,22 +129,47 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <method name="MultipleTones" tp:name-for-bindings="Multiple_Tones">
       <tp:added version="0.19.6" />
+      <tp:changed version="0.21.3">The characters [pPxXwW,] must
+        also be supported.</tp:changed>
       <arg direction="in" name="Tones" type="s">
-        <tp:docstring>A string representation of one or more DTMF
-          events.</tp:docstring>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A string representation of one or more DTMF
+            events. Implementations of this method MUST support all of the
+            following characters in this string:</p>
+
+          <ul>
+            <li>the digits 0-9, letters A-D and a-d, and symbols '*' and '#'
+              correspond to the members of <tp:type>DTMF_Event</tp:type></li>
+
+            <li>any of 'p', 'P', 'x', 'X' or ',' (comma) results in an
+              implementation-defined pause, typically for 3 seconds</li>
+
+            <li>'w' or 'W' waits for the user to continue, by stopping
+              interpretation of the string, and if there is more to be played,
+              emitting the <tp:member-ref>TonesDeferred</tp:member-ref> signal
+              with the rest of the string as its argument: see that signal
+              for details</li>
+          </ul>
+        </tp:docstring>
       </arg>
       <tp:docstring>
         <p>Send multiple DTMF events to all eligible streams in the channel.
-        Each character in the Tones string must be a valid DTMF event
-        (as defined by
-        <a href="http://www.rfc-editor.org/rfc/rfc4733.txt">RFC4733</a>).
-        Each tone will be played for a pre-defined number of milliseconds,
-        followed by a pause before the next tone is played.  The
-        duration/pause is defined by the protocol or connection manager.</p>
+        Each tone will be played for an implementation-defined number of
+        milliseconds (typically 250ms), followed by a gap before the next tone
+        is played (typically 100ms). The
+        duration and gap are defined by the protocol or connection manager.</p>
+
         <tp:rationale>
-          In cases where the client knows in advance the tone sequence it wants
-          to send, it's easier to use this method than manually start and stop
-          each tone in the sequence.
+          <p>In cases where the client knows in advance the tone sequence it
+            wants to send, it's easier to use this method than manually start
+            and stop each tone in the sequence.</p>
+
+          <p>The tone and gap lengths may need to vary for interoperability,
+            according to the protocol and other implementations' ability to
+            recognise tones. At the time of writing, GStreamer uses a
+            minimum of 250ms tones and 100ms gaps when playing in-band DTMF
+            in the normal audio stream, or 70ms tones and 50ms gaps when
+            encoding DTMF as <code>audio/telephone-event</code>.</p>
         </tp:rationale>
 
         <p>Tone overlaping or queueing is not supported, so this method can only
@@ -182,6 +219,47 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </property>
 
+    <property name="DeferredTones" tp:name-for-bindings="Deferred_Tones"
+        type="s" access="read">
+      <tp:added version="0.21.3" />
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The tones waiting for the user to continue, if any.</p>
+
+        <p>When this property is set to a non-empty value,
+          <tp:member-ref>TonesDeferred</tp:member-ref> is emitted.
+          When any tones are played (i.e. whenever
+          <tp:member-ref>SendingTones</tp:member-ref> is emitted),
+          this property is reset to the empty string.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="TonesDeferred" tp:name-for-bindings="Tones_Deferred">
+      <tp:added version="0.21.3" />
+      <arg name="Tones" type="s">
+        <tp:docstring>The new non-empty value of
+          <tp:member-ref>DeferredTones</tp:member-ref>.</tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when 'w' or 'W', indicating "wait for the user to continue",
+          is encountered while playing a DTMF string queued by
+          <tp:member-ref>MultipleTones</tp:member-ref> or
+          <tp:member-ref>InitialTones</tp:member-ref>. Any queued DTMF events
+          after the 'w', which have not yet been played, are placed in the
+          <tp:member-ref>DeferredTones</tp:member-ref> property and copied
+          into this signal's argument.</p>
+
+        <p>When the channel handler is ready to continue, it MAY pass the
+          value of <tp:member-ref>DeferredTones</tp:member-ref> to
+          <tp:member-ref>MultipleTones</tp:member-ref>, to resume sending.
+          Alternatively, it MAY ignore the deferred tones, or even play
+          different tones instead. Any deferred tones are discarded the next
+          time a tone is played.</p>
+
+        <p>This signal SHOULD NOT be emitted if there is nothing left to play,
+          i.e. if the 'w' was the last character in the DTMF string.</p>
+      </tp:docstring>
+    </signal>
+
     <signal name="SendingTones" tp:name-for-bindings="Sending_Tones">
       <tp:added version="0.19.6" />
       <arg name="Tones" type="s">
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold.xml
index 1e3a832..ef5a08f 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold.xml
@@ -20,7 +20,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
   <interface name="org.freedesktop.Telepathy.Channel.Interface.Hold">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+    <tp:xor-requires>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
+    </tp:xor-requires>
     <tp:changed version="0.17.4">first API-stable version</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Channel_Interface_Mergeable_Conference.xml b/spec/Channel_Interface_Mergeable_Conference.xml
index 989ffac..cd606c1 100644
--- a/spec/Channel_Interface_Mergeable_Conference.xml
+++ b/spec/Channel_Interface_Mergeable_Conference.xml
@@ -23,7 +23,7 @@
     name="org.freedesktop.Telepathy.Channel.Interface.MergeableConference.DRAFT"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Conference"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can have
@@ -50,11 +50,11 @@
 
         <p>The given channel SHOULD be added to <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT.Channels</tp:dbus-ref> if and only if the
+            >Conference.Channels</tp:dbus-ref> if and only if the
           underlying protocol signals the merge in some way. It MUST NOT be
           added to <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT.InitialChannels</tp:dbus-ref> (to preserve
+            >Conference.InitialChannels</tp:dbus-ref> (to preserve
           immutability).</p>
 
         <tp:rationale>
@@ -82,19 +82,19 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Errors.InvalidArgument">
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
             The given channel isn't suitable for merging into this one: for
             instance, it might have the wrong channel type or handle type.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Errors.NotImplemented">
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It will never be possible to merge channels into this particular
             conference.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Errors.NotAvailable">
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             The given channel is theoretically suitable for merging into this
             one, but that's not currently possible for some reason (for
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index d4fde0d..0eeee39 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -95,7 +95,8 @@ USA.</p>
     </tp:docstring>
 
     <property name="SupportedContentTypes" type="as" access="read"
-      tp:name-for-bindings="Supported_Content_Types">
+      tp:name-for-bindings="Supported_Content_Types"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of MIME types supported by this channel, with more preferred
           MIME types appearing earlier in the list. The list MAY include "*/*"
@@ -143,7 +144,8 @@ USA.</p>
 
     <property name="MessagePartSupportFlags" type="u"
       tp:type="Message_Part_Support_Flags" access="read"
-      tp:name-for-bindings="Message_Part_Support_Flags">
+      tp:name-for-bindings="Message_Part_Support_Flags"
+      tp:immutable="yes">
       <tp:docstring>
         Flags indicating the level of support for message parts on this
         channel.
@@ -1087,15 +1089,19 @@ USA.</p>
 
     <property name="PendingMessages" type="aaa{sv}" access="read"
       tp:type="Message_Part[][]" tp:name-for-bindings="Pending_Messages">
-      <tp:docstring>
-        A list of incoming messages that have neither been acknowledged nor
-        rejected. This list is a more detailed version of the one returned
-        by <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">Text.ListPendingMessages</tp:dbus-ref>,
-        and contains the same messages, uniquely identified by the same
-        pending message IDs. Its items can be removed using
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">Text.AcknowledgePendingMessages</tp:dbus-ref>.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of incoming messages that have neither been acknowledged nor
+          rejected. This list is a more detailed version of the one returned
+          by <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Type">Text.ListPendingMessages</tp:dbus-ref>,
+          and contains the same messages, uniquely identified by the same
+          pending message IDs. Its items can be removed using
+          <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Type">Text.AcknowledgePendingMessages</tp:dbus-ref>.</p>
+
+        <p>Change notification is via
+          <tp:member-ref>MessageReceived</tp:member-ref> and
+          <tp:member-ref>PendingMessagesRemoved</tp:member-ref>.</p>
       </tp:docstring>
     </property>
 
@@ -1340,7 +1346,8 @@ USA.</p>
 
     <property name="DeliveryReportingSupport" access="read"
       tp:type="Delivery_Reporting_Support_Flags" type="u"
-      tp:name-for-bindings="Delivery_Reporting_Support">
+      tp:name-for-bindings="Delivery_Reporting_Support"
+      tp:immutable="yes">
       <tp:docstring>
         A bitfield indicating features supported by this channel.
       </tp:docstring>
diff --git a/spec/Channel_Interface_Room.xml b/spec/Channel_Interface_Room.xml
new file mode 100644
index 0000000..ffdf4a9
--- /dev/null
+++ b/spec/Channel_Interface_Room.xml
@@ -0,0 +1,373 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Room"
+  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.Channel.Interface.Room.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:added version="0.19.11">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Different IM protocols use a variety of ways to name chat rooms. The
+        simplest example is perhaps IRC, where chat rooms have short,
+        persistent, human-readable string names, and are generally global
+        across the network. Skype chat rooms have persistent string names, so
+        you can leave and re-join a room, but these names are opaque unique
+        identifiers. MSN chat rooms are unnamed, and you can only join one by
+        being invited. And XMPP wins the coveted “most complicated chat rooms”
+        prize: chat rooms may be hosted by different servers with different DNS
+        names; normally they have human-readable names, except that all MUCs on
+        Google Talk's conference server have UUIDs as names, and <a
+          href="http://xmpp.org/extensions/xep-0045.html#createroom-unique"><acronym
+          title="XMPP Extension Protocol">XEP</acronym>-0045 §10.1.4
+        <q>Requesting a Unique Room Name</q></a> defines a protocol for
+        requesting a unique, opaque room name on the server.</p>
+
+      <p>This interface intends to support and differentiate these mechanisms
+        more clearly than the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+        and <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+        properties can alone. It initially contains a pair of properties used
+        to represent the human-readable parts of a
+        <tp:type>Room_Handle</tp:type>'s identifier, if any. The above examples
+        for different protocols are represented as follows:</p>
+
+      <ul>
+        <li>The IRC channel <tt>#telepathy</tt> on Freenode is represented by a
+          channel with properties
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>Room</code>,
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          = <code>"#telepathy"</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>"#telepathy"</code>,
+          <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
+          that the room has a human-readable identifier, and is not confined to
+          a particular server on the network.
+
+          <tp:rationale>
+            Actually, IRC supports creating “local” channels specific to the
+            server they are created on. These channels have identifiers
+            starting with <tt>&amp;</tt> rather than <tt>#</tt>. These could be
+            represented by setting <tp:member-ref>Server</tp:member-ref>
+            appropriately.
+          </tp:rationale>
+        </li>
+
+        <li>A Skype group chat with opaque identifier <tt>0xdeadbeef</tt> has
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>Room</code>,
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          = <code>"0xdeadbeef"</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
+          that the room has an identifier but no human-readable name.
+        </li>
+
+        <li>An MSN group chat has
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>None</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
+          that the room has neither an identifier (so it cannot be re-joined
+          later) nor a human-readable name.
+        </li>
+
+        <li>A standard Jabber multi-user chat
+          <tt>jdev@conference.jabber.org</tt> has
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>Room</code>,
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          = <code>"jdev@conference.jabber.org"</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>"jdev"</code>,
+          <tp:member-ref>Server</tp:member-ref> = <code>"conference.jabber.org"</code>.
+        </li>
+
+        <li>A Google Talk private MUC <tt>private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com</tt> has
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>Room</code>,
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          = <code>"private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com"</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>Server</tp:member-ref> =
+          <code>"groupchat.google.com"</code>, indicating that the room has a
+          persistent identifier, no human-readable name, and is hosted by a
+          particular server.
+        </li>
+
+        <li>Similarly, a XEP-0045 §10.1.4 uniquely-named room
+          <tt>lrcgsnthzvwm@conference.jabber.org</tt> has
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          = <code>Room</code>,
+          <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          = <code>"lrcgsnthzvwm@conference.jabber.org"</code>,
+          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>Server</tp:member-ref> =
+          <code>"conference.jabber.org"</code>, indicating that the room has a
+          persistent identifier, no human-readable name, and is hosted by a
+          particular server.
+        </li>
+      </ul>
+
+      <h4>Requestable channel classes</h4>
+
+      <p>If the connection supports joining text chat rooms by unique
+        identifier, like Skype, it should advertise a
+        <tp:type>Requestable_Channel_Class</tp:type> matching:</p>
+
+      <blockquote>
+        <pre>
+( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+                                        >Text</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >TargetHandleType</tp:dbus-ref>: Room,
+          },
+  Allowed = [ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              >TargetID</tp:dbus-ref>,
+              ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              >TargetHandle</tp:dbus-ref>,
+            ]
+)</pre></blockquote>
+
+      <p>Channel requests must specify either <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        >TargetID</tp:dbus-ref> or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        >TargetHandle</tp:dbus-ref>.</p>
+
+      <p>If, like IRC, the room identifiers are also human-readable, the
+        RCCs should also include RoomID in <var>Allowed_Properties</var>:</p>
+
+      <blockquote>
+        <pre>
+( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+                                        >Text</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >TargetHandleType</tp:dbus-ref>: Room,
+          },
+  Allowed = [ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              >TargetID</tp:dbus-ref>,
+              ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              >TargetHandle</tp:dbus-ref>,
+              ...<tp:member-ref>RoomID</tp:member-ref>
+            ]
+),
+
+( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+                                        >Text</tp:dbus-ref>
+          },
+  Allowed = [ ...<tp:member-ref>RoomID</tp:member-ref>,
+            ]
+)</pre></blockquote>
+
+      <p>Requests may specify the RoomID in place of
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        . Note how <tp:member-ref>RoomID</tp:member-ref> appears
+        in <var>Allowed_Properties</var> of a different RCC because
+        when <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        >TargetHandleType</tp:dbus-ref> is omitted (or is None), both
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        >TargetHandle</tp:dbus-ref> and
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        >TargetID</tp:dbus-ref> must also be omitted.
+        <tp:member-ref>RoomID</tp:member-ref> is allowed in conjuction
+        with
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        in some situations, as explained below in the <em>Requesting room
+        channels</em> section.
+      </p>
+
+      <p>If rooms may be on different servers, <tp:member-ref>Server</tp:member-ref>
+        should also be included in the allowed properties, but
+        CMs MUST use a reasonable default
+        <tp:member-ref>Server</tp:member-ref> if not explicitly
+        specified in a channel request. The CM's default server MAY
+        be configurable by a connection parameter specified on a
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.ConnectionManager"
+        >RequestConnection</tp:dbus-ref> call, similarly to how the
+        fallback conference server is specified on jabber connections in
+        gabble.</p>
+
+      <p>If the protocol supports unnamed rooms, <tp:member-ref>RoomID</tp:member-ref>
+        should be fixed to the empty string, and
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+        should be None:</p>
+
+      <blockquote>
+        <pre>
+( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+                                        >Text</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            >TargetHandleType</tp:dbus-ref>: None,
+            ...<tp:member-ref>RoomID</tp:member-ref>: "",
+          },
+  Allowed = [ ]
+)</pre></blockquote>
+
+      <h4>Requesting room channels</h4>
+
+      <p>When explicitly joining a room, the CM cannot know whether the room
+        ID is unique or not. As a result, if this is the case, adding an
+        empty string <tp:member-ref>RoomID</tp:member-ref> into the channel
+        request will ensure the CM knows. For example:</p>
+
+      <blockquote>
+        <pre>
+{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
+  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "qwerasdfzxcv@conference.jabber.org",
+  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+}</pre></blockquote>
+
+      <p>If <tp:member-ref>RoomID</tp:member-ref> features in
+        <var>Allowed_Properties</var> then the only value allowed in conjunction
+        with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+        or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        is the empty string. Requests with conflicting
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+        and <tp:member-ref>RoomID</tp:member-ref> properties
+        will fail with InvalidArgument.</p>
+
+      <p>To create a XEP-0045 §10.1.4 uniquely-named room channel
+        on the conference.jabber.org server, then the following channel
+        request should be made:</p>
+
+      <blockquote>
+        <pre>
+{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
+  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+  ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
+}</pre>
+      </blockquote>
+
+      <p>If everything is successful, then when the channel request is
+        satisfied, a new channel will appear with the following properties:</p>
+
+      <blockquote>
+        <pre>
+{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
+  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "kajsdhkajshdfjkshdfjkhs@conference.jabber.org",
+  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+  ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
+}</pre>
+      </blockquote>
+
+      <p>The CM will have received the unique room name (kajsdhkajshdfjkshdfjkhs)
+        and then created a room with such a name on the said server. The empty
+        <tp:member-ref>RoomID</tp:member-ref> property shows that the room name
+        is not human-readable.</p>
+
+    </tp:docstring>
+
+    <property name="RoomID" tp:name-for-bindings="Room_ID" type="s"
+              access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The human-readable identifier of a chat room. Note that if
+          non-empty, this property (and perhaps also
+          <tp:member-ref>Server</tp:member-ref>) should be sufficient in
+          a channel request to join the room. XMPP MUCs have a room name
+          concept which is more like a topic, except more
+          persistent. This D-Bus property is <strong>not</strong> this
+          XMPP room name, but the bit before the @ in the room jid.</p>
+
+        <p>This property cannot change during the lifetime of the channel. It
+          should appear in the <var>Allowed_Properties</var> of a
+          <tp:type>Requestable_Channel_Class</tp:type> for the connection if
+          rooms on this connection have human-readable names, and can be joined
+          by name.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Server" tp:name-for-bindings="Server" type="s"
+              access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>For protocols with a concept of chatrooms on multiple servers with
+          different DNS names (like XMPP), the DNS name of the server hosting
+          this channel (for example, <tt>"conference.jabber.org"</tt> or
+          <tt>"groupchat.google.com"</tt>). For other protocols, the empty
+          string.</p>
+
+        <p>This property cannot change during the lifetime of the channel. It
+          should appear in the <var>Allowed_Properties</var> of a
+          <tp:type>Requestable_Channel_Class</tp:type> for the connection if
+          and only if non-empty values are supported.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:struct name="Room_Subject">
+      <tp:docstring>
+        A struct representing the subject of a room channel.
+      </tp:docstring>
+      <tp:member type="s" name="Subject">
+        <tp:docstring>
+           A human-readable description of the current subject of
+           conversation in the channel, similar to /topic in IRC.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Actor">
+        <tp:docstring>
+           A normalized contact ID representing who last modified the
+           subject, or the empty string if it is not known.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="x" tp:type="Unix_Timestamp64" name="Timestamp">
+        <tp:docstring>
+           A unix timestamp indicating when the subject was last modified.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <property name="Subject" tp:name-for-bindings="Subject"
+              type="(ssx)" tp:type="Room_Subject" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The subject on the room such as the topic in an IRC channel,
+          or the room name in XMPP MUCs. In protocols which do not support
+          subjects (like MSN), this property should be ("", "", 0).</p>
+
+        <tp:rationale>This property replaces the subject, subject-contact, and
+          subject-timestamp Telepathy properties of Text channels, as Telepathy
+          properties are soon to be deprecated completely.</tp:rationale>
+
+        <p>This property may change during the lifetime of the channel and
+          MUST not be included in a channel request.</p>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_SMS.xml b/spec/Channel_Interface_SMS.xml
new file mode 100644
index 0000000..b0dce66
--- /dev/null
+++ b/spec/Channel_Interface_SMS.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_SMS"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2008–2010 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+  </tp:license>
+
+  <interface
+    name="org.freedesktop.Telepathy.Channel.Interface.SMS">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
+    <tp:added version='0.19.12'>Imported from
+      rtcom-telepathy-glib, with the unused properties removed and the
+      documentation tidied up.</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface contains SMS-specific properties for text channels.
+        This currently only includes whether the SMSes received on the channel
+        should be displayed immediately to the user, without prompting.</p>
+
+      <h4>Handler filters</h4>
+
+      <p>A handler for class 0 SMSes should advertise the following filter:</p>
+
+      <blockquote><code>
+{ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+  ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+      <tp:type>Handle_Type</tp:type>_Contact,<br/>
+  ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
+      True,<br/>
+}</code></blockquote>
+
+      <p>It should also set its <tp:dbus-ref
+        namespace='ofdT.Client.Handler'>BypassApproval</tp:dbus-ref> property
+        to <code>True</code>, so that it is invoked immediately for new
+        channels.</p>
+    </tp:docstring>
+
+    <property name="Flash" tp:name-for-bindings="Flash"
+      type="b" access="read" >
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <code>True</code>, then this channel is exclusively for
+          receiving class 0 SMSes (and no SMSes can be sent using <tp:dbus-ref
+          namespace='ofdT.Channel.Interface.Messages'>SendMessage</tp:dbus-ref>
+          on this channel). If <code>False</code>, no incoming class 0 SMSes
+          will appear on this channel.</p>
+
+        <p>This property is immutable (cannot change), and therefore SHOULD
+          appear wherever immutable properties are reported, e.g. <tp:dbus-ref
+            namespace="ofdT.Connection.Interface.Requests"
+          >NewChannels</tp:dbus-ref> signals.</p>
+
+        <tp:rationale>
+          <p>Class 0 SMSes should be displayed immediately to the user, and
+            need not be saved to the device memory unless the user explicitly
+            chooses to do so. This is unlike “normal”, class 1 SMSes, which
+            must be stored, but need not be shown immediately in their entirity
+            to the user.</p>
+
+          <p>Separating class 0 SMSes into their own channel with this
+            immutable property allows them to be dispatched to a different
+            <tp:dbus-ref namespace='ofdT.Client'>Handler</tp:dbus-ref>—which
+            would include this property in its <tp:dbus-ref
+            namespace='ofdT.Client.Handler'
+            >HandlerChannelFilter</tp:dbus-ref>—avoiding the normal Text
+            channel handler having to decide for each message whether it should
+            be displayed to the user immediately or handled normally.</p>
+
+          <p>Currently, no mechanism is defined for <em>sending</em> class 0
+            SMSes. It seems reasonable to support specifying the class of an
+            outgoing SMS in its header <tp:type>Message_Part</tp:type>, rather
+            than requiring the UI to request a special channel for such SMSes;
+            hence, we define here that channels with Flash set to
+            <code>True</code> are read-only.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
diff --git a/spec/Channel_Interface_Splittable.xml b/spec/Channel_Interface_Splittable.xml
index 063565e..760c134 100644
--- a/spec/Channel_Interface_Splittable.xml
+++ b/spec/Channel_Interface_Splittable.xml
@@ -28,7 +28,7 @@
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for channels that can be made conceptually part of a
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference.DRAFT</tp:dbus-ref>, and can then be detached from that
+          >Conference</tp:dbus-ref>, and can then be detached from that
         conference.</p>
 
       <tp:rationale>
@@ -45,23 +45,20 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request that this channel is removed from any
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference.DRAFT</tp:dbus-ref> of which it is a part.</p>
+          >Conference</tp:dbus-ref> of which it is a part.</p>
 
         <p>This implies that the media streams within the conference are put on
           hold and the media streams within the member channel leaving the
-          conference are unheld.
-          <strong>[FIXME: or, maybe it'd be less surprising if it didn't do
-            this?]</strong>
-        </p>
+          conference are unheld.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Errors.InvalidArgument">
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
             This channel isn't in a conference.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Errors.NotAvailable">
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
           <tp:docstring>
             This channel is in a conference but can't currently be split away
             from it.
diff --git a/spec/Channel_Request_Future.xml b/spec/Channel_Request_Future.xml
new file mode 100644
index 0000000..d75c7e0
--- /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 f1d0f0e..a45d956 100644
--- a/spec/Channel_Type_Call.xml
+++ b/spec/Channel_Type_Call.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" ?>
 <node name="/Channel_Type_Call" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Limited</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Collabora Limited</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
   <tp:license>
     This library is free software; you can redistribute it and/or
 modify it under the terms of the GNU Lesser General Public
@@ -23,29 +23,406 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A channel type for making audio and video calls.</p>
+      <p>A channel type for making audio and video calls. Call
+        channels supersede the old <tp:dbus-ref
+        namespace="ofdT.Channel.Type">StreamedMedia</tp:dbus-ref>
+        channel type. Call channels are much more flexible than its
+        predecessor and allow more than two participants.</p>
+
+      <p>Handlers are advised against executing all the media
+        signalling, codec and candidate negotiation themselves but
+        instead use a helper library such as <a
+        href="http://telepathy.freedesktop.org/doc/telepathy-farsight/">telepathy-farsight</a>
+        which when given a new Call channel will set up the
+        transports and codecs and create GStreamer pads which
+        can be added to the handler UI. This is useful as it means
+        the handler does not have to worry how exactly the
+        connection between the call participants is being made.</p>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> and
+        <tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>
+        properties in a Call channel refer to the contact that the
+        user initially called, or which contact initially called the
+        user. Even in a conference call, where there are multiple
+        contacts in the call, these properties refer to the
+        initial contact, who might have left the conference since
+        then. As a result, handlers should not rely on these
+        properties.</p>
+
+      <h4>Contents</h4>
+
+      <p><tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
+        objects represent the actual media that forms the Call (for
+        example an audio content and a video content). Calls always
+        have one or more Content objects associated with them. As a
+        result, a new Call channel request MUST have either
+        <tp:member-ref>InitialAudio</tp:member-ref>=True, or
+        <tp:member-ref>InitialVideo</tp:member-ref>=True, or both,
+        as the Requestable Channel Classes will document.</p>
+
+      <p><tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects have
+        one or more stream associated with them. More information on
+        these streams and how to maniuplate them can be found on the
+        <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
+        interface page.</p>
+
+      <h4>Outgoing calls</h4>
+
+      <p>To make an audio-only call to a contact <tt>foo@example.com</tt>
+        handlers should call:</p>
+
+      <blockquote>
+        <pre>
+<tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+  ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+  ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
+  ...<tp:member-ref>InitialAudio</tp:member-ref>: True,
+})</pre></blockquote>
+
+      <p>As always, <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> may be used
+        in place of
+        <tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>
+        if the contact's handle is already known. To make an audio
+        and video call, the handler should also specify
+        <tp:member-ref>InitialVideo</tp:member-ref> The
+        connection manager SHOULD return a channel whose immutable
+        properties contain the local user as the <tp:dbus-ref
+        namespace="ofdT.Channel">InitiatorHandle</tp:dbus-ref>, the
+        remote contact as the <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref>,
+        <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref> =
+        <code>True</code> (indicating the call is outgoing).</p>
+
+      <p>After a new Call channel is requested, the
+        <tp:member-ref>CallState</tp:member-ref> property will be
+        <tp:type>Call_State</tp:type>_Pending_Initiator. As the local
+        user is the initiator, the call must be accepted by the handler
+        by calling the <tp:member-ref>Accept</tp:member-ref> method.
+        At this point, <tp:member-ref>CallState</tp:member-ref> changes
+        to <tp:type>Call_State</tp:type>_Pending_Receiver which signifies
+        that the call is ringing, waiting for the remote contact to
+        accept the call. All changes to
+        <tp:member-ref>CallState</tp:member-ref> property are signalled
+        using the <tp:member-ref>CallStateChanged</tp:member-ref>
+        signal.</p>
+
+      <p>When the call is accepted by the remote contact, the
+        <tp:member-ref>CallStateChanged</tp:member-ref> signal fires
+        again to show that <tp:member-ref>CallState</tp:member-ref> =
+        <tp:type>Call_State</tp:type>_Accepted.</p>
+
+      <p>At this point <a
+        href="http://telepathy.freedesktop.org/doc/telepathy-farsight/">telepathy-farsight</a>
+        will signal that a pad is available for the handler to show
+        in the user interface.</p>
+
+      <h5>Missed calls</h5>
+
+      <p>If the remote contact does not accept the call in time, then
+        the call can be terminated by the server. Note that this only
+        happens in some protocols. Most XMPP clients, for example, do
+        not do this and rely on the call initiator terminating the call.
+        A missed call is shown in a Call channel by the
+        <tp:member-ref>CallState</tp:member-ref> property changing to
+        <tp:type>Call_State</tp:type>_Ended, and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property changing
+        to (remote contact,
+        <tp:type>Call_State_Change_Reason</tp:type>_No_Answer, "").</p>
+
+      <h5>Rejected calls</h5>
+
+      <p>If the remote contact decides he or she does not feel like
+        talking to the local user, he or she can reject his or her
+        incoming call. This will be shown in the Call channel by
+        <tp:member-ref>CallState</tp:member-ref> changing to
+        <tp:type>Call_State</tp:type>_Ended and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property
+        changing to (remote contact,
+        <tp:type>Call_State</tp:type>_Change_Reason_User_Requested,
+        "org.freedesktop.Telepathy.Error.Rejected").</p>
+
+      <h4>Incoming calls</h4>
+
+      <p>When an incoming call occurs, something like the following
+        <tp:dbus-ref
+        namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+        signal will occur:</p>
+
+      <blockquote>
+        <pre>
+<tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>([
+  /org/freedesktop/Telepathy/Connection/foo/bar/foo_40bar_2ecom/CallChannel,
+  {
+    ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandle</tp:dbus-ref>: 42,
+    ...<tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>: False,
+    ...<tp:member-ref>InitialAudio</tp:member-ref>: True,
+    ...<tp:member-ref>InitialVideo</tp:member-ref>: True,
+    ...<tp:member-ref>InitialAudioName</tp:member-ref>: "audio",
+    ...<tp:member-ref>InitialVideoName</tp:member-ref>: "video",
+    ...<tp:member-ref>MutableContents</tp:member-ref>: True,
+  }])</pre></blockquote>
+
+      <p>The <tp:member-ref>InitialAudio</tp:member-ref> and
+        <tp:member-ref>InitialVideo</tp:member-ref> properties show that
+        the call has been started with two contents: one for audio
+        streaming and one for video streaming. The
+        <tp:member-ref>InitialAudioName</tp:member-ref> and
+        <tp:member-ref>InitialVideoName</tp:member-ref> properties also
+        show that the aforementioned audio and video contents have names
+        "audio" and "video".</p>
+
+      <p>Once the handler has notified the local user that there is an
+        incoming call waiting for acceptance, the handler should call
+        <tp:member-ref>SetRinging</tp:member-ref> to let the CM know.
+        The new channel should also be given to telepathy-farsight to
+        work out how the two participants will connect together.
+        telepathy-farsight will call the appropriate methods on the call's
+        <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>s
+        to negotiate codecs and transports.</p>
+
+      <p>To pick up the call, the handler should call
+        <tp:member-ref>Accept</tp:member-ref>. The
+        <tp:member-ref>CallState</tp:member-ref> property changes to
+        <tp:type>Call_State</tp:type>_Accepted and once media is
+        being transferred, telepathy-farsight will notify the
+        handler of a new pad to be shown to the local user in the
+        UI</p>
+
+      <p>To reject the call, the handler should call the
+        <tp:member-ref>Hangup</tp:member-ref> method. The
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property will
+        change to (self handle,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Rejected").</p>
+
+      <h4>Ongoing calls</h4>
+
+      <h5>Adding and removing contents</h5>
+
+      <p>When a call is open, new contents can be added as long as the
+        CM supports it. The
+        <tp:member-ref>MutableContents</tp:member-ref> property will let
+        the handler know whether further contents can be added or
+        existing contents removed. An example of this is starting a
+        voice call between a contact and then adding a video content.
+        To do this, the should call
+        <tp:member-ref>AddContent</tp:member-ref> like this:</p>
+
+      <blockquote>
+        <pre><tp:member-ref>AddContent</tp:member-ref>("video",
+           <tp:type>Media_Stream_Type</tp:type>_Video)</pre>
+      </blockquote>
+
+      <p>Assuming no errors, the new video content will be added to
+        the call. telepathy-farsight will pick up the new content and
+        perform the transport and codec negotiation automatically.
+        telpathy-farsight will signal when the video is ready to
+        show in the handler's user interface.</p>
+
+      <p>A similar method is used for removing contents from a call,
+        except that the <tp:dbus-ref
+        namespace="ofdT.Call.Content.DRAFT">Remove</tp:dbus-ref> method
+        is on the <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> object.</p>
+
+      <h5>Ending the call</h5>
+
+      <p>To end the call, the handler should call the
+        <tp:member-ref>Hangup</tp:member-ref> method. The
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and
+        <tp:member-ref>CallStateReason</tp:member-ref> will change
+        to (self handle,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Cancelled").</p>
+
+      <p>If the other participant hangs up first then the
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and
+        <tp:member-ref>CallStateReason</tp:member-ref> will change
+        to (remote contact,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Terminated").</p>
+
+      <h4>Multi-party calls</h4>
+
+      [TODO]
+
+      <h4>Call states</h4>
+
+      <p>There are many combinations of the
+        <tp:member-ref>CallState</tp:member-ref> and
+        <tp:member-ref>CallStateReason</tp:member-ref> properties which
+        mean different things. Here is a table to try to make these
+        meanings clearer:</p>
+
+      <table>
+        <tr>
+          <th rowspan="2"><tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref></th>
+          <th rowspan="2"><tp:member-ref>CallState</tp:member-ref></th>
+          <th colspan="3"><tp:member-ref>CallStateReason</tp:member-ref></th>
+          <th rowspan="2">Meaning</th>
+        </tr>
+        <tr>
+          <th>Actor</th>
+          <th>Reason</th>
+          <th>DBus_Reason</th>
+        </tr>
+        <!-- Pending_Initiator -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Initiator</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The outgoing call channel is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref>.</td>
+        </tr>
+        <!-- Pending_Receiver -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The outgoing call is waiting for the remote contact to pick up the call.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
+          <td>0</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_Unknown</td>
+          <td>""</td>
+          <td>The incoming call is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref> on the call.</td>
+        </tr>
+        <!-- Accepted -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Accepted</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The remote contact accepted the outgoing call.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Accepted</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The local user accepted the incoming call.</td>
+        </tr>
+        <!-- Ended -->
+        <tr>
+          <td>True or False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>Cancelled</tp:error-ref></td>
+          <td>The local user hung up the incoming or outgoing call.</td>
+        </tr>
+        <tr>
+          <td>True or False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>Terminated</tp:error-ref></td>
+          <td>The remote contact hung up the incoming or outgoing call.</td>
+        </tr>
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_No_Answer</td>
+          <td>""</td>
+          <td>The outgoing call was not picked up and the call ended.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>PickedUpElsewhere</tp:error-ref></td>
+          <td>The incoming call was ended because it was picked up elsewhere.</td>
+        </tr>
+      </table>
+
+      <h4>Requestable channel classes</h4>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+        for <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
+        can be:</p>
+
+      <blockquote>
+        <pre>
+[( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+            ...<tp:member-ref>InitialVideo</tp:member-ref>: True
+          },
+  Allowed = [ ...<tp:member-ref>InitialVideoName</tp:member-ref>,
+              ...<tp:member-ref>InitialAudio</tp:member-ref>,
+              ...<tp:member-ref>InitialAudioName</tp:member-ref>
+            ]
+),
+( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+            ...<tp:member-ref>InitialAudio</tp:member-ref>: True
+          },
+  Allowed = [ ...<tp:member-ref>InitialAudioName</tp:member-ref>,
+              ...<tp:member-ref>InitialVideo</tp:member-ref>,
+              ...<tp:member-ref>InitialVideoName</tp:member-ref>
+            ]
+)]</pre></blockquote>
+
+      <p>Clients aren't allowed to make outgoing calls that have
+        neither initial audio nor initial video. Clearly, CMs
+        which don't support video should leave out the first class and
+        omit <tp:member-ref>InitialVideo</tp:member-ref> from the second
+        class, and vice versa for CMs without audio support.</p>
+
+      <p>Handlers should not close <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
+        without first calling <tp:member-ref>Hangup</tp:member-ref> on
+        the channel. If a Call handler crashes, the <tp:dbus-ref
+        namespace="ofdT">ChannelDispatcher</tp:dbus-ref> will call
+        <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref> on the
+        channel which SHOULD also imply a call to
+        <tp:member-ref>Hangup</tp:member-ref>(<tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Terminated", "") before
+        actually closing the channel.</p>
 
-      <p>A Call channel can have one or more <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Call">Content.DRAFT</tp:dbus-ref>
-        objects, which represent the actual Media that forms the Call (e.g. an
-        audio content and a video content).</p>
     </tp:docstring>
 
-    <method name="Ringing" tp:name-for-bindings="Ringing">
+    <method name="SetRinging" tp:name-for-bindings="Set_Ringing">
+      <tp:changed version="0.21.2">renamed from Ringing</tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Indicate that the local user has been alerted about the incoming
           call.</p>
 
-        <p>This method is only useful if the channel's
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-            >Requested</tp:dbus-ref> property is false, and the
-          <tp:member-ref>CallState</tp:member-ref> is
-          Call_State_Pending_Receiver. While this is the case,
-          this method SHOULD change the
+        <p>This method is only useful if the
+          channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
+          property is False, and
+          the <tp:member-ref>CallState</tp:member-ref> is
+          <tp:type>Call_State</tp:type>_Pending_Receiver (an incoming
+          call waiting on the local user to pick up). While this is
+          the case, this method SHOULD change the
           <tp:member-ref>CallFlags</tp:member-ref> to include
-          Call_Flag_Ringing, and notify the remote contact that the local
-          user has been alerted (if the protocol implements this); repeated
-          calls to this method SHOULD succeed, but have no further effect.</p>
+          <tp:type>Call_Flags</tp:type>_Locally_Ringing, and notify the
+          remote contact that the local user has been alerted (if the
+          protocol implements this); repeated calls to this method
+          SHOULD succeed, but have no further effect.</p>
 
         <p>In all other states, this method SHOULD fail with the error
           NotAvailable.</p>
@@ -54,14 +431,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The call was <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
-              >Requested</tp:dbus-ref>, so ringing does not make sense.
+            The call was <tp:dbus-ref namespace="ofdT.Channel"
+            >Requested</tp:dbus-ref>, so ringing does not make sense.
           </tp:docstring>
         </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
           <tp:docstring>
-            The call is no longer in state Call_State_Pending_Receiver.
+            The call is no longer in state
+            <tp:type>Call_State</tp:type>_Pending_Receiver.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -69,14 +446,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <method name="Accept" tp:name-for-bindings="Accept">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>For incoming calls in state Call_State_Pending_Receiver, accept the
+        <p>For incoming calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver, accept the
           incoming call; this changes the
-          <tp:member-ref>CallState</tp:member-ref> to Call_State_Accepted.</p>
+          <tp:member-ref>CallState</tp:member-ref> to
+          <tp:type>Call_State</tp:type>_Accepted.</p>
 
-        <p>For outgoing calls in state Call_State_Pending_Initiator, actually
+        <p>For outgoing calls in state
+          <tp:type>Call_State</tp:type>_Pending_Initiator, actually
           call the remote contact; this changes the
           <tp:member-ref>CallState</tp:member-ref> to
-          Call_State_Pending_Receiver.</p>
+          <tp:type>Call_State</tp:type>_Pending_Receiver.</p>
 
         <p>Otherwise, this method SHOULD fail with the error NotAvailable.</p>
 
@@ -84,16 +464,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           client (user interface) is handling the channel.</p>
 
         <p>When this method is called, for each <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call"
-            >Content.DRAFT</tp:dbus-ref> whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content.DRAFT"
-            >Disposition</tp:dbus-ref> is Call_Content_Disposition_Initial,
-          any streams where the self-handle's sending state in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.DRAFT"
-            >Senders</tp:dbus-ref> is Sending_State_Pending_Send
-          will be moved to Sending_State_Sending as if <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.DRAFT"
-            >SetSending</tp:dbus-ref>(TRUE) had been called.</p>
+          namespace="ofdT.Call" >Content.DRAFT</tp:dbus-ref> whose
+          <tp:dbus-ref namespace="ofdT.Call.Content.DRAFT"
+          >Disposition</tp:dbus-ref> is
+          <tp:type>Call_Content_Disposition</tp:type>_Initial, any
+          streams where the <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
+          is <tp:type>Sending_State</tp:type>_Pending_Send will be
+          moved to <tp:type>Sending_State</tp:type>_Sending as if
+          <tp:dbus-ref namespace="ofdT.Call.Stream.DRAFT"
+          >SetSending</tp:dbus-ref>(True) had been called.</p>
       </tp:docstring>
 
       <tp:possible-errors>
@@ -107,11 +487,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <method name="Hangup" tp:name-for-bindings="Hangup">
       <tp:docstring>
-        Request that the call is ended.
+        Request that the call is ended. All contents will be removed
+        from the Call so that the
+        <tp:member-ref>Contents</tp:member-ref> property will be the
+        empty list.
       </tp:docstring>
 
       <arg direction="in" name="Reason"
-        type="u"  tp:type="Call_State_Change_Reason">
+        type="u" tp:type="Call_State_Change_Reason">
         <tp:docstring>
           A generic hangup reason.
         </tp:docstring>
@@ -147,21 +530,39 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <method name="AddContent" tp:name-for-bindings="Add_Content">
       <tp:docstring>
-        [FIXME]
+        Request that a new <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> of type
+        Content_Type is added to the Call. Handlers should check the
+        value of the <tp:member-ref>MutableContents</tp:member-ref>
+        property before trying to add another content as it might not
+        be allowed.
       </tp:docstring>
       <arg direction="in" name="Content_Name" type="s">
         <tp:docstring>
-          The suggested name of the content to add
+          <p>The suggested name of the content to add.</p>
 
           <tp:rationale>
-            [FIXME: rationale]
+            The content name property should be meaningful, so should
+            be given a name which is significant to the user. The name
+            could be a localized "audio", "video" or perhaps include
+            some string identifying the source, such as a webcam
+            identifier.
           </tp:rationale>
+
+          <p>If there is already a content with the same name as this
+            property then a sensible suffix should be added. For example,
+            if this argument is "audio" but a content of the same name
+            already exists, a sensible suffix such as " (1)" is appended
+            to name the new content "audio (1)". A further content with the
+            name "audio" would then be named "audio (2)".</p>
+
         </tp:docstring>
       </arg>
       <arg direction="in" name="Content_Type" type="u"
           tp:type="Media_Stream_Type">
         <tp:docstring>
-          The media type of the content to add
+          The media stream type of the content to be added to the
+          call.
         </tp:docstring>
       </arg>
       <arg direction="out" name="Content" type="o">
@@ -175,12 +576,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            [FIXME: when?]
+            The media stream type given is invalid.
           </tp:docstring>
         </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
-            [FIXME: when?]
+            The media stream type requested is not implemented by the
+            CM.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
+          <tp:docstring>
+            The content type requested cannot be added to this
+            call. Examples of why this might be the case include
+            because a second video stream cannot be added, or a
+            content cannot be added when the content set isn't
+            mutable.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -189,46 +600,37 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <signal name="ContentAdded"
             tp:name-for-bindings="Content_Added">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a new <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call"
-            >Content.DRAFT</tp:dbus-ref> is added to the call.</p>
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> is added to the call.</p>
       </tp:docstring>
       <arg name="Content" type="o">
         <tp:docstring>
-          Path to the newly-created <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call"
-            >Content.DRAFT</tp:dbus-ref> object.
+          Path to the newly-created <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> object.
         </tp:docstring>
       </arg>
-       <arg name="Content_Type" type="u" tp:type="Media_Stream_Type">
-          <tp:docstring>
-            The media type of the content which was added
-          </tp:docstring>
-        </arg>
     </signal>
 
     <signal name="ContentRemoved" tp:name-for-bindings="Content_Removed">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call"
-            >Content.DRAFT</tp:dbus-ref> is removed from the call.</p>
+        <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> is removed from the call.</p>
       </tp:docstring>
       <arg name="Content" type="o">
         <tp:docstring>
-          The <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call"
-            >Content.DRAFT</tp:dbus-ref> which was removed.
+          The <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> which was removed.
         </tp:docstring>
       </arg>
     </signal>
 
     <property name="Contents" type="ao" access="read"
-              tp:name-for-bindings="Contents">
+      tp:name-for-bindings="Contents">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The list of
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call">Content.DRAFT</tp:dbus-ref>
-          objects  that are part of this call. Change notification
-          is via the <tp:member-ref>ContentAdded</tp:member-ref> and
+        <p>The list of <tp:dbus-ref
+          namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects that
+          are part of this call. Change notification is via the
+          <tp:member-ref>ContentAdded</tp:member-ref> and
           <tp:member-ref>ContentRemoved</tp:member-ref> signals.
         </p>
       </tp:docstring>
@@ -306,9 +708,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The local contact has been alerted about the call but has not
           responded; if possible, the remote contact(s) have been informed of
           this fact. This flag only makes sense on incoming calls in
-          state Call_State_Pending_Receiver. It SHOULD be set when
-          <tp:member-ref>Ringing</tp:member-ref> is called successfully, and
-          unset when the state changes.
+          state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD
+          be set when <tp:member-ref>SetRinging</tp:member-ref> is
+          called successfully, and unset when the state changes.
         </tp:docstring>
       </tp:flag>
 
@@ -317,19 +719,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The contact is temporarily unavailable, and the call has been placed
           in a queue (e.g. 182 Queued in SIP, or call-waiting in telephony).
           This flag only makes sense on outgoing 1-1 calls in
-          state Call_State_Pending_Receiver. It SHOULD be set or unset
-          according to informational messages from other contacts.
+          state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD be
+          set or unset according to informational messages from other
+          contacts.
         </tp:docstring>
       </tp:flag>
 
       <tp:flag suffix="Locally_Held" value="4">
         <tp:docstring>
-          The call has been put on hold by the local user, e.g. using the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Hold</tp:dbus-ref> interface. This flag SHOULD only be set if
-          there is at least one Content, and all Contents are locally held;
-          it makes sense on calls in state Call_State_Pending_Receiver or
-          Call_State_Accepted.
+          The call has been put on hold by the local user, e.g. using
+          the <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Hold</tp:dbus-ref> interface. This flag SHOULD only be set
+          if there is at least one Content, and all Contents are
+          locally held; it makes sense on calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver
+          or <tp:type>Call_State</tp:type>_Accepted.
 
           <tp:rationale>
             Otherwise, in transient situations where some but not all contents
@@ -346,8 +750,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The initiator of the call originally called a contact other than the
           current recipient of the call, but the call was then forwarded or
           diverted. This flag only makes sense on outgoing calls, in state
-          Call_State_Pending_Receiver or Call_State_Accepted. It SHOULD be
-          set or unset according to informational messages from other contacts.
+          <tp:type>Call_State</tp:type>_Pending_Receiver or
+          <tp:type>Call_State</tp:type>_Accepted. It SHOULD be set or unset
+          according to informational messages from other contacts.
         </tp:docstring>
       </tp:flag>
 
@@ -359,9 +764,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           status code 183 Session Progress, and could be used when the
           outgoing call has reached a gateway, for instance.
           This flag only makes sense on outgoing calls in state
-          Call_State_Pending_Receiver, and SHOULD be set or unset according to
-          informational messages from servers, gateways and other
-          infrastructure.
+          <tp:type>Call_State</tp:type>_Pending_Receiver, and SHOULD be set
+          or unset according to informational messages from servers, gateways
+          and other infrastructure.
         </tp:docstring>
       </tp:flag>
 
@@ -385,11 +790,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Muted" value="64">
         <tp:docstring>
           The call has been muted by the local user, e.g. using the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Content.Interface"
-            >Mute.DRAFT</tp:dbus-ref> interface. This flag SHOULD only be set if
-          there is at least one Content, and all Contents are locally muted;
-          it makes sense on calls in state Call_State_Pending_Receiver or
-          Call_State_Accepted.
+          <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
+          >Mute.DRAFT</tp:dbus-ref> interface. This flag SHOULD only
+          be set if there is at least one Content, and all Contents
+          are locally muted; it makes sense on calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver or
+          <tp:type>Call_State</tp:type>_Accepted.
         </tp:docstring>
       </tp:flag>
     </tp:flags>
@@ -409,7 +815,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <dd>An optional human-readable message sent when the call was ended,
             corresponding to the Message argument to the
             <tp:member-ref>Hangup</tp:member-ref> method. This is only
-            applicable when the call state is Call_State_Ended.
+            applicable when the call state is <tp:type>Call_State</tp:type>_Ended.
             <tp:rationale>
               XMPP Jingle can send such messages.
             </tp:rationale>
@@ -418,7 +824,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <dt>queue-message - s</dt>
           <dd>An optional human-readable message sent when the local contact
             is being held in a queue. This is only applicable when
-            Call_Flag_Queued is in the call flags.
+            <tp:type>Call_Flags</tp:type>_Queued is in the call flags.
             <tp:rationale>
               SIP 182 notifications can have human-readable messages attached.
             </tp:rationale>
@@ -428,7 +834,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <dd>A message giving further details of any error indicated by the
             <tp:member-ref>CallStateReason</tp:member-ref>. This will not
             normally be localized or suitable for display to users, and is only
-            applicable when the call state is Call_State_Ended.</dd>
+            applicable when the call state is
+            <tp:type>Call_State</tp:type>_Ended.</dd>
         </dl>
       </tp:docstring>
     </property>
@@ -442,6 +849,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           and <tp:member-ref>CallStateDetails</tp:member-ref> explain the
           reason for the current values for those properties.</p>
 
+        <p>Note that when in a conference call, this property is
+          purely to show your state in joining the call. The receiver
+          (or remote contact) in this context is the conference server
+          itself. The property does not change when other call members'
+          states change.</p>
+
         <p>Clients MAY consider unknown values in this property to be an
           error.</p>
       </tp:docstring>
@@ -456,6 +869,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <p>Clients are expected to ignore unknown flags in this property,
           without error.</p>
+
+        <p>When an ongoing call is active and not on hold or has any
+          other problems, this property will be 0.</p>
       </tp:docstring>
     </property>
 
@@ -496,6 +912,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             of a <tp:type>Call_State_Reason</tp:type> struct.</p>
         </tp:docstring>
       </tp:enumvalue>
+
+      <tp:enumvalue suffix="No_Answer" value="3">
+        <tp:added version="0.21.2"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The <tp:member-ref>CallState</tp:member-ref> changed from
+            <tp:type>Call_State</tp:type>_Pending_Receiver to
+            <tp:type>Call_State</tp:type>_Ended because the initiator
+            ended the call before the receiver accepted it. With an
+            incoming call this state change reason signifies a missed
+            call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
     </tp:enum>
 
     <tp:struct name="Call_State_Reason">
@@ -515,7 +943,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:member type="u" tp:type="Call_State_Change_Reason" name="Reason">
         <tp:docstring>
           The reason, chosen from a limited set of possibilities defined by
-          the Telepathy specification.
+          the Telepathy specification. If
+          <tp:type>Call_State_Change_Reason</tp:type>_User_Requested then
+          the Actor member will dictate whether it was the local user or
+          a remote contact responsible.
         </tp:docstring>
       </tp:member>
 
@@ -592,9 +1023,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </signal>
 
     <property name="HardwareStreaming" tp:name-for-bindings="Hardware_Streaming"
-        type="b" access="read">
+        type="b" access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If this property is TRUE, all of the media streaming is done by some
+        <p>If this property is True, all of the media streaming is done by some
           mechanism outside the scope of Telepathy.</p>
 
         <tp:rationale>
@@ -604,11 +1035,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             audio streaming for the call).</p>
         </tp:rationale>
 
-        <p>If this is FALSE, the handler is responsible for doing the actual
+        <p>If this is False, the handler is responsible for doing the actual
           media streaming for at least some contents itself. Those contents
-          will have the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Content.Interface"
-            >Media.DRAFT</tp:dbus-ref> interface, to communicate the necessary
+          will have the <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
+          >Media.DRAFT</tp:dbus-ref> interface, to communicate the necessary
           information to a streaming implementation. Connection managers SHOULD
           operate like this, if possible.</p>
 
@@ -663,6 +1093,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">
@@ -700,38 +1143,50 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <property name="CallMembers" tp:name-for-bindings="Call_Members"
       type="a{uu}" access="read" tp:type="Call_Member_Map">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        A mapping from the remote contacts that are part of this call to flags
-        discribing their status. This mapping never has the local user's handle
-        as a key.
+        <p>A mapping from the remote contacts that are part of this call to flags
+          describing their status. This mapping never has the local user's handle
+          as a key.</p>
+
+        <p>When the call ends, this property should be an empty list,
+          and notified with
+          <tp:member-ref>CallMembersChanged</tp:member-ref></p>
+
+        <p>If the Call implements
+          <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Group</tp:dbus-ref> and the Group members are
+          channel-specific handles, then this call SHOULD also use
+          channel-specific handles.</p>
+
+        <p>Anonymous members are exposed as channel-specific handles
+          with no owner.</p>
       </tp:docstring>
     </property>
 
     <property name="InitialTransport" tp:name-for-bindings="Initial_Transport"
-      type="s" access="read">
+      type="s" access="read" tp:requestable="yes" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>
-          If set on a requested channel this indicates the transport that
-          should be used for this call.
-          <tp:rationale>
-            When implementing a voip gateway one wants the outgoing leg of the
-            gatewayed to have the same transport as the incoming leg. This
-            property allows the gateway to request a Call with the right
-            transport from the CM.
-          </tp:rationale>
-        </p>
+        <p>If set on a requested channel, this indicates the transport that
+          should be used for this call. Where not applicable, this property
+          is defined to be the empty string, in particular, on CMs with
+          hardware streaming.</p>
+
+        <tp:rationale>
+          When implementing a voip gateway one wants the outgoing leg of the
+          gatewayed to have the same transport as the incoming leg. This
+          property allows the gateway to request a Call with the right
+          transport from the CM.
+        </tp:rationale>
       </tp:docstring>
     </property>
 
     <property name="InitialAudio" tp:name-for-bindings="Initial_Audio"
-      type="b" access="read">
+      type="b" access="read" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If set to true in a channel request that will create a new channel,
+        <p>If set to True in a channel request that will create a new channel,
           the connection manager should immediately attempt to establish an
           audio stream to the remote contact, making it unnecessary for the
-          client to call
-          <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT">AddContent</tp:dbus-ref>.
-          </p>
+          client to call <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">AddContent</tp:dbus-ref>.</p>
 
         <p>If this property, or InitialVideo, is passed to EnsureChannel
           (as opposed to CreateChannel), the connection manager SHOULD ignore
@@ -739,25 +1194,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           channel as suitable; these properties only become significant when
           the connection manager has decided to create a new channel.</p>
 
-        <p>If true on a requested channel, this indicates that the audio
+        <p>If True on a requested channel, this indicates that the audio
           stream has already been requested and the client does not need to
           call RequestStreams, although it MAY still do so.</p>
 
-        <p>If true on an unrequested (incoming) channel, this indicates that
+        <p>If True on an unrequested (incoming) channel, this indicates that
           the remote contact initially requested an audio stream; this does
           not imply that that audio stream is still active (as indicated by
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT">Contents</tp:dbus-ref>).</p>
-
-        <p>This property is immutable (cannot change), and therefore SHOULD
-          appear wherever immutable properties are reported, e.g. <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
-          signals.</p>
+          <tp:dbus-ref namespace="ofdT.Channel.Type.Call.DRAFT"
+          >Contents</tp:dbus-ref>).</p>
 
-        <tp:rationale><p>This reduces D-Bus round trips.</p></tp:rationale>
+        <p>The name of this new content can be decided by using the
+          <tp:member-ref>InitialAudioName</tp:member-ref> property.</p>
 
         <p>Connection managers that support the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities</tp:dbus-ref>
+          namespace="ofdT.Connection.Interface">ContactCapabilities</tp:dbus-ref>
           interface SHOULD represent the capabilities of receiving audio
           and/or video calls by including a channel class in
           a contact's capabilities with ChannelType = Call
@@ -775,19 +1226,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>Clients that are willing to receive audio and/or video calls
           SHOULD include the following among their channel classes if
           calling <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>
+          namespace="ofdT.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>
           (clients of a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
+          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
           SHOULD instead arrange for the ChannelDispatcher to do this,
           by including the filters in their <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+          namespace="ofdT.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
           properties):</p>
 
         <ul>
           <li>{ ChannelType = Call }</li>
-          <li>{ ChannelType = Call, InitialAudio = true }
+          <li>{ ChannelType = Call, InitialAudio = True }
             if receiving calls with audio is supported</li>
-          <li>{ ChannelType = Call, InitialVideo = true }
+          <li>{ ChannelType = Call, InitialVideo = True }
             if receiving calls with video is supported</li>
         </ul>
 
@@ -800,12 +1251,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </property>
 
     <property name="InitialVideo" tp:name-for-bindings="Initial_Video"
-      type="b" access="read">
+      type="b" access="read" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for
           a video stream. This property is immutable (cannot change).</p>
 
-        <p>In particular, note that if this property is false, this does not
+        <p>In particular, note that if this property is False, this does not
           imply that an active video stream has not been added, only that no
           video stream was active at the time the channel appeared.</p>
 
@@ -815,13 +1266,49 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
+    <property name="InitialAudioName" tp:name-for-bindings="Initial_Audio_Name"
+      type="s" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>InitialAudio</tp:member-ref> is set to
+          True, then this property will name the intial audio content
+          with the value of this property.</p>
+
+        <tp:rationale>
+          <p>Content names are meant to be significant, but if no name
+            can be given to initial audio content, then its name cannot
+            be meaningful or even localized.</p>
+        </tp:rationale>
+
+        <p>If this property is empty or missing from the channel
+          request and InitialAudio is True, then the CM must come up
+          with a sensible for the content, such as "audio".</p>
+
+        <p>If the protocol has no concept of stream names then this
+          property will not show up in the allowed properties list of
+          the Requestable Channel Classes for call channels.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialVideoName" tp:name-for-bindings="Initial_Video_Name"
+      type="s" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same as
+          <tp:member-ref>InitialAudioName</tp:member-ref>, but for a
+          video stream created by setting
+          <tp:member-ref>InitialVideo</tp:member-ref> to True. This
+          property is immutable and so cannot change.</p>
+      </tp:docstring>
+    </property>
+
     <property name="MutableContents" tp:name-for-bindings="Mutable_Contents"
-      type="b" access="read">
+      type="b" access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If <tt>True</tt>, a stream of a different content type can be added
+        <p>If True, a stream of a different content type can be added
         after the Channel has been requested </p>
 
-        <p>If this property is missing, clients SHOULD assume that it is false,
+        <p>If this property is missing, clients SHOULD assume that it is False,
           and thus that the channel's streams cannot be changed once the call
           has started.</p>
 
@@ -839,11 +1326,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
               video once the call has started for contacts without this flag.
             </p>
           </tp:rationale>
-
-        <p>This property is immutable, and therefore SHOULD be announced
-          in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>,
-          etc.</p>
       </tp:docstring>
     </property>
 
@@ -862,32 +1344,32 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <tp:hct name="gtalk-p2p">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The client can implement streaming for streams whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
-          property is Stream_Transport_Type_GTalk_P2P.</p>
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_GTalk_P2P.</p>
       </tp:docstring>
     </tp:hct>
 
     <tp:hct name="ice">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The client can implement streaming for streams whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
-          property is Stream_Transport_Type_ICE.</p>
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_ICE.</p>
       </tp:docstring>
     </tp:hct>
 
-    <tp:hct name="wlm-8.5">
+    <tp:hct name="wlm-2009">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The client can implement streaming for streams whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
-          property is Stream_Transport_Type_WLM_8_5.</p>
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_WLM_2009.</p>
       </tp:docstring>
     </tp:hct>
 
-    <tp:hct name="wlm-2009">
+    <tp:hct name="shm">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The client can implement streaming for streams whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
-          property is Stream_Transport_Type_WLM_2009.</p>
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_SHM.</p>
       </tp:docstring>
     </tp:hct>
 
@@ -918,7 +1400,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>For example, a client could advertise support for audio and video
           calls using Speex, Theora and H264 by having five handler capability
           tokens in its <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref>
+          namespace="ofdT.Client.Handler">Capabilities</tp:dbus-ref>
           property:</p>
 
         <ul>
diff --git a/spec/Channel_Type_Contact_Search.xml b/spec/Channel_Type_Contact_Search.xml
index de58bfc..335c71f 100644
--- a/spec/Channel_Type_Contact_Search.xml
+++ b/spec/Channel_Type_Contact_Search.xml
@@ -352,7 +352,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           while the SearchState is In_Progress,
           <tp:member-ref>SearchStateChanged</tp:member-ref> will be emitted,
           with the state Failed and the error
-          <code>org.freedesktop.Telepathy.Errors.Cancelled</code>.</p>
+          <code>org.freedesktop.Telepathy.Error.<tp:error-ref>Cancelled</tp:error-ref></code>.</p>
 
         <p>Calling this method on a search in state Completed or Failed
           succeeds, but has no effect.</p>
diff --git a/spec/Channel_Type_Room_List.xml b/spec/Channel_Type_Room_List.xml
index 6d6ce31..98f7458 100644
--- a/spec/Channel_Type_Room_List.xml
+++ b/spec/Channel_Type_Room_List.xml
@@ -84,7 +84,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dd>A description of the room's overall purpose</dd>
 
           <dt>subject (s)</dt>
-          <dd>The current subject of conversation in the room</dd>
+          <dd>The current subject of conversation in the room (as would
+            be returned by getting the string part of the <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+            >Subject</tp:dbus-ref> property)</dd>
 
           <dt>members (u)</dt>
           <dd>The number of members in the room</dd>
@@ -94,6 +97,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <dt>invite-only (b)</dt>
           <dd>True if you cannot join the room, but must be invited</dd>
+
+          <dt>room-id (s)</dt>
+          <dd>The human-readable identifier of a chat room (as would be
+            returned by getting the <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+            >RoomID</tp:dbus-ref> property)</dd>
+
+          <dt>server (s)</dt>
+          <dd>The DNS name of the server hosting these channels (as would be
+            returned by getting the <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+            >Server</tp:dbus-ref> property)</dd>
         </dl>
       </tp:docstring>
     </signal>
diff --git a/spec/Channel_Type_Server_TLS_Connection.xml b/spec/Channel_Type_Server_TLS_Connection.xml
new file mode 100644
index 0000000..1f3348e
--- /dev/null
+++ b/spec/Channel_Type_Server_TLS_Connection.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Type_Server_TLS_Connection"
+    xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright> Copyright © 2010 Collabora Limited </tp:copyright>
+  <tp:license>
+    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
+    Lesser 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.Type.ServerTLSConnection">
+    <tp:added version="0.19.13">(as stable API)</tp:added>
+
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>A channel type that carries a TLS certificate between a server
+      and a client connecting to it.</p>
+      <p>Channels of this kind always have <tp:dbus-ref
+      namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref> = False,
+      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+      = None and <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+      = 0, and cannot be requested with methods such as <tp:dbus-ref
+      namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+      Also, they SHOULD be dispatched while the
+      <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+      owning them is in the CONNECTING state.</p>
+      <p>In this case, handlers SHOULD accept or reject the certificate, using
+      the relevant methods on the provided object, or MAY just <tp:dbus-ref
+      namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> the channel before doing so, to fall
+      back to a non-interactive verification process done inside the CM.</p>
+      <p>For example, channels of this kind can pop up while a client is
+      connecting to an XMPP server.</p>
+    </tp:docstring>
+
+    <property name="ServerCertificate" type="o" access="read"
+              tp:name-for-bindings="Server_Certificate">
+      <tp:docstring>
+        <p>A <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
+        containing the certificate chain as sent by the server,
+        and other relevant information.</p>
+        <p>This property is immutable.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Hostname" type="s" access="read"
+              tp:name-for-bindings="Hostname">
+      <tp:added version="0.19.12"/>
+      <tp:docstring>
+        The hostname of the server we expect <tp:member-ref>ServerCertificate</tp:member-ref>
+        to certify; clients SHOULD verify <tp:member-ref>ServerCertificate</tp:member-ref> against
+	this hostname when checking its validity.
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
index 5445659..aa2b903 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/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index e3cd6b9..9cbfea2 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -454,18 +454,28 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:property name="subject" type="s">
       <tp:docstring>
       A human-readable description of the current subject of conversation in
-      the channel, similar to /topic in IRC.
+      the channel, similar to /topic in IRC. This is equivalent to the
+      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+      >Subject</tp:dbus-ref> property in the Room interface which will replace
+      this Telepathy property.
       </tp:docstring>
     </tp:property>
     <tp:property name="subject-contact" type="u" tp:type="Contact_Handle">
       <tp:docstring>
       A contact handle representing who last modified the subject, or 0
-      if it isn't known.
+      if it isn't known. This is equivalent to the
+      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+      >Subject</tp:dbus-ref> property in the Room interface which will replace
+      this Telepathy property.
       </tp:docstring>
     </tp:property>
     <tp:property name="subject-timestamp" type="u" tp:type="Unix_Timestamp">
       <tp:docstring>
       A unix timestamp indicating when the subject was last modified.
+      This is equivalent to the
+      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+      >Subject</tp:dbus-ref> property in the Room interface which will replace
+      this Telepathy property.
       </tp:docstring>
     </tp:property>
 
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index 10a16bd..2cceed1 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -279,11 +279,21 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
 
       <arg name="Handler_Info" type="a{sv}" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Additional information about these channels. No keys are
-            currently defined.</p>
-
-          <p>If keys are defined for this dictionary, all will be optional;
-            handlers MAY safely ignore any entry in this dictionary.</p>
+          <p>Additional information about these channels. Currently defined
+            keys are:</p>
+
+          <dl>
+            <dt><code>request-properties</code> - a{oa{sv}}</dt>
+            <dd>A map from <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              paths listed in <var>Requests_Satisfied</var> to
+              <tp:type>Qualified_Property_Value_Map</tp:type>s containing
+              namespaced immutable properties of each request.</dd>
+          </dl>
+
+          <p>When more keys are defined for this dictionary, all will be
+            optional; handlers MAY safely ignore any entry in this
+            dictionary.</p>
         </tp:docstring>
       </arg>
 
diff --git a/spec/Client_Handler_Future.xml b/spec/Client_Handler_Future.xml
index 776fa4f..4c1a8b7 100644
--- a/spec/Client_Handler_Future.xml
+++ b/spec/Client_Handler_Future.xml
@@ -33,15 +33,38 @@
         API or ABI guarantees.</p>
     </tp:docstring>
 
+    <property name="BypassObservers" tp:name-for-bindings="Bypass_Observers"
+      type="b" access="read">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, channels destined for this handler are not passed to
+          observers for observing.</p>
+
+        <tp:rationale>
+          <p>This is useful in use-cases where the handler doesn't want anyone
+            observing the channel - for example, because channels it handles
+            shouldn't be logged.</p>
+        </tp:rationale>
+
+        <p>For service-activatable handlers, this property should be specified
+          in the handler's <tt>.client</tt> file as follows:</p>
+
+<pre>
+[org.freedesktop.Telepathy.Client.Handler]
+BypassObservers=true
+</pre>
+      </tp:docstring>
+    </property>
+
     <property name="RelatedConferencesBypassApproval"
       tp:name-for-bindings="Related_Conferences_Bypass_Approval"
       type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, channels destined for this handler that have the
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.DRAFT</tp:dbus-ref> interface, with a channel that
+            >Conference</tp:dbus-ref> interface, with a channel that
           was previously handled by the same client process in their
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT"
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Conference"
             >InitialChannels</tp:dbus-ref> property, should bypass the
           approval stage. In effect, this is a weaker form of
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler"
diff --git a/spec/Client_Interface_Requests.xml b/spec/Client_Interface_Requests.xml
index f4c1108..cfab58d 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 912edaf..01fee8b 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -326,7 +326,9 @@ Recover=true
 
       <arg name="Requests_Satisfied" type="ao" direction="in">
         <tp:docstring>
-          The requests satisfied by these channels.
+          The <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>s
+          satisfied by these channels.
 
           <tp:rationale>
             If the same process is an Observer and a Handler, it can be useful
@@ -356,6 +358,13 @@ Recover=true
                 the same observer crashed).
               </tp:rationale>
             </dd>
+
+            <dt><code>request-properties</code> - a{oa{sv}}</dt>
+            <dd>A map from <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              paths listed in <var>Requests_Satisfied</var> to
+              <tp:type>Qualified_Property_Value_Map</tp:type>s containing
+              namespaced immutable properties of each request.</dd>
           </dl>
 
           <p>All defined keys for this dictionary are optional;
diff --git a/spec/Connection.xml b/spec/Connection.xml
index 3109670..a694e24 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -722,7 +722,7 @@ USA.</p>
             reasons SHOULD be treated like this reason.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Disconnected</code>.</p>
+            <code>org.freedesktop.Telepathy.Error.<tp:error-ref>Disconnected</tp:error-ref></code>.</p>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -896,7 +896,7 @@ USA.</p>
           <p>The server's SSL certificate is self-signed.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.HostnameMismatch</code>.
+            <code>org.freedesktop.Telepathy.Error.Cert.SelfSigned</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -911,6 +911,39 @@ USA.</p>
           </p>
         </tp:docstring>
       </tp:enumvalue>
+
+      <tp:enumvalue suffix="Cert_Revoked" value="14">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The server's SSL certificate has been revoked.</p>
+
+          <p>When disconnected for this reason, the equivalent D-Bus error is
+            <code>org.freedesktop.Telepathy.Error.Cert.Revoked</code>.
+          </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Cert_Insecure" value="15">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The server's SSL certificate uses an insecure algorithm,
+	  or is cryptographically weak.</p>
+
+          <p>When disconnected for this reason, the equivalent D-Bus error is
+            <code>org.freedesktop.Telepathy.Error.Cert.Insecure</code>.
+          </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Cert_Limit_Exceeded" value="16">
+	<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+	  <p>The length in bytes of the server certificate, or the depth of the
+	  sever certificate chain exceed the limits imposed by the crypto
+	  library.</p>
+
+	  <p>When disconnected for this reason, the equivalent D-Bus error is
+	    <code>org.freedesktop.Telepathy.Error.Cert.LimitExceeded</code>
+	  </p>
+	</tp:docstring>
+      </tp:enumvalue>
     </tp:enum>
 
     <signal name="ConnectionError" tp:name-for-bindings="Connection_Error">
@@ -952,7 +985,7 @@ USA.</p>
           <tp:type>Connection_Status_Reason</tp:type>, or may be a more
           specific Telepathy error
           (such as
-          <code>org.freedesktop.Telepathy.Errors.ConnectionRefused</code>
+          <code>org.freedesktop.Telepathy.Error.ConnectionRefused</code>
           for Connection_Status_Reason_Network_Error)
           or a protocol-specific or connection-manager-specific error in a
           suitable namespace.
@@ -977,13 +1010,10 @@ USA.</p>
             <dd>Debugging information on the change, corresponding to the
               message part of a D-Bus error message, which SHOULD NOT be
               displayed to users under normal circumstances</dd>
+	    <dt>user-requested (b), expected-hostname (s), certificate-hostname (s)</dt>
+	    <dd>The same details defined in <tp:type>TLS_Certificate_Rejection</tp:type>.</dd>
           </dl>
 
-          <tp:rationale>
-            <p>This argument allows for future extensions. For instance,
-              if indicating DNS lookup failure, we could define a key
-              that indicates the hostname that could not be found.</p>
-          </tp:rationale>
         </tp:docstring>
       </arg>
 
@@ -1020,6 +1050,125 @@ USA.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
+    <method name="AddClientInterest" tp:name-for-bindings="Add_Client_Interest">
+      <tp:added version="0.21.3"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Register a client's interest in notifications related to one or
+          more interfaces.</p>
+
+        <p>Groups of notifications are identified by a token which is either
+          a D-Bus interface name, or a string that starts with a D-Bus
+          interface name. The meaning of each token is given by that D-Bus
+          interface, which MUST define it in its documentation.</p>
+
+        <tp:rationale>
+          <p>Initially, all interests are in entire interface, but allowing
+            other strings allows subscription to part of an interface; for
+            instance, an interest in ...MailNotification/count could track
+            the number of messages without caring about their detailed
+            content.</p>
+        </tp:rationale>
+
+        <p>For each token with which this method interacts, the
+          Connection tracks an "interest count" (like a reference count) for
+          each unique bus name that has called this method. When a client
+          calls this method, for each token, the interest count for its
+          unique bus name is incremented; when
+          <tp:member-ref>RemoveClientInterest</tp:member-ref> is called,
+          all interest counts for that unique bus name are decremented.
+          If the unique bus name leaves the bus (for instance, if the
+          client crashes or exits), all interest counts for that unique bus
+          name are set to zero.</p>
+
+        <p>The Connection can then use these reference counts to
+          avoid subscribing to protocol-level notifications unless at least
+          one client has a non-zero interest count for the relevant
+          token.</p>
+
+        <tp:rationale>
+          <p>This method exists to reduce memory and network overhead when
+            there is no active subscription.</p>
+
+          <p>One situation where this is useful is <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Connection.Interface"
+              >Location</tp:dbus-ref>: on XMPP, location updates are received
+            over PEP. If the Connection advertises the
+            <code>geoloc+notify</code> capability, it will be sent location
+            updates for all contacts. To avoid consuming resources for this,
+            the connection should avoid advertising that capability until
+            a client has expressed an interest in contacts' locations.</p>
+
+          <p>Another example of a protocol that benefits from this method is
+            the Google XMPP Mail Notification extension, which can be used
+            to implement <tp:dbus-ref
+              namespace="org.freedesktop.Telepathy.Connection.Interface"
+              >MailNotification</tp:dbus-ref>. In this protocol, the CM
+            receives a notification that something has changed, but to get
+            more information, the CM must request this information. Knowing
+            that nobody is currently interested in this information, the CM
+            can avoid generating useless network traffic. Similarly, the CM
+            may free the list of unread messages to reduce memory overhead.</p>
+        </tp:rationale>
+
+        <p>If this method is called for an interface that might require
+          protocol-level subscription, but the connection cannot set up
+          that subscription yet (for instance because the
+          <tp:member-ref>Status</tp:member-ref> is not Connected yet), the
+          Connection MUST remember the client's interest, and attempt to
+          subscribe to the appropriate protocol feature when this becomes
+          possible.</p>
+
+        <p>Clients MAY ignore any errors raised by this method; it is intended
+          to be called with the reply ignored.</p>
+
+        <tp:rationale>
+          <p>The only reason it could fail is if it's unimplemented, in which
+            case the only thing the client can usefully do is to proceed as if
+            it had succeeded.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg name="Tokens" type="as" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Interfaces or parts of interfaces in which to register an
+            interest, represented by either a
+            <tp:type>DBus_Interface</tp:type>, or a string prefixed with a
+            <tp:type>DBus_Interface</tp:type>.</p>
+
+          <p>If the Connection does not support one of these tokens, this
+            is not considered to be an error; the unsupported token is
+            simply ignored.</p>
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <method name="RemoveClientInterest"
+      tp:name-for-bindings="Remove_Client_Interest">
+      <tp:added version="0.21.3"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Release an interest registered using
+          <tp:member-ref>AddClientInterest</tp:member-ref>. See that
+          method's documentation for details.</p>
+
+        <p>Clients MAY ignore any errors raised by this method; it is intended
+          to be called with the reply ignored.</p>
+
+        <tp:rationale>
+          <p>The only reasons it could fail are if it's unimplemented, or if
+            the client's reference-counting is wrong and it has tried to
+            remove a client interest that it did not add. In both cases,
+            there's nothing the client could do about it.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg name="Tokens" type="as" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Interfaces or parts of interfaces that were previously passed to
+            <tp:member-ref>AddClientInterest</tp:member-ref>.</p>
+        </tp:docstring>
+      </arg>
+    </method>
+
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This models a connection to a single user account on a communication
         service. Its basic capability is to provide the facility to request and
diff --git a/spec/Connection_Interface_Addressing.xml b/spec/Connection_Interface_Addressing.xml
new file mode 100644
index 0000000..497c6d0
--- /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_Anonymity.xml b/spec/Connection_Interface_Anonymity.xml
index 31f1554..704263c 100644
--- a/spec/Connection_Interface_Anonymity.xml
+++ b/spec/Connection_Interface_Anonymity.xml
@@ -111,60 +111,30 @@
     </property>
 
     <property name="AnonymityMandatory" type="b" access="readwrite"
-      tp:name-for-bindings="Anonymity_Mandatory">
+      tp:name-for-bindings="Anonymity_Mandatory"
+      tp:is-connection-parameter='yeah'>
       <tp:docstring>
         <p>This specifies whether or not the anonymity settings MUST be respected
           by the CM and any intermediaries between the local and remote contacts.
           If this is set to true but anonymity settings cannot be followed, then
           the session MUST be denied with a
-          <code>org.freedesktop.Telepathy.Errors.WouldBreakAnonymity</code>
+          <code>org.freedesktop.Telepathy.Error.<tp:error-ref>WouldBreakAnonymity</tp:error-ref></code>
           error.
           Any client that sets <tp:member-ref>AnonymityModes</tp:member-ref>
           SHOULD also set this property first (rather than accepting the CM's
           default value).</p>
-
-        <p>This property SHOULD also be made available as a parameter of the
-          same (fully-qualified) name to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ConnectionManager">RequestConnection</tp:dbus-ref>,
-          with the DBus_Property flag in its
-          <tp:type>Conn_Mgr_Param_Flags</tp:type>. 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.Anonymity.AnonymityMandatory": <var>new_value</var>
-              }, [])</code>
-        </blockquote>
       </tp:docstring>
     </property>
 
     <property name="AnonymityModes" type="u" tp:type="Anonymity_Mode_Flags"
-      access="readwrite" tp:name-for-bindings="Anonymity_Modes">
+      access="readwrite" tp:name-for-bindings="Anonymity_Modes"
+      tp:is-connection-parameter='yeah'>
       <tp:docstring>
         <p>The currently enabled anonymity modes for the connection. Setting
           has the effect of requesting new modes for the connection, and may
           raise an error if the unsupported modes are set. Successfully changing
           the modes will result in emission of
           <tp:member-ref>AnonymityModesChanged</tp:member-ref> signal.</p>
-
-        <p>This property SHOULD also be made available as a parameter of the
-          same (fully-qualified) name to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ConnectionManager">RequestConnection</tp:dbus-ref>,
-          with the DBus_Property flag in its
-          <tp:type>Conn_Mgr_Param_Flags</tp:type>. 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.Anonymity.AnonymityModes": <var>new_value</var>
-              }, [])</code>
-        </blockquote>
       </tp:docstring>
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
diff --git a/spec/Connection_Interface_Cellular.xml b/spec/Connection_Interface_Cellular.xml
index bf0f1a9..99a3602 100644
--- a/spec/Connection_Interface_Cellular.xml
+++ b/spec/Connection_Interface_Cellular.xml
@@ -30,7 +30,8 @@
     </tp:docstring>
 
     <property name="MessageValidityPeriod" tp:name-for-bindings="Message_Validity_Period"
-      type="u" access="readwrite">
+      type="u" access="readwrite"
+      tp:is-connection-parameter='yup'>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Define how long should the service centre try message delivery before
           giving up, failing delivery and deleting the message. A value of 0
@@ -40,55 +41,48 @@
           implementations may round the value up (eg. to a minute or hour
           precision). The maximum validity period may vary depending on
           protocol or provider.</p>
+      </tp:docstring>
+    </property>
 
-        <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.MessageValidityPeriod": <var>new_validity_period</var>
-              }, [])</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>
+    <property name="OverrideMessageServiceCentre"
+        tp:name-for-bindings="Override_Message_Service_Centre"
+        type="b" access="readwrite"
+        tp:is-connection-parameter='can i get a hell yeah?'>
+      <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>
       </tp:docstring>
     </property>
 
     <property name="MessageServiceCentre" tp:name-for-bindings="Message_Service_Centre"
-      type="s" access="readwrite">
+      type="s" access="readwrite"
+      tp:is-connection-parameter='HELL YEAH!!!'>
+      <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>
-
-        <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.MessageServiceCentre": <var>new_smsc_address</var>
-              }, [])</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>
+          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>
       </tp:docstring>
     </property>
 
@@ -120,7 +114,8 @@
 
     <property name="MessageReducedCharacterSet"
       tp:name-for-bindings="Message_Reduced_Character_Set"
-      type="b" access="readwrite">
+      type="b" access="readwrite"
+      tp:is-connection-parameter='no... just kidding! yes!'>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Determines whether SMSes containing characters that do not fit into
           a 7‐bit GSM character set should be sent as UCS‐2, or lossily
@@ -129,26 +124,6 @@
           financial cost of using twice as many SMSes); if <code>True</code>,
           the message will be recoded in an implementation‐specific way to fit
           into a country‐specific GSM reduced character set.</p>
-
-        <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.MessageReducedCharacterSet": <var>new_value</var>
-              }, [])</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>
   </interface>
diff --git a/spec/Connection_Interface_Client_Types.xml b/spec/Connection_Interface_Client_Types.xml
new file mode 100644
index 0000000..9790856
--- /dev/null
+++ b/spec/Connection_Interface_Client_Types.xml
@@ -0,0 +1,218 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Client_Types"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright (C) 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ClientTypes">
+    <tp:added version="0.21.1">(as stable API)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface on connections to support protocols which allows users to
+        subscribe to the client types of their contacts.</p>
+
+      <p>One can connect to instant messaging networks on a huge variety of
+        devices, from PCs, to phones to consoles. It can be useful for users
+        to know what kind of device a contact is using so that he or she
+        can decide not to send that big file or start a video chat. This
+        interface exposes exactly this information for clients to display.</p>
+
+      <p>The client types are represented in strings, using the values
+        <a href="http://xmpp.org/registrar/disco-categories.html#client">
+        documented by the XMPP registrar</a> with some additional types
+        added for other protocols. A contact can set one or more client types
+        so this interface returns a list of strings to denote client types
+        for a contact. The well-known client types to be used are:</p>
+
+      <ul>
+        <li>bot</li>
+        <li>console (minimal non-GUI client used on dumb terminals or
+          text-only screens, <strong>not</strong> a games console)</li>
+        <li>handheld</li>
+        <li>pc</li>
+        <li>phone</li>
+        <li>web</li>
+<!-- Excluding these two because there's been no conclusion regarding my mail
+     to standards@xmpp.org about adding these two to their list:
+
+        <li>sms (the client is not actually an instant messaging client
+          but all messages sent to this contact will be delivered as SMSs)</li>
+        <li>game (a gaming device)</li>
+-->
+      </ul>
+
+      <p>If the empty list is given as the client types, this means that
+        details about the contact's client types are unknown. If there are
+        multiple resources of a contact online at one point in time, the
+        client types of the most available resource will be returned. In
+        other words, the returned client types are those for the resource whose
+        presence will be retreived using the
+        <tp:dbus-ref namespace="ofdT.Connection.Interface">SimplePresence</tp:dbus-ref>
+        interface.</p>
+
+      <p>For example, if a contact has two resources:</p>
+
+      <ul>
+        <li>their phone, with presence "available"; and</li>
+        <li>their pc, with presence "busy";</li>
+      </ul>
+
+      <p>then the methods in this interface will return an array (with
+      one element: "phone") as the client types because that is the more
+      available resource. If at some later time the contact's phone's presence
+      changes to "away", the
+      <tp:member-ref>ClientTypesUpdated</tp:member-ref> signal will
+      notify that the contact's client types attribute has changed from
+      ["phone"] to ["pc"],
+      because "busy" is a more available presence than "away".</p>
+
+    </tp:docstring>
+
+    <tp:mapping name="Contact_Client_Types">
+      <tp:docstring>
+        A mapping from contact handle to client types.
+      </tp:docstring>
+      <tp:member type="u" tp:type="Contact_Handle" name="Contact">
+        <tp:docstring>
+          A contact.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="as" name="Client_Types" tp:type="Contact_Client_Type[]">
+        <tp:docstring>
+          The contact's client types as documented earlier in this interface.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <method name="GetClientTypes" tp:name-for-bindings="Get_Client_Types">
+      <tp:docstring>
+        Return the client types of the given contacts, if they are
+        already known. If any of the given contacts' client types are
+        not known, request their current client types, but return
+        immediately without waiting for a reply; if a reply with a
+        non-empty client type array is later received for those
+        contacts, the
+        <tp:member-ref>ClientTypesUpdated</tp:member-ref> signal will
+        be emitted for them.
+
+        <tp:rationale>
+          This method is appropriate for "lazy" client type finding, for instance
+          displaying the client types (if available) of everyone in your contact
+          list.
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          The contacts whose client types should be returned or signalled.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Client_Types" type="a{uas}"
+        tp:type="Contact_Client_Types">
+        <tp:docstring>
+          The contacts' client types, if already known. Contacts whose client
+          types are not already known are omitted from the mapping; contacts known
+          to have no client type information appear in the mapping with an empty
+          list.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="RequestClientTypes" tp:name-for-bindings="Request_Client_Types">
+      <tp:docstring>
+        Return the current client types of the given contact. If necessary, make
+        a request to the server for up-to-date information, and wait for a
+        reply.
+
+        <tp:rationale>
+          This method is appropriate for use in a "Contact Information..."
+          dialog; it can be used to show progress information (while waiting
+          for the method to return), and can distinguish between various error
+          conditions.
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact whose client types should be returned.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Client_Types" type="as"
+        tp:type="Contact_Client_Type[]">
+        <tp:docstring>
+          The contact's client types. It MAY be empty, indicating that no client
+          type information was found.
+        </tp:docstring>
+      </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.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
+          <tp:docstring>
+            The requested contact does not allow the local user to see their
+            client type information.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="ClientTypesUpdated" tp:name-for-bindings="Client_Types_Updated">
+      <tp:docstring>
+        Emitted when a contact's client types change or become known.
+      </tp:docstring>
+
+      <arg name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact.
+        </tp:docstring>
+      </arg>
+      <arg name="Client_Types" type="as" tp:type="Contact_Client_Type[]">
+        <tp:docstring>
+          The contact's client types, or an empty list to indicate that nothing
+          is known about the contact's client types.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:contact-attribute name="client-types" type="as"
+      tp:type="Contact_Client_Type[]">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same mapping that would be returned by
+          <tp:member-ref>GetClientTypes</tp:member-ref> for this contact.
+          Omitted from the result if the contact's client types are not
+          known.</p>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <tp:simple-type name="Contact_Client_Type" type="s"
+      array-name="Contact_Client_Type_List">
+      <tp:docstring>A string representing a single client type of a
+        contact.</tp:docstring>
+    </tp:simple-type>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Communication_Policy.xml b/spec/Connection_Interface_Communication_Policy.xml
new file mode 100644
index 0000000..9a92fa0
--- /dev/null
+++ b/spec/Connection_Interface_Communication_Policy.xml
@@ -0,0 +1,163 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Communication_Policy"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Limited</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+  </tp:license>
+
+  <interface
+     name="org.freedesktop.Telepathy.Connection.Interface.CommunicationPolicy.DRAFT"
+     tp:causes-havoc="experimental">
+    <tp:added version="0.21.1">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>
+        This interface supports controlling which contacts are allowed
+        to initiate text chats, incoming calls, and other forms of
+        communication as supported by the underlying protocol. The
+        policies supported for different communication methods on this
+        connection are listed in the
+        <tp:member-ref>SupportedPolicies</tp:member-ref> property. The
+        current configuration is held in
+        <tp:member-ref>ActivePolicies</tp:member-ref>; it can be modified
+        using <tp:member-ref>SetPolicy</tp:member-ref>, and changes
+        are signalled by <tp:member-ref>PolicyChanged</tp:member-ref>.
+      </p>
+    </tp:docstring>
+
+    <tp:mapping name="Active_Policies_Map">
+      <tp:docstring>
+        A mapping of communication methods (channel types), and their
+        associated policy.
+      </tp:docstring>
+
+      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type">
+        <tp:docstring>
+          The channel interface with the policy.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="(uv)" tp:type="Access_Control" name="Active_Policy">
+        <tp:docstring>
+          The active policy for this channel type.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <property name="SupportedPolicies"
+              tp:name-for-bindings="Supported_Policies" access="read"
+              type="a(asau)" tp:type="Supported_Policy[]">
+      <tp:docstring>
+        The communication policies supported by this connection.
+      </tp:docstring>
+    </property>
+
+    <property name="ActivePolicies" tp:name-for-bindings="Active_Policies"
+              access="read" type="a{s(uv)}" tp:type="Active_Policies_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The active communication policies on this
+        connection. Communication methods that are not in this
+        mapping are considered open.</p>
+
+        <p>For example, to allow incoming calls only from contacts
+          buddy list, and to allow text messages from anyone,
+          the policy would look like this:</p>
+
+        <pre>
+{
+    'org.freedesktop.Telepathy.Channel.Type.Text' : Access_Control_Type_Open,
+    'org.freedesktop.Telepathy.Channel.Type.Call' : Access_Control_Type_Publish_List
+}
+        </pre>
+
+        <p>Changes to this property are signalled by
+          <tp:member-ref>PolicyChanged</tp:member-ref>.</p>
+      </tp:docstring>
+    </property>
+
+    <method name="SetPolicy" tp:name-for-bindings="Set_Policy">
+      <tp:docstring>
+        Set a policy for a communication method (channel
+        type). Depending on the server or protocol, more than one
+        communication method could be bound to the same policy, if
+        calling this method on one channel type changes the policy on
+        another channel type, the <tp:member-ref>PolicyChanged</tp:member-ref>
+        signal that would follow would include all the channel types
+        that have an altered policy.
+      </tp:docstring>
+      <arg name="Channel_Type" direction="in" type="s"
+           tp:type="DBus_Interface">
+        <tp:docstring>
+          The channel type to set the policy for.
+        </tp:docstring>
+      </arg>
+      <arg name="Policy" direction="in" type="(uv)"
+           tp:type="Access_Control">
+        <tp:docstring>
+          The policy to set for this channel.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <signal name="PolicyChanged" tp:name-for-bindings="Policy_Changed">
+      <tp:docstring>
+        <tp:member-ref>ActivePolicies</tp:member-ref> has
+        changed. This occurs when the server unilaterally changed the
+        policy or <tp:member-ref>SetPolicy</tp:member-ref> has been
+        called.
+      </tp:docstring>
+      <arg name="Changed_Policies" type="a{s(uv)}"
+           tp:type="Active_Policies_Map">
+        <tp:docstring>
+          A subset of the active policies that have changed.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:struct name="Supported_Policy" array-name="Supported_Policy_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The communication methods (channel types), and the policies
+        that can be applied to them. This is server and protocol
+        dependant.</p>
+
+        <p>Grouped channel types will always have the same policy applied
+        to them.</p>
+
+        <tp:rationale>
+          Different protocols have different limitations to the
+          granularity of communication policies. One protocol might be
+          able to set a different policy for VoIP calls and text chat,
+          while another protocol might only be able to set one policy
+          to both VoIP and text chat.
+        </tp:rationale>
+      </tp:docstring>
+      <tp:member type="as" tp:type="DBus_Interface[]"
+        name="Chanel_Types">
+        <tp:docstring>
+          A list of channel interfaces that support these policies.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="au" tp:type="Access_Control_Type[]"
+        name="Supported Policies">
+        <tp:docstring>
+          A list of supported policies.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+  </interface>
+</node>
diff --git a/spec/Connection_Interface_Contact_Groups.xml b/spec/Connection_Interface_Contact_Groups.xml
index 87ab752..5282a82 100644
--- a/spec/Connection_Interface_Contact_Groups.xml
+++ b/spec/Connection_Interface_Contact_Groups.xml
@@ -18,15 +18,63 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups.DRAFT"
-    tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"/>
-    <tp:added version="0.19.6">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList"/>
+    <tp:added version="0.21.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections in which contacts can be placed in
         user-defined groups.</p>
+
+      <p>The most basic functionality of this interface is to list and monitor
+        a contact's set of groups. To do this, use the
+        <tp:member-ref>GroupsChanged</tp:member-ref> signal, and the
+        <tp:token-ref>groups</tp:token-ref> contact attribute (this should
+        usually be done by connecting to the GroupsChanged signal, then
+        calling <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.ContactList"
+          >GetContactListAttributes</tp:dbus-ref> with this interface
+        included in the Interfaces argument). Simple user interfaces can
+        limit themselves to displaying that information, and ignore the rest
+        of this interface: to ensure that this works,
+        <tp:member-ref>GroupsChanged</tp:member-ref> is emitted for every
+        change, even if that change could be inferred from another signal
+        such as <tp:member-ref>GroupsRemoved</tp:member-ref>.</p>
+
+      <p>Looking at contacts' lists of groups is sufficient to present a
+        user interface resembling XMPP's data model, in which groups behave
+        like tags applied to contacts, and so an empty group cannot exist
+        or is not interesting. However, some protocols model groups as
+        objects in their own right. User interfaces may either track
+        the set of groups via the <tp:member-ref>Groups</tp:member-ref>
+        property and the <tp:member-ref>GroupsCreated</tp:member-ref> and
+        <tp:member-ref>GroupsRemoved</tp:member-ref> signals, or ignore
+        this extra information.</p>
+
+      <p>Similarly, in some protocols it is possible to rename a group as
+        a single atomic operation. Simpler user interfaces will
+        see the new name being created, the old name being removed, and the
+        members moving to the new name, via the signals described above.
+        More advanced user interfaces can optionally distinguish between an
+        atomic rename and a create/remove pair, and display renamed groups
+        differently, by monitoring the
+        <tp:member-ref>GroupRenamed</tp:member-ref> signal.</p>
+
+      <p>This interface also provides various methods to manipulate
+        user-defined groups, which can be expected to work if
+        <tp:member-ref>GroupStorage</tp:member-ref> is not None.</p>
+
+      <p>Depending on the protocol, some methods might be implemented by
+        more than one protocol operation; for instance, in a
+        "contact-centric" protocol like XMPP,
+        <tp:member-ref>SetContactGroups</tp:member-ref> is a single
+        protocol operation and <tp:member-ref>SetGroupMembers</tp:member-ref>
+        requires a protocol operation per contact, whereas in a more
+        "group-centric" protocol it might be the other way around. User
+        interfaces SHOULD call whichever method most closely resembles the
+        way in which the user's action was represented in the UI, and
+        let the connection manager deal with the details.</p>
     </tp:docstring>
 
     <property name="DisjointGroups" tp:name-for-bindings="Disjoint_Groups"
@@ -65,6 +113,26 @@
       </tp:docstring>
     </tp:contact-attribute>
 
+    <signal name="GroupsChanged" tp:name-for-bindings="Groups_Changed">
+      <tp:docstring>
+        Emitted when contacts' groups change.
+      </tp:docstring>
+
+      <arg name="Contact" type="au" tp:type="Contact_Handle">
+        <tp:docstring>The relevant contacts.</tp:docstring>
+      </arg>
+
+      <arg name="Added" type="as">
+        <tp:docstring>The names of groups to which the contacts were
+          added.</tp:docstring>
+      </arg>
+
+      <arg name="Removed" type="as">
+        <tp:docstring>The names of groups from which the contacts were
+          removed.</tp:docstring>
+      </arg>
+    </signal>
+
     <property name="Groups" type="as" access="read"
       tp:name-for-bindings="Groups">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -79,11 +147,9 @@
           distinguish between a create/remove pair and a renamed group by
           receiving <tp:member-ref>GroupRenamed</tp:member-ref>.</p>
 
-        <p>This property's value is not meaningful until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this property to be meaningful by calling
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"
-            >RequestContactList</tp:dbus-ref>.</p>
+        <p>This property's value is not meaningful until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> has become Success.</p>
       </tp:docstring>
     </property>
 
@@ -101,7 +167,9 @@
 
     <signal name="GroupRenamed" tp:name-for-bindings="Group_Renamed">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a group is renamed.</p>
+        <p>Emitted when a group is renamed, in protocols where this can
+          be distinguished from group creation, removal and membership
+          changes.</p>
 
         <p>Immediately after this signal is emitted,
           <tp:member-ref>GroupsCreated</tp:member-ref> MUST signal the
@@ -112,7 +180,7 @@
         <tp:rationale>
           <p>Emitting these extra signals, in this order, means that clients
             that are interested in the set of groups that exist (but treat a
-            rename and a create/remove pair identically) to ignore the
+            rename and a create/remove pair identically) can ignore the
             GroupRenamed signal entirely.</p>
         </tp:rationale>
 
@@ -168,26 +236,6 @@
       </arg>
     </signal>
 
-    <signal name="GroupsChanged" tp:name-for-bindings="Groups_Changed">
-      <tp:docstring>
-        Emitted when contacts' groups change.
-      </tp:docstring>
-
-      <arg name="Contact" type="au" tp:type="Contact_Handle">
-        <tp:docstring>The relevant contacts.</tp:docstring>
-      </arg>
-
-      <arg name="Added" type="as">
-        <tp:docstring>The names of groups to which the contacts were
-          added.</tp:docstring>
-      </arg>
-
-      <arg name="Removed" type="as">
-        <tp:docstring>The names of groups from which the contacts were
-          removed.</tp:docstring>
-      </arg>
-    </signal>
-
     <method name="SetContactGroups" tp:name-for-bindings="Set_Contact_Groups">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Add the given contact to the given groups (creating new groups
@@ -213,6 +261,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Contact" type="u" tp:type="Contact_Handle" direction="in">
@@ -239,6 +295,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -265,6 +322,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -286,6 +351,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -306,6 +372,14 @@
           <tp:member-ref>GroupsChanged</tp:member-ref> and
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -326,6 +400,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -341,6 +416,14 @@
         <p>Any <tp:member-ref>GroupsChanged</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -366,6 +449,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -378,6 +462,14 @@
         <p>Any <tp:member-ref>GroupsChanged</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Group" type="s" direction="in">
@@ -393,6 +485,7 @@
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -412,6 +505,14 @@
         <p>Any <tp:member-ref>GroupRenamed</tp:member-ref> or
           <tp:member-ref>GroupsRemoved</tp:member-ref> signals that result from
           this method call MUST be emitted before the method returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >ContactListState</tp:dbus-ref> changes to Success.
+          If the ContactListState is Failure, this method SHOULD raise the
+          same error as
+          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+            >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <arg name="Old_Name" type="s" direction="in">
@@ -439,6 +540,7 @@
           <tp:docstring>Raised if there is already a group with the new
             name.</tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Contact_List.xml b/spec/Connection_Interface_Contact_List.xml
index 9db86aa..d602c19 100644
--- a/spec/Connection_Interface_Contact_List.xml
+++ b/spec/Connection_Interface_Contact_List.xml
@@ -18,10 +18,9 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList.DRAFT2"
-    tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:added version="0.19.8">(draft 2)</tp:added>
+    <tp:added version="0.21.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections that have any concept of a list of
@@ -35,7 +34,7 @@
         <p>In some protocols (like link-local XMPP), while there might not be
           any server or roster, it's possible to list "nearby" contacts.</p>
 
-        <p>In Telepathy 0.18 and older, we represented contact lists as a
+        <p>In Telepathy 0.20 and older, we represented contact lists as a
           collection of <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Channel.Type"
             >ContactList</tp:dbus-ref> channels. This is remarkably difficult to
@@ -46,87 +45,115 @@
       </tp:rationale>
 
       <p>The list of contacts is not exposed as a D-Bus property; it can be
-        fetched using <tp:member-ref>RequestContactList</tp:member-ref>.
+        fetched using <tp:member-ref>GetContactListAttributes</tp:member-ref>.
       </p>
 
       <tp:rationale>
         <p>In some protocols, such as XMPP, the contact list may not be
           available immediately. The
-          <tp:member-ref>RequestContactList</tp:member-ref> method
-          will wait until the contact list is available before returning.
+          <tp:member-ref>GetContactListAttributes</tp:member-ref> method
+          will fail until the contact list is available.
           Using a method also allows extra attributes to be retrieved at
           the same time.</p>
       </tp:rationale>
     </tp:docstring>
 
-    <method name="RequestContactList"
-      tp:name-for-bindings="Request_Contact_List">
-      <tp:changed version="0.19.8">(in draft: renamed from
-        GetContactListAttributes)</tp:changed>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Return some contact attributes for a list of contacts somehow
-          associated with the user.</p>
+    <tp:enum name="Contact_List_State" type="u">
+      <tp:docstring>
+        The progress made in retrieving the contact list.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring>The connection has not started to retrieve the contact
+          list. If <tp:member-ref>GetContactListAttributes</tp:member-ref> is
+          called in this state, it will raise NotYet.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Waiting" value="1">
+        <tp:docstring>The connection has started to retrieve the contact
+          list, but has not yet succeeded or failed.
+          If <tp:member-ref>GetContactListAttributes</tp:member-ref> is called
+          in this state, it will raise NotYet.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Failure" value="2">
+        <tp:docstring>
+          <p>The connection has tried and failed to retrieve the contact
+            list. If <tp:member-ref>GetContactListAttributes</tp:member-ref>
+            is called in this state, it will immediately raise an error
+            indicating the reason for failure.</p>
+
+          <p>The connection manager SHOULD try again to obtain the contact
+            list, if appropriate for the protocol. If it succeeds later,
+            the <tp:member-ref>ContactListState</tp:member-ref> MUST advance
+            to Success.</p>
+        </tp:docstring>
+      </tp:enumvalue>
 
-        <p>This definition is deliberately vague: in practice, most user
-          interfaces should display some subset of this list, by filtering it
-          by some contact attributes (for instance, displaying all contacts
-          whose "subscribe" attribute is Yes is expected to be a common case).
-          This list MAY contain any contacts whatsoever, but MUST contain
-          at least the following:</p>
+      <tp:enumvalue suffix="Success" value="3">
+        <tp:docstring>The connection has successfully retrieved the contact
+          list. If <tp:member-ref>GetContactListAttributes</tp:member-ref>
+          is called in this state, it will return successfully.</tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="ContactListState" tp:name-for-bindings="Contact_List_State"
+      type="u" tp:type="Contact_List_State" access="read">
+      <tp:docstring>
+        The progress made in retrieving the contact list.
+        Change notification is via
+        <tp:member-ref>ContactListStateChanged</tp:member-ref>.
+      </tp:docstring>
+    </property>
+
+    <signal name="ContactListStateChanged"
+      tp:name-for-bindings="Contact_List_State_Changed">
+      <tp:docstring>
+        Emitted when <tp:member-ref>ContactListState</tp:member-ref>
+        changes.
+      </tp:docstring>
+
+      <arg name="Contact_List_State" type="u" tp:type="Contact_List_State">
+        <tp:docstring>
+          The new value of <tp:member-ref>ContactListState</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="GetContactListAttributes"
+      tp:name-for-bindings="Get_Contact_List_Attributes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Return some contact attributes for a list of contacts
+          associated with the user. This list MUST include at least:</p>
 
         <ul>
-          <li>all contacts whose "subscribe" attribute is Ask or Yes</li>
-          <li>all contacts whose "publish" attribute is Ask or Yes</li>
-          <li>all contacts with a persistently-stored stored alias, if
-            supported</li>
-          <li>all contacts in user-defined contact groups, if supported</li>
+          <li>all contacts whose <tp:token-ref>subscribe</tp:token-ref>
+            attribute is not No</li>
+          <li>all contacts whose <tp:token-ref>publish</tp:token-ref>
+            attribute is not No</li>
         </ul>
 
-        <p>This list does not need to contain every visible contact: for
-          instance, contacts seen in XMPP or IRC chatrooms SHOULD NOT appear
-          here. Blocked contacts SHOULD NOT appear here either, unless they
-          are still stored in a persistent roster/contact list as well as
-          being blocked.</p>
+        <p>but MAY contain other contacts.</p>
 
         <tp:rationale>
-          <p>This is basically the union of the historical <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type"
-              >ContactList</tp:dbus-ref> subscribe, publish and stored
-            channels.</p>
-
-          <p>For example, XMPP, it's the roster; on link-local XMPP, it's the
-            set of visible users on the local network; on MSN, it's the union
-            of the forward and reverse buddy lists.</p>
-
-          <p>An easy way for an application to display a contact list is to
-            call this method with at least this interface in the Interfaces
-            argument, then check which subset of contacts should be displayed
-            (perhaps based on their subscribe attribute, for instance) and display
-            them. Any additional information required to display the contact
-            list, like aliases or presence, can be retrieved at the same
-            time.</p>
-
-          <p>In practice, most user interfaces for the contact list will
-            usually display a large proportion of this list
-            (for instance, most contacts on the contact list will usually
-            have subscribe=Yes in practice, so contact lists that display
-            subscribe=Yes contacts need to display almost the entire list),
-            so the overhead of returning information about too many contacts
-            is small.</p>
+          <p>For instance, on XMPP, all contacts on the roster would appear
+            here even if they have subscription="none", unless there's
+            reason to believe the user does not want to see them (such as
+            having been blocked).</p>
         </tp:rationale>
 
-        <p>This method SHOULD NOT return before the contact list has been
-          retrieved, on protocols where this is possible. As a result,
-          clients SHOULD use a longer-than-default timeout for this method
-          call, since retrieving the contact list can take a significant
-          time on some servers.</p>
+        <p>This list does not need to contain every visible contact: for
+          instance, contacts seen in XMPP or IRC chatrooms SHOULD NOT appear
+          here. Blocked contacts SHOULD NOT appear here, unless they still
+          have a non-<tt>No</tt> <tp:token-ref>subscribe</tp:token-ref> or
+          <tp:token-ref>publish</tp:token-ref> attribute
+          for some reason.</p>
 
         <tp:rationale>
-          <p>This makes it possible for clients to wait for the contact list.
-            For instance, on XMPP this method shouldn't return until the
-            roster has been retrieved, which is an asynchronous process.
-            However, on link-local XMPP you can't know when you have the
-            complete list, so this method would have to return immediately.</p>
+          <p>It's reasonable to assume that blocked contacts should not be
+            visible to the user unless they specifically go looking for them,
+            at least in protocols like XMPP where blocking a contact
+            suppresses presence.</p>
         </tp:rationale>
       </tp:docstring>
 
@@ -150,12 +177,6 @@
             Equivalent to the corresponding argument to <tp:dbus-ref
               namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
               >GetContactAttributes</tp:dbus-ref>.</p>
-
-          <p><em>FIXME: if we do distributed refcounting, we should probably
-              rename this to 'Reference' and implement handle-refcounting
-              semantics first? On the other hand, if we make handles persist
-              for the lifetime of the connection, we can just remove this
-              parameter.</em></p>
         </tp:docstring>
       </arg>
 
@@ -171,31 +192,64 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+            <p>The <tp:member-ref>ContactListState</tp:member-ref> is
+              None or Waiting. In particular, this error is raised if the
+              <tp:dbus-ref namespace="ofdT.Connection">Status</tp:dbus-ref>
+              is not yet Connection_Status_Connected.</p>
+          </tp:docstring>
+        </tp:error>
       </tp:possible-errors>
     </method>
 
-    <tp:enum name="Presence_State" type="u">
+    <tp:enum name="Subscription_State" type="u">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A tristate indicating whether presence subscription is denied,
+        <p>An enumeration indicating whether presence subscription is denied,
           denied but pending permission, or allowed. The exact semantics
-          vary according to where this type is used.</p>
+          vary according to where this type is used: see the
+          <tp:token-ref>subscribe</tp:token-ref> and
+          <tp:token-ref>publish</tp:token-ref> contact attributes for
+          details.</p>
       </tp:docstring>
 
-      <tp:enumvalue suffix="No" value="0">
-        <tp:docstring>Presence information cannot be seen.</tp:docstring>
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring>The presence subscription state is
+          unknown.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="No" value="1">
+        <tp:docstring>Presence information cannot be seen, and either the
+          subscription state Removed_Remotely does not apply, or it is
+          not known whether that state applies.
+        </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Ask" value="1">
-        <tp:docstring>Presence information cannot be seen, but permission
-          to see presence information has been requested.</tp:docstring>
+
+      <tp:enumvalue suffix="Removed_Remotely" value="2">
+        <tp:docstring>Presence information cannot be seen because the
+          remote contact took action: either the local user's request to
+          see the remote contact's presence was denied, or the remote
+          contact requested to see the local user's presence but then
+          cancelled their request.</tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Ask" value="3">
+        <tp:docstring>Presence information cannot be seen. Permission
+          to see presence information has been requested, and the request
+          has not yet been declined or accepted.</tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Yes" value="2">
+
+      <tp:enumvalue suffix="Yes" value="4">
         <tp:docstring>Presence information can be seen.</tp:docstring>
       </tp:enumvalue>
     </tp:enum>
 
     <tp:contact-attribute name="subscribe"
-      type="u" tp:type="Presence_State">
+      type="u" tp:type="Subscription_State">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If this attribute on a contact is Yes, this connection can
           expect to receive their presence, along with any other information
@@ -207,7 +261,7 @@
             the local user's buddy list" in ICQ, for example.</p>
         </tp:rationale>
 
-        <p>If this attribute is No or Ask, the local user cannot generally
+        <p>If this attribute is not Yes, the local user cannot generally
           expect to receive presence from this contact. Their presence status
           as returned by <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.SimplePresence">GetPresences</tp:dbus-ref>
@@ -229,18 +283,30 @@
             asked during the current session will ever have Ask status.</p>
         </tp:rationale>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>If this attribute is Removed_Remotely, this indicates that the
+          local user has asked to receive the contact's presence at some time,
+          but the remote contact has rejected that request, and a local
+          user interface has not yet acknowledged this. It is
+          implementation-dependent whether contacts' subscribe attributes can
+          remain set to Removed_Remotely, or are reset to No, when the
+          connection disconnects.</p>
+
+        <p>After notifying the user, user interfaces MAY acknowledge a change
+          to <tt>subscribe</tt>=Removed_Remotely by calling either
+          <tp:member-ref>Unsubscribe</tp:member-ref> or
+          <tp:member-ref>RemoveContacts</tp:member-ref>, which will set
+          <tt>subscribe</tt> to No (and perhaps remove the contact). This
+          allows user interfaces to detect that the user has been notified
+          about the rejected request.</p>
+
+        <p>This attribute's value will be Unknown or omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
     <tp:contact-attribute name="publish"
-      type="u" tp:type="Presence_State">
+      type="u" tp:type="Subscription_State">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If this attribute on a contact is Yes, the local user's presence
           is published to that contact, along with any other information that
@@ -254,12 +320,12 @@
             the contact's buddy list" in ICQ, for example.</p>
         </tp:rationale>
 
-        <p>If this attribute is No or Ask, the
+        <p>If this attribute is not Yes, the
           local user's presence is not published to that contact; however,
           if it is Ask, the contact has requested that the local user's
           presence is made available to them.</p>
 
-        <p>It is implementation-dependent whether contacts' publish
+        <p>It is implementation-dependent whether contacts' <tt>publish</tt>
           attributes can remain set to Ask, or are reset to No, when the
           connection disconnects.</p>
 
@@ -270,21 +336,32 @@
             during the current session will ever have Ask status.</p>
         </tp:rationale>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received, in protocols where this is applicable.
-          Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>If this attribute is Removed_Remotely, this indicates that the
+          remote contact has asked to receive the user's presence at some time,
+          but has then cancelled that request before a response was given by
+          the local user. User interfaces MAY reset <tt>publish</tt> from
+          Removed_Remotely to No, by calling either
+          <tp:member-ref>Unpublish</tp:member-ref> or
+          <tp:member-ref>RemoveContacts</tp:member-ref>.</p>
+
+        <p>If multiple factors affect whether a contact can receive the local
+          user's presence, this attribute SHOULD reflect the overall
+          result. For instance, an XMPP contact with subscription="to" or
+          subscription="both", but who has been blocked via
+          <a href="http://xmpp.org/extensions/xep-0016.html">XEP-0016 Privacy
+            Lists</a>, SHOULD have publish=No.</p>
+
+        <p>This attribute's value will be Unknown or omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
     <tp:contact-attribute name="publish-request" type="s">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If the "publish" attribute is Ask, an optional message that was
-          sent by the contact asking to receive the local user's presence;
-          omitted if none was given.</p>
+        <p>If the <tp:token-ref>publish</tp:token-ref> attribute is Ask, an
+          optional message that was sent by the contact asking to receive the
+          local user's presence; omitted if none was given.</p>
 
         <tp:rationale>
           <p>If the contact asking to receive our presence is also using
@@ -294,17 +371,14 @@
 
         <p>Otherwise, this SHOULD be omitted.</p>
 
-        <p>This attribute SHOULD be omitted from the
-          <tp:type>Contact_Attributes_Map</tp:type> returned by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-            >GetContactAttributes</tp:dbus-ref> until the initial contact
-          list has been received. Clients MAY wait for this by calling
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+        <p>This attribute will also be omitted until the
+          <tp:member-ref>ContactListState</tp:member-ref> has changed to
+          Success.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
-    <property name="SubscriptionsPersist"
-      tp:name-for-bindings="Subscriptions_Persist" type="b" access="read">
+    <property name="ContactListPersists"
+      tp:name-for-bindings="Contact_List_Persists" type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, presence subscriptions (in both directions) on this
           connection are stored by the server or other infrastructure.</p>
@@ -323,17 +397,17 @@
             presence from everyone else) so nothing is ever stored.</p>
         </tp:rationale>
 
-        <p>If <tp:member-ref>CanChangeSubscriptions</tp:member-ref>
+        <p>If <tp:member-ref>CanChangeContactList</tp:member-ref>
           is true, Telepathy clients (e.g. user interfaces or address books)
           MAY keep a record of permission to publish and requests to subscribe
           locally, and attempt to restore it for each Connection. If
-          SubscriptionsPersist is false, clients MAY do this for all contacts;
-          if SubscriptionsPersist is true, clients SHOULD NOT change the state
+          ContactListPersists is false, clients MAY do this for all contacts;
+          if ContactListPersists is true, clients SHOULD NOT change the state
           of contacts that were not changed locally.</p>
 
         <tp:rationale>
-          <p>In SIMPLE (SIP), SubscriptionsPersist is false, but
-            CanChangeSubscriptions is true. Presence will not be received
+          <p>In SIMPLE (SIP), ContactListPersists is false, but
+            CanChangeContactList is true. Presence will not be received
             unless clients renew any subscriptions they have for each
             connection, in the way described. There is no server-side storage,
             so clients have no alternative but to maintain independent contact
@@ -359,10 +433,45 @@
     </property>
 
     <tp:enum name="Contact_Metadata_Storage_Type" type="u">
-      <tp:docstring>
-        Values of this enumeration indicate the extent to which metadata
-        such as aliases and group memberships can be stored for the contacts
-        on a particular connection.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Values of this enumeration indicate the extent to which metadata
+          such as aliases and group memberships can be stored for the contacts
+          on a particular connection.</p>
+
+        <p>On some protocols, certain metadata (for instance, contact aliases)
+          can only be stored for contacts on the contact list, or contacts
+          with a particular contact list state.</p>
+
+        <p>To make it easier to deal with such protocols, if clients set
+          metadata on a contact who is not in the required state, the
+          Connection MUST cache the metadata for the duration of the session.
+          If clients request the attributes of that contact after the
+          appropriate "set" method has returned successfully, the Connection
+          MUST return the new (cached) value.</p>
+
+        <p>If the contact is later placed in the required state to store
+          metadata (for instance, if subscription to the contact's presence
+          is requested, on a protocol like MSN where the alias has storage type
+          Subscribed_Or_Pending), the connection MUST store the cached
+          metadata at that time.</p>
+
+        <tp:rationale>
+          <p>If the Connection didn't cache changes in this way, a client
+            intending to change the alias on MSN would have to wait until
+            the server acknowledged the subscription request; in the meantime,
+            other clients would still display the old alias.</p>
+        </tp:rationale>
+
+        <p>The only exception to that general rule is that if the Connection
+          cannot store particular metadata at all (i.e. the
+          storage type is None), it MUST reject attempts to set it.</p>
+
+        <tp:rationale>
+          <p>If the implementation knows that metadata can't be stored at
+            all, it's useful to report that, which can be done
+            synchronously. In general, user interfaces should detect
+            storage type None and not display editing controls at all.</p>
+        </tp:rationale>
       </tp:docstring>
 
       <tp:enumvalue suffix="None" value="0">
@@ -391,22 +500,6 @@
           <tp:rationale>
             <p>Contact aliases and groups on MSN have this behaviour.</p>
           </tp:rationale>
-
-          <p>If this type of metadata is set on a contact with subscribe=No,
-            the Connection MUST cache it until disconnected, and return it
-            if requested. If subscription to the contact's presence is
-            subsequently requested, making it possible to store this metadata,
-            the Connection MUST store the cached value at that time.</p>
-
-          <tp:rationale>
-            <p>This supports the recommended calling pattern for adding a
-              new contact, in which alias and groups are set (without
-              necessarily waiting for a reply) before requesting the
-              contact's presence. Until the subscription request is
-              processed by the server, the alias and groups will be cached
-              in memory; when the subscription request has been processed,
-              the connection manager will store the metadata on the server.</p>
-          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -419,19 +512,6 @@
             <p>No service with this behaviour is currently known, but it's a
               stricter form of Subscribed_Or_Pending.</p>
           </tp:rationale>
-
-          <p>If this type of metadata is set on a contact with subscribe != Yes,
-            the Connection MUST cache it until disconnected, and return it
-            if requested. If subscription to the contact's presence is
-            subsequently allowed, making it possible to store this metadata,
-            the Connection MUST store the cached value at that time.</p>
-
-          <tp:rationale>
-            <p>The same rationale applies as for Subscribed_Or_Pending,
-              except that metadata must be stored until the subscription
-              request is not only processed by the server, but also allowed
-              by the remote user.</p>
-          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -455,13 +535,13 @@
         A single contact's subscribe, publish and publish-request attributes.
       </tp:docstring>
 
-      <tp:member name="Subscribe" type="u" tp:type="Presence_State">
+      <tp:member name="Subscribe" type="u" tp:type="Subscription_State">
         <tp:docstring>
           The new value of the contact's "subscribe" attribute.
         </tp:docstring>
       </tp:member>
 
-      <tp:member name="Publish" type="u" tp:type="Presence_State">
+      <tp:member name="Publish" type="u" tp:type="Subscription_State">
         <tp:docstring>
           The new value of the contact's "publish" attribute.
         </tp:docstring>
@@ -500,19 +580,32 @@
         <p>Emitted when the contact list becomes available, when contacts'
           basic stored properties change, when new contacts are added to the
           list that would be returned by
-          <tp:member-ref>RequestContactList</tp:member-ref>,
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>,
           or when contacts are removed from that list.</p>
 
         <tp:rationale>
           <p>This provides change notification for that list, and for
-            contacts' "subscribe", "publish" and
-            "publish-request" attributes.</p>
+            contacts' <tp:token-ref>subscribe</tp:token-ref>,
+            <tp:token-ref>publish</tp:token-ref> and
+            <tp:token-ref>publish-request</tp:token-ref> attributes.</p>
+        </tp:rationale>
+
+        <p>Connection managers SHOULD also emit this signal when a contact
+          requests that the user's presence is published to them, even if
+          that contact's <tp:token>publish</tp:token> attribute is already
+          Ask and the <tp:token>publish-request</tp:token> has not changed.</p>
+
+        <tp:rationale>
+          <p>If the same contact sends 10 identical requests, 10 identical
+            signals should be emitted.</p>
         </tp:rationale>
       </tp:docstring>
 
       <arg type="a{u(uus)}" name="Changes" tp:type="Contact_Subscription_Map">
         <tp:docstring>
-          The new subscribe, publish and publish-request attributes of all the
+          The new <tp:token-ref>subscribe</tp:token-ref>,
+            <tp:token-ref>publish</tp:token-ref> and
+            <tp:token-ref>publish-request</tp:token-ref> attributes of all the
           contacts that have been added, and all the contacts for which those
           attributes have changed.
         </tp:docstring>
@@ -522,15 +615,15 @@
         <tp:docstring>
           The contacts that have been removed from the list that would be
           returned by
-          <tp:member-ref>RequestContactList</tp:member-ref>.
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.
           This also implies that they have subscribe = No and publish = No;
           contacts MUST NOT be listed both here and in Changes.
         </tp:docstring>
       </arg>
     </signal>
 
-    <property name="CanChangeSubscriptions" type="b" access="read"
-      tp:name-for-bindings="Can_Change_Subscriptions">
+    <property name="CanChangeContactList" type="b" access="read"
+      tp:name-for-bindings="Can_Change_Contact_List">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, presence subscription and publication can be changed
           using the
@@ -590,10 +683,10 @@
           request, with the given message, if allowed by the underlying
           protocol.</p>
 
-        <p>For contacts with subscribe=No, this method SHOULD request that
-          the contact allows the local user to subscribe to their presence;
-          in general, this will change their publish attribute from No
-          to Ask (although it could change directly from No to Yes in some
+        <p>For contacts with subscribe=No or subscribe=Rejected, this method
+          SHOULD request that the contact allows the local user to subscribe
+          to their presence; in general, this will change their publish
+          attribute to Ask (although it could change directly to Yes in some
           situations).</p>
 
         <p>Any state changes that immediately result from this request MUST
@@ -606,9 +699,20 @@
         </tp:rationale>
 
         <p>If the remote contact accepts the request, their subscribe
-          attribute will later change from Ask to Yes; if they explicitly
-          reject the request (in protocols that allow this), their subscribe
-          attribute will later change from Ask to No.</p>
+          attribute will later change from Ask to Yes.</p>
+
+        <p>If the remote contact explicitly rejects the request (in protocols
+          that allow this), their subscribe attribute will later change from
+          Ask to Rejected.</p>
+
+        <p>If the subscription request is cancelled by the local user, the
+          contact's subscribe attribute will change from Ask to No.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -643,10 +747,16 @@
         <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
         <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
+          </tp:docstring>
+        </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -714,6 +824,12 @@
           <p>This makes it easy for user interfaces to see what practical
             effect this method had.</p>
         </tp:rationale>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -730,7 +846,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -745,7 +867,7 @@
         <p>If possible, this method SHOULD set the contacts' subscribe and
           publish attributes to No, remove any stored aliases for those
           contacts, and remove the contacts from the result of
-          <tp:member-ref>RequestContactList</tp:member-ref>.</p>
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
 
         <p>This method SHOULD succeed even if it was not possible to carry out
           the request entirely or for all contacts (for instance, if there is an
@@ -764,6 +886,12 @@
             contact list's state), then consult its local cache of the
             contact list's state to see whether the contact is still there.</p>
         </tp:rationale>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -780,7 +908,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -801,6 +935,12 @@
           entirely or for all contacts; however, all signals that
           immediately result from this method call MUST be emitted before it
           returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -817,7 +957,7 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -838,6 +978,12 @@
           entirely or for all contacts; however, all signals that
           immediately result from this method call MUST be emitted before it
           returns.</p>
+
+        <p>This method SHOULD NOT be called until the
+          <tp:member-ref>ContactListState</tp:member-ref> changes to Success.
+          If the <tp:member-ref>ContactListState</tp:member-ref> changes to
+          Failure, this method SHOULD raise the same error as
+          <tp:member-ref>GetContactListAttributes</tp:member-ref>.</p>
       </tp:docstring>
 
       <arg name="Contacts" direction="in"
@@ -854,7 +1000,13 @@
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
-            <tp:member-ref>CanChangeSubscriptions</tp:member-ref> is false.
+            <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>
+            The <tp:member-ref>ContactListState</tp:member-ref> is None
+            or Waiting.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
diff --git a/spec/Connection_Interface_Keepalive.xml b/spec/Connection_Interface_Keepalive.xml
new file mode 100644
index 0000000..9f4ac68
--- /dev/null
+++ b/spec/Connection_Interface_Keepalive.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Keepalive"
+  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.Connection.Interface.Keepalive.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:added version="0.21.2">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Most messaging protocols allow the client to send periodic
+        content-less pings to the server when the connection is otherwise idle,
+        to reassure both itself and the server that its connection is still
+        alive. Depending on the nature of the network connection, and the
+        device running the client, the desired interval between such pings may
+        vary.</p>
+
+      <tp:rationale>
+        <p>For instance, on a mobile handset connected via 3G,
+          overly-frequent keepalives can drain the battery through needlessly
+          waking up the radio, and a relatively high interval is appropiate. By
+          contrast, a desktop computer is less likely to be asleep in the first
+          place, and users expect dropped connections to be noticed as soon as
+          possible.</p>
+      </tp:rationale>
+
+      <p>This interface provides a
+        <tp:member-ref>KeepaliveInterval</tp:member-ref> property which
+        controls the frequency of keepalive pings, if any. Connection managers
+        implementing this property should also include it in <tp:dbus-ref
+        namespace='org.freedesktop.Telepathy'>Protocol.Parameters</tp:dbus-ref>
+        with the <code>DBus_Property</code> flag, allowing the desired value to
+        be stored in <tp:dbus-ref
+          namespace='org.freedesktop.Telepathy'>Account.Parameters</tp:dbus-ref>
+        and passed onto the connection by the account manager.</p>
+    </tp:docstring>
+
+    <property name="KeepaliveInterval" type="u" access="readwrite"
+              tp:name-for-bindings="Keepalive_Interval"
+              tp:is-connection-parameter='och aye'>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The time in seconds between pings sent to the server to ensure that
+          the connection is still alive, or <tt>0</tt> to disable such
+          pings.</p>
+
+        <p>This property (and parameter) supersedes the older
+          <tt>keepalive-interval</tt>
+          <tp:type>Connection_Parameter_Name</tp:type>.</p>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Location.xml b/spec/Connection_Interface_Location.xml
index 6c69a80..fe54923 100644
--- a/spec/Connection_Interface_Location.xml
+++ b/spec/Connection_Interface_Location.xml
@@ -47,6 +47,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         or the XEP-0080-derived
         <a href="http://geoclue.freedesktop.org/">Geoclue</a> API where
         possible.</p>
+
+      <p>Clients of this interface SHOULD register an interest in it by calling
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          >Connection.AddClientInterest</tp:dbus-ref> with an argument
+        containing the name of this interface,
+        before calling any Location method. If they do so, they SHOULD also call
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          >Connection.RemoveClientInterest</tp:dbus-ref> after use to allow
+        the CM to release resources associated with this interface.</p>
     </tp:docstring>
 
     <!-- Potentially to be reinstated later:
@@ -250,19 +259,29 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:mapping>
 
     <method name="GetLocations" tp:name-for-bindings="Get_Locations">
-      <tp:docstring>
-        Return the current locations of the given contacts, if they are
-        already known. If any of the given contacts' locations are not known,
-        request their current locations, but return immediately without waiting
-        for a reply; if a reply with a non-empty location is later received
-        for those contacts, the <tp:member-ref>LocationUpdated</tp:member-ref>
-        signal will be emitted for them.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Return the current locations of the given contacts, if they are
+          already known. If any of the given contacts' locations are not known,
+          request their current locations, but return immediately without waiting
+          for a reply; if a reply with a non-empty location is later received
+          for those contacts, the <tp:member-ref>LocationUpdated</tp:member-ref>
+          signal will be emitted for them.</p>
 
         <tp:rationale>
-          This method is appropriate for "lazy" location finding, for instance
-          displaying the location (if available) of everyone in your contact
-          list.
+          <p>This method is appropriate for "lazy" location finding, for instance
+            displaying the location (if available) of everyone in your contact
+            list.</p>
         </tp:rationale>
+
+        <p>For backwards compatibility, if this method is called by a client
+          whose "interest count" for this interface, as defined by <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy"
+            >Connection.AddClientInterest</tp:dbus-ref>, is zero, the
+          Connection SHOULD behave as if AddClientInterest had been called for
+          this interface just before that method call. Clients that do not
+          explicitly call AddClientInterest SHOULD NOT call <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy"
+            >Connection.RemoveClientInterest</tp:dbus-ref> either.</p>
       </tp:docstring>
 
       <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
@@ -426,6 +445,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>GetLocations</tp:member-ref> for this contact.
           Omitted from the result if the contact's location
           is not known.</p>
+
+        <p>For backwards compatibility, if contact attributes that include
+          this interface are requested
+          by a client whose "interest count" for this interface, as defined by
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+            >Connection.AddClientInterest</tp:dbus-ref>, is zero, the
+          Connection SHOULD behave as if AddClientInterest was called for this
+          interface just before that request. Clients that do not explicitly
+          call AddClientInterest SHOULD NOT call <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy"
+            >Connection.RemoveClientInterest</tp:dbus-ref> either.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
diff --git a/spec/Connection_Interface_Mail_Notification.xml b/spec/Connection_Interface_Mail_Notification.xml
index cfe67a8..1ac6d1a 100644
--- a/spec/Connection_Interface_Mail_Notification.xml
+++ b/spec/Connection_Interface_Mail_Notification.xml
@@ -19,10 +19,9 @@ 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.MailNotification.DRAFT"
-    tp:causes-havoc="experimental">
+    name="org.freedesktop.Telepathy.Connection.Interface.MailNotification">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:added version="0.19.1">(as draft 1)</tp:added>
+    <tp:added version="0.21.3">(as stable API)</tp:added>
 
     <tp:flags name="Mail_Notification_Flags" value-prefix="Mail_Notification_Flag" type="u" >
       <tp:flag suffix="Supports_Unread_Mail_Count" value="1">
@@ -470,65 +469,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
-    <method name="Subscribe"
-        tp:name-for-bindings="Subscribe">
-      <tp:docstring>
-        <p>This method subscribes a client to the notification interface. This
-          MUST be called by clients before using this interface.</p>
-
-        <p>The Connection tracks a subscription count (like a refcount) for
-          each unique bus name that has called Subscribe(). When a client calls
-          Unsubscribe(), it releases one "reference". If a client exits
-          (or crashes), the Connection releases all "references" held on its
-          behalf.</p>
-
-        <tp:rationale>
-          <p>The reference count imposed on the subscription simplifies
-            implementation of client running in the same process
-            (e.g. plug-ins): two plug-ins interested in mail notification can
-            call Subscribe and Unsubscribe independently without interfering
-            with each other.</p>
-
-          <p>This method exists to reduce memory and network overhead when
-            there is no active subscription. An example of a protocol that
-            benefits from this method is the Google XMPP Mail Notification
-            extension: in this protocol, the CM receives a notification
-            that something has changed, but to get more information, the CM
-            must request this information. Knowing that nobody is currently
-            interested in this information, the CM can avoid generating
-            useless network traffic. Similarly, the CM may free
-            the list of unread messages to reduce memory overhead.</p>
-        </tp:rationale>
-
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="Unsubscribe"
-        tp:name-for-bindings="Unsubscribe">
-      <tp:docstring>
-        This method unsubscribes a client from the notification interface.
-        This SHOULD be called by each client that has successfully called
-        Subscribe when it no longer needs the mail notification interface.
-
-        <tp:rationale>
-          See <tp:member-ref>Subscribe</tp:member-ref> for rationale.
-        </tp:rationale>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            Raised if the client calling this method has no references to
-            release.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-      </tp:possible-errors>
-    </method>
-
     <method name="RequestInboxURL"
       tp:name-for-bindings="Request_Inbox_URL">
       <arg direction="out" name="URL" type="(sua(ss))" tp:type="Mail_URL" >
@@ -606,13 +546,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         connection manager to provide the necessary information for clients
         to open a web-based mail client without having to re-authenticate.</p>
 
-      <p>To use this interface, a client MUST first subscribe using the
-        <tp:member-ref>Subscribe</tp:member-ref> method. The subscription
+      <p>To use this interface, a client MUST first subscribe by passing the
+        name of this interface to the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy"
+          >Connection.AddClientInterest</tp:dbus-ref> method. The subscription
         mechanic aims at reducing network traffic and memory footprint in the
         situation where nobody is currently interesting in provided
         information. When done with this interface, clients SHOULD call
-        <tp:member-ref>Unsubscribe</tp:member-ref> to release resources in
-        the CM.</p>
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          >Connection.RemoveClientInterest</tp:dbus-ref> to allow the CM to
+        release resources.</p>
 
       <p>Protocols have various different levels of Mail Notification support.
         To describe the level of support, the interface provides a property
diff --git a/spec/Connection_Interface_Power_Saving.xml b/spec/Connection_Interface_Power_Saving.xml
new file mode 100644
index 0000000..ae82d2f
--- /dev/null
+++ b/spec/Connection_Interface_Power_Saving.xml
@@ -0,0 +1,110 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Power_Saving"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"
+  >
+  <tp:copyright> Copyright (C) 2007 Collabora Limited </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface
+    name="org.freedesktop.Telepathy.Connection.Interface.PowerSaving.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.19.12"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Some protocols support mechanisms for reducing bandwidth usage—and
+        hence power usage, on mobile devices—when the user is not directly
+        interacting with their IM client. For instance, Google Talk's XMPP
+        server supports queueing incoming presence updates at the client's
+        instruction; the client can instruct the server to deliver all
+        outstanding presence updates at a later time. This interface may be
+        used to instruct the connection manager to enable and disable such
+        protocol-level features when a screensaver is activated, the device
+        screen is locked, and so on, by calling the
+        <tp:member-ref>SetPowerSaving</tp:member-ref> method.</p>
+
+      <p>Enabling power saving SHOULD NOT change behaviour in any way
+        that is noticable to a user not actively interacting with their client.
+        For example, delaying presence updates somewhat is unlikely to be
+        noticed by a user not staring at their device waiting for a contact to
+        come online; on the other hand, requesting that the server queue
+        incoming messages would be noticable by the user, so is not an
+        acceptable effect of calling
+        <tp:member-ref>SetPowerSaving</tp:member-ref>.</p>
+    </tp:docstring>
+
+    <method name="SetPowerSaving" tp:name-for-bindings="Set_Power_Saving">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Turn power saving mode on or off.</p>
+
+        <tp:rationale>
+          <p>Depending on the device's activity level, the
+            connection can have its power saving mode turned on or off.</p>
+        </tp:rationale>
+
+        <p>Errors raised by this method indicate that power saving could not be
+          enabled, which SHOULD NOT generally be treated as fatal.</p>
+
+        <tp:rationale>
+          If the CM cannot switch modes, either because of the
+          protocol (<code>NotImplemented</code>), or because of the service
+          (<code>NotAvailable</code>), Mission Control (or whoever manages this)
+          should be made aware. The error could be ignored or, in the extreme,
+          be fascist and disconnect the account.
+        </tp:rationale>
+      </tp:docstring>
+
+      <arg direction="in" name="Activate" type="b">
+        <tp:docstring>
+          <code>True</code> if protocol-level power saving features should be
+          activated; <code>False</code> if they should be de-activated.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The current connection has no power saving features.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="PowerSavingActive" type="b" access="read"
+              tp:name-for-bindings="Power_Saving_Active">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p><code>True</code> if protocol-level power saving features are
+          currently activated. This property can be changed using the
+          <tp:member-ref>SetPowerSaving</tp:member-ref> method; change
+          notifications is via the
+          <tp:member-ref>PowerSavingChanged</tp:member-ref> signal.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="PowerSavingChanged"
+            tp:name-for-bindings="Power_Saving_Changed">
+      <arg name="Active" type="b">
+        <tp:docstring>
+          The new state of the power saving feature.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The <tp:member-ref>PowerSavingActive</tp:member-ref>
+        property changed.
+      </tp:docstring>
+    </signal>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Resources.xml b/spec/Connection_Interface_Resources.xml
new file mode 100644
index 0000000..716089c
--- /dev/null
+++ b/spec/Connection_Interface_Resources.xml
@@ -0,0 +1,212 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Resources"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.</p>
+
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.Resources.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.21.1">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface on connections to show contact attributes for
+        specific resources of a contact, if the protocol supports
+        multiple resources. Resources are most common in XMPP, hence the
+        name of this interface, but they are also present in MSN, where
+        they are called points of presence.</p>
+
+      <p>When a client requests some attribute of a contact using its
+        handle on the connection, the CM uses an algorithm to choose the
+        most appropriate resource for the job. If there is only one
+        resource, then the choice is obvious. If, however, there is more
+        than one resource connected at any one time, the CM either
+        aggregates all appropriate information to return (in the case of
+        capabilities), or chooses one specific resource (in the case of
+        presence).</p>
+
+      <p>Resources in XMPP have names, and it can be extremely useful
+        for the user to be able to know which resources of a contact are
+        online, providing the names are human-readable. Before now,
+        resources have not been exposed in Telepathy, but this interface
+        attempts to change this.</p>
+
+      <p>When using this interface, it is a little like using the
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface"
+        >Contacts</tp:dbus-ref> interface, but only resource-specific
+        attributes are ever returned. The resource-specific contact
+        attributes are decided on by the CM, but XMPP's are listed
+        below:</p>
+
+      <ul>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence/presence</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities/capabilities</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ClientTypes/client-types</tp:dbus-ref></li>
+      </ul>
+
+    </tp:docstring>
+
+    <method name="GetResources" tp:name-for-bindings="Get_Resources">
+      <tp:docstring>
+        Return the resource information of the given contacts. If any
+        of the contact attributes for specific resources of the given
+        contacts' are not known return immediately without waiting for
+        a reply.
+      </tp:docstring>
+
+      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          The contacts whose resource attributes should be returned.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Resources" type="a{ua{sa{sv}}}"
+        tp:type="Resources_Attributes_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The contacts' resources and the contact attributes specific
+            to each resource. If contact attributes are not immediately
+            known, the behaviour is defined by the interface; the
+            attribute should either be omitted from the result or
+            replaced with a default value.</p>
+
+          <p>For every contact handle passed into this method, it is
+            guaranteed that there will be a key in the returned map
+            that corresponds to said handle. If there is no information
+            regarding the contact the resource information map will be
+            empty.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+      </tp:possible-errors>
+    </method>
+
+    <tp:enum name="Resources_Human_Readability" type="u">
+      <tp:enumvalue suffix="Never" value="0">
+        <tp:docstring>
+          The resource string is never human-readable.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Maybe" value="1">
+        <tp:docstring>
+          The resource string might be human-readable.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="ResourcesHumanReadable" type="u" access="read"
+      tp:type="Resources_Human_Readability"
+      tp:name-for-bindings="Resources_Human_Readable">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Whether the resources returned from <tp:member-ref>GetResources</tp:member-ref>
+          are human readable or not.</p>
+
+        <p>If the connection manager knows that all resource names are
+          automatically generated, then the resource strings mean
+          nothing to the user. Showing these strings in the UI would
+          be confusing, so by setting this to
+          Resources_Human_Readability_Never, the UI is advised not to
+          show resources.</p>
+
+        <p>If on the other hand, all resources are set to nice names
+          (such as "office" or "home") then it might be wise to expose
+          these strings in the UI, so this property would be set to
+          Resources_Human_Readability_Maybe. This is the case in XMPP --
+          most resources are set in a way that the user can deduce some
+          information from them. The absence of an Always enum value is
+          because in the case of XMPP, the resource string could be
+          partially human-readable (as on Google Talk, where a resource
+          of "home" is changed by the server to a unique string like
+          "home_1234fdec") or not at all human-readable.</p>
+
+      </tp:docstring>
+    </property>
+
+    <signal name="ResourcesUpdated" tp:name-for-bindings="Resources_Updated">
+      <tp:docstring>
+        Emitted when a contact has a resource added or removed, or any
+        contact attribute for any resource changes.
+      </tp:docstring>
+
+      <arg name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact.
+        </tp:docstring>
+      </arg>
+      <arg name="Resources" tp:type="Resource_Information_Map"
+        type="a{sa{sv}}">
+        <tp:docstring>
+          The contact's resource information. All resource information
+          is given, not just the details which have changed.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:mapping name="Resource_Information_Map">
+      <tp:docstring>
+        A map of a contact's resources to their resource-specific
+        information.
+      </tp:docstring>
+
+      <tp:member name="Key" type="s">
+        <tp:docstring>
+          <p>The name of the resource.</p>
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member name="Contact_Attributes" type="a{sv}"
+        tp:type="Single_Contact_Attributes_Map">
+        <tp:docstring>
+          A map of contact attributes whose data is specific to this
+          resource.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:mapping name="Resources_Attributes_Map">
+      <tp:docstring>Mapping returned by
+        <tp:member-ref>GetResources</tp:member-ref>, representing a
+        collection of Contacts, their resources, and their
+        resource-specific contact attributes.</tp:docstring>
+
+      <tp:member type="u" tp:type="Contact_Handle" name="Contact">
+        <tp:docstring>
+          A contact.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="a{sa{sv}}" tp:type="Resource_Information_Map"
+        name="Resources">
+        <tp:docstring>
+          A map of the contact's resources to their resource-specific
+          information.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:contact-attribute name="resources" type="a{sa{sv}}"
+      tp:type="Resource_Information_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same mapping that would be returned by
+          <tp:member-ref>GetResources</tp:member-ref> for this contact.</p>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Simple_Presence.xml
index 5c7ae97..7788161 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Simple_Presence.xml
@@ -349,17 +349,95 @@
       </tp:enumvalue>
     </tp:enum>
 
+    <tp:enum name="Access_Control_Type" type="u"
+             array-name="Access_Control_Type_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A type for communication access control. These control
+          policies are used in
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">CommunicationPolicy.DRAFT</tp:dbus-ref>
+          as well as most rich presence interfaces.</p>
+
+        <p>New interfaces should use this type, and NOT
+          <tp:type>Rich_Presence_Access_Control_Type</tp:type>.</p>
+      </tp:docstring>
+      <tp:enumvalue suffix="Whitelist" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Only allow contacts that are in a certain whitelist.</p>
+
+          <p>The associated variant
+            in <tp:type>Access_Control</tp:type> is a list of
+            <tp:type>Contact_Handle</tp:type> representing
+            the whitelist, with signature <code>au</code>.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Publish_List" value="1">
+        <tp:docstring>
+          Allow contacts in the user's 'publish' list. The associated
+          variant in <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Group" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Only allow contacts that are in a certain group.</p>
+
+          <p>The associated variant in <tp:type>Access_Control</tp:type> is a
+            <tp:type>Group_Handle</tp:type> representing the permitted
+            group.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Open" value="3">
+        <tp:docstring>
+          Allow all contacts.  The associated
+          variant in <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Subscribe_Or_Publish_List" value="4">
+        <tp:docstring>
+          Allow all contacts in the user's 'subscribe' or 'publish'
+          list. The associated variant in <tp:type>Access_Control</tp:type> is
+          ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Closed" value="5">
+        <tp:docstring>
+          Forbid all contacts. The associated variant in
+          <tp:type>Access_Control</tp:type> is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Not_Understood" value="6">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The access control rule is too complex to be represented
+            in the current Telepathy API. The associated variant is
+            meaningless. Setting this mode is never valid; the
+            connection manager MUST raise an error if this is attempted.</p>
+
+          <tp:rationale>
+            XEP-0016 Privacy Lists can easily produce access control
+            mechanisms that can't be expressed in a simpler API. We
+            need to be able to at least indicate that fact.
+          </tp:rationale>
+
+          <p>The associated variant in <tp:type>Access_Control</tp:type> is
+            ignored.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
     <tp:enum name="Rich_Presence_Access_Control_Type" type="u"
       array-name="Rich_Presence_Access_Control_Type_List">
-      <tp:docstring>
-        A type of access control for Rich_Presence_Access_Control.
-        For most types, the exact access control is given by an associated
-        variant.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A type of access control for Rich_Presence_Access_Control.
+          For most types, the exact access control is given by an associated
+          variant.</p>
 
         <tp:rationale>
-          These are the access control types from XMPP publish/subscribe
-          (XEP-0060).
+          <p>These are the access control types from XMPP publish/subscribe
+          (XEP-0060).</p>
         </tp:rationale>
+
+        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
+          uses this for historical reasons, new interfaces will use
+          <tp:type>Access_Control_Type</tp:type>.</p>
       </tp:docstring>
 
       <tp:enumvalue suffix="Whitelist" value="0">
@@ -389,13 +467,42 @@
       </tp:enumvalue>
     </tp:enum>
 
+    <tp:struct name="Access_Control">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An access control mode for extended presence items like geolocation.
+          This type isn't actually used by the SimplePresence interface, but
+          it's included here so it can be referenced by rich presence
+          interfaces.</p>
+
+        <p>New interfaces should use this type, and NOT
+          <tp:type>Rich_Presence_Access_Control</tp:type>.</p>
+      </tp:docstring>
+
+      <tp:member name="Type" type="u" tp:type="Access_Control_Type">
+        <tp:docstring>
+          The type of access control to apply.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Detail" type="v">
+        <tp:docstring>
+          Any additional information required by the Type. The required
+          type and semantics are defined for each
+          <tp:type>Access_Control_Type</tp:type>.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
     <tp:struct name="Rich_Presence_Access_Control">
-      <tp:docstring>
-        An access control mode for extended presence items like geolocation.
-        This type isn't actually used by the SimplePresence interface, but
-        it's included here so it can be referenced by rich presence interfaces
-        such as <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>.
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An access control mode for extended presence items like geolocation.
+          This type isn't actually used by the SimplePresence interface, but
+          it's included here so it can be referenced by rich presence interfaces
+          such as <tp:dbus-ref
+                     namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>.</p>
+
+        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
+          uses this for historical reasons, new interfaces will use
+          <tp:type>Access_Control_Type</tp:type>.</p>
       </tp:docstring>
 
       <tp:member name="Type" type="u" tp:type="Rich_Presence_Access_Control_Type">
diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml
index 709a9b9..d75d866 100644
--- a/spec/Connection_Manager.xml
+++ b/spec/Connection_Manager.xml
@@ -147,13 +147,32 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:flag>
       <tp:flag suffix="DBus_Property" value="16">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          This parameter is also a D-Bus property on the resulting <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>; a
-          parameter named <code>com.example.Duck.Macaroni</code> with this flag
-          corresponds to the <code>Macaroni</code> property on the
-          <code>com.example.Duck</code> interface.  Its value can be queried
-          and possibly changed on an existing Connection using methods on the
-          <code>org.freedesktop.DBus.Properties</code> interface.
+          <p>This parameter is also a D-Bus property on the resulting
+            <tp:dbus-ref
+              namespace="ofdT">Connection</tp:dbus-ref>; a
+            parameter named <code>com.example.Duck.Macaroni</code> with this
+            flag corresponds to the <code>Macaroni</code> property on the
+            <code>com.example.Duck</code> interface.  Its value can be queried
+            and possibly changed on an existing Connection using methods on the
+            <code>org.freedesktop.DBus.Properties</code> interface.</p>
+
+          <p>When a parameter with this flag is changed with <tp:dbus-ref
+            namespace="ofdT">Account.UpdateParameters</tp:dbus-ref>, the
+            account manager will attempt to update its value on any running
+            connections. Thus, clients generally do not need to directly access
+            or update the connection property; instead, they SHOULD manipulate
+            <tp:dbus-ref namespace="ofdT">Account.Parameters</tp:dbus-ref>.</p>
+
+          <tp:rationale>
+            <p>This allows runtime-configurable options to be stored and
+              maintained by the <tp:dbus-ref
+              namespace='ofdT'>AccountManager</tp:dbus-ref>, without needing to
+              invent a separate account preference for “properties that should
+              be set on the connection as soon as it is created”. It was
+              originally invented to manage <tp:dbus-ref
+                namespace='ofdT.Connection.Interface'>Cellular</tp:dbus-ref>
+              preferences.</p>
+          </tp:rationale>
         </tp:docstring>
         <tp:added version="0.17.16"/>
       </tp:flag>
@@ -273,7 +292,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring>
           A dictionary mapping parameter names to values of the appropriate
           type, as indicated by <tp:member-ref>GetParameters</tp:member-ref>
-          and the above well-known list.
+          and the well-known list of names and value types documented on the
+          <tp:type>Connection_Parameter_Name</tp:type> type.
         </tp:docstring>
       </arg>
       <arg direction="out" type="s" tp:type="DBus_Bus_Name" name="Bus_Name">
@@ -307,7 +327,55 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>To request values for these parameters from the user, a client must
         have prior knowledge of the meaning of the parameter names, so the
-        following well-known names and types should be used where appropriate:</p>
+        well-known names and types defined by the
+        <tp:type>Connection_Parameter_Name</tp:type> type should be used where
+        appropriate.</p>
+
+        <p>Connection manager authors SHOULD avoid introducing parameters
+          whose default values would not be serializable in a
+          <code>.manager</code> file.</p>
+
+        <tp:rationale>
+          <p>The same serialization format is used in Mission Control
+            to store accounts.</p>
+        </tp:rationale>
+
+        <p>Every successful RequestConnection call will cause the emission of a
+        <tp:member-ref>NewConnection</tp:member-ref> signal for the same newly
+        created connection. The
+        requester can use the returned object path and service name
+        independently of the emission of that signal. In that case this signal
+        emission is most useful for, e.g. other processes that are monitoring
+        the creation of new connections.</p>
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The requested protocol is not supported by this manager
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The requested connection already appears to exist
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Unrecognised connection parameters
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <tp:simple-type name="Connection_Parameter_Name" type="s">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Well-known connection parameter names, along with their expected
+          type. Where possible, connection managers should use names and types
+          from this list in the <tp:dbus-ref
+          namespace='ofdT.Protocol'>Parameters</tp:dbus-ref> that may be passed
+          to <tp:member-ref>RequestConnection</tp:member-ref>.</p>
 
         <dl>
           <dt>account (s)</dt>
@@ -354,47 +422,29 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             significant if the stun-server is also supplied.</dd>
 
           <dt>keepalive-interval (u)</dt>
-          <dd>The time in seconds between pings sent to the server to ensure
-            that the connection is still alive, or <tt>0</tt> to disable such
-            pings.</dd>
+          <dd>
+            <p>The time in seconds between pings sent to the server to ensure
+              that the connection is still alive, or <tt>0</tt> to disable such
+              pings.</p>
+
+            <p>This parameter is superseded by the <tp:dbus-ref
+                namespace='ofdT.Connection.Interface.Keepalive.DRAFT'>KeepaliveInterval</tp:dbus-ref>
+              property, which can be updated on an already-established
+              connection as well as being specified when requesting the
+              connection. Clients SHOULD provide that parameter instead, if
+              allowed; new connection managers SHOULD implement it in
+              preference to this one.</p>
+          </dd>
         </dl>
 
-        <p>Connection manager authors SHOULD avoid introducing parameters
-          whose default values would not be serializable in a
-          <code>.manager</code> file.</p>
-
-        <tp:rationale>
-          <p>The same serialization format is used in Mission Control
-            to store accounts.</p>
-        </tp:rationale>
+        <p>The following well-known parameter names correspond to D-Bus
+          properties, and thus their <tp:type>Conn_Mgr_Param_Flags</tp:type>
+          should include DBus_Property. See that flag for more details on this
+          kind of parameter.</p>
 
-        <p>Every successful RequestConnection call will cause the emission of a
-        <tp:member-ref>NewConnection</tp:member-ref> signal for the same newly
-        created connection. The
-        requester can use the returned object path and service name
-        independently of the emission of that signal. In that case this signal
-        emission is most useful for, e.g. other processes that are monitoring
-        the creation of new connections.</p>
+        <tp:list-dbus-property-parameters/>
       </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The requested protocol is not supported by this manager
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The requested connection already appears to exist
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            Unrecognised connection parameters
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
+    </tp:simple-type>
 
     <property name="Interfaces" tp:name-for-bindings="Interfaces"
       type="as" access="read">
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index c9ae78f..123ea8b 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -337,6 +337,53 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         has been discovered and streaming is in progress.
       </tp:docstring>
     </method>
+    <method name="NewActiveTransportPair"
+      tp:name-for-bindings="New_Active_Transport_Pair">
+      <arg direction="in" name="Native_Candidate_ID" type="s"/>
+      <arg direction="in" name="Native_Transport" type="(usuussduss)"
+        tp:type="Media_Stream_Handler_Transport"/>
+      <arg direction="in" name="Remote_Candidate_ID" type="s"/>
+      <arg direction="in" name="Remote_Transport" type="(usuussduss)"
+        tp:type="Media_Stream_Handler_Transport"/>
+      <tp:docstring>
+        <p>Informs the connection manager that a valid transport pair
+          has been discovered and streaming is in progress. Component
+          id MUST be the same for both transports and the pair is
+          only valid for that component.</p>
+
+        <tp:rationale>
+          <p>The connection manager might need to send the details of
+            the active transport pair (e.g. c and o parameters of SDP
+            body need to contain address of selected native RTP transport
+            as stipulated by RFC 5245). However, the candidate ID might
+            not be enough to determine these info if the transport was
+            found after <tp:member-ref>NativeCandidatesPrepared</tp:member-ref>
+            has been called (e.g. peer reflexive ICE candidate). </p>
+        </tp:rationale>
+
+        <p>This method must be called before
+          <tp:member-ref>NewActiveCandidatePair</tp:member-ref>.</p>
+
+        <tp:rationale>
+          <p>This way, connection managers supporting this method can
+            safely ignore subsequent
+            <tp:member-ref>NewActiveCandidatePair</tp:member-ref> call.</p>
+        </tp:rationale>
+
+        <p>Connection managers SHOULD NOT implement this method unless
+          they need to inform the peer about selected transports. As a
+          result, streaming implementations MUST NOT treat errors raised
+          by this method as fatal.</p>
+
+        <tp:rationale>
+          <p>Usually, connection managers only need to do one answer/offer
+            round-trip. However, some protocols give the possibility to
+            to send an updated offer (e.g. ICE defines such mechanism to
+            avoid some race conditions and to properly set the state of
+            gateway devices).</p>
+        </tp:rationale>
+      </tp:docstring>
+    </method>
     <tp:enum name="Media_Stream_Base_Proto" type="u">
       <tp:enumvalue suffix="UDP" value="0">
         <tp:docstring>UDP (User Datagram Protocol)</tp:docstring>
@@ -513,9 +560,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </signal>
     <signal name="StartTelephonyEvent"
       tp:name-for-bindings="Start_Telephony_Event">
-      <arg name="Event" type="y">
+      <arg name="Event" type="y" tp:type="DTMF_Event">
         <tp:docstring>
-          A telephony event code as defined by RFC 4733.
+          A telephony event code.
         </tp:docstring>
       </arg>
       <tp:docstring>
@@ -523,6 +570,44 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         over this stream until StopTelephonyEvent is called.
       </tp:docstring>
     </signal>
+    <signal name="StartNamedTelephonyEvent"
+      tp:name-for-bindings="Start_Named_Telephony_Event">
+      <tp:added version="0.21.2"/>
+      <arg name="Event" type="y" tp:type="DTMF_Event">
+        <tp:docstring>
+          A telephony event code as defined by RFC 4733.
+        </tp:docstring>
+      </arg>
+     <arg name="Codec_ID" type="u">
+        <tp:docstring>
+          The payload type to use when sending events. The value 0xFFFFFFFF
+	  means to send with the already configured event type instead of using
+	  the specified one.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Request that a telephony event (as defined by RFC 4733) is transmitted
+        over this stream until StopTelephonyEvent is called. This differs from
+        StartTelephonyEvent in that you force the event to be transmitted
+	as a RFC 4733 named event, not as sound. You can also force a specific
+	Codec ID.
+      </tp:docstring>
+    </signal>
+    <signal name="StartSoundTelephonyEvent"
+      tp:name-for-bindings="Start_Sound_Telephony_Event">
+      <tp:added version="0.21.2"/>
+      <arg name="Event" type="y" tp:type="DTMF_Event">
+        <tp:docstring>
+          A telephony event code as defined by RFC 4733.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Request that a telephony event (as defined by RFC 4733) is transmitted
+        over this stream until StopTelephonyEvent is called. This differs from
+        StartTelephonyEvent in that you force the event to be transmitted
+	as sound instead of as a named event.
+      </tp:docstring>
+    </signal>
     <signal name="StopTelephonyEvent"
       tp:name-for-bindings="Stop_Telephony_Event">
       <tp:docstring>
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 91c350f..e37fe22 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -45,6 +45,32 @@
           <code>/org/freedesktop/Telepathy/ConnectionManager/salut/local_xmpp</code>,
           respectively.</p>
       </tp:rationale>
+
+      <p>If the ConnectionManager has a <tt>.manager</tt> file, each
+        Protocol's immutable properties must be represented in that file;
+        the representation is described as part of the documentation for
+        each property. For instance, a very simple ConnectionManager with one
+        Protocol might be represented like this:</p>
+
+<pre>
+[ConnectionManager]
+Interfaces=
+
+[Protocol example]
+Interfaces=
+ConnectionInterfaces=org.freedesktop.Telepathy.Connection.Interface.Requests;
+param-account=s required
+param-password=s required secret
+RequestableChannelClasses=text;
+VCardField=x-example
+EnglishName=Example
+Icon=im-example
+
+[text]
+org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
+org.freedesktop.Telepathy.Channel.TargetHandleType u=1
+allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
+</pre>
     </tp:docstring>
 
     <property name="Interfaces" tp:name-for-bindings="Interfaces"
@@ -136,6 +162,12 @@
           of those strings is the name of a group in the <code>.manager</code>
           file which represents a channel class.</p>
 
+        <p>The names of the groups representing channel classes are not
+          significant, and MUST NOT be interpreted. When writing
+          <tt>.manager</tt> files, authors MAY choose mnemonic group names,
+          generate group names mechanically (e.g. with an incrementing
+          integer), or use some combination of these.</p>
+
         <p>Each group representing a channel class has a key
           <code>allowed</code> which is a list of D-Bus property names
           representing allowed parameters. Any other keys that do not contain
@@ -152,17 +184,23 @@
           <code>.manager</code> files.</p>
 
         <p>For instance, this <code>.manager</code> file could represent
-          a simple Text-only connection manager:</p>
+          a connection manager that supports 1-1 Text messages and
+          StreamedMedia audio calls:</p>
 
 <pre>[Protocol jabber]
 param-account=s required
 param-password=s required
-RequestableChannelClasses=text
+RequestableChannelClasses=rcc0;rcc1;
 
-[text]
+[rcc0]
 org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
 org.freedesktop.Telepathy.Channel.TargetHandleType u=1
 allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
+
+[rcc1]
+org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.StreamedMedia
+org.freedesktop.Telepathy.Channel.TargetHandleType u=1
+allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;org.freedesktop.Telepathy.Channel.Type.StreamedMedia.InitialAudio;
 </pre>
       </tp:docstring>
     </property>
@@ -178,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
@@ -187,15 +239,14 @@ 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
+          MUST cache this property in the protocol's section of the
+          <code>.manager</code> file if it is non-empty, using the key
+          <code>VCardField</code>. The corresponding value
+          is a string, following the syntax of the "localestring" type from
+          the Desktop Entry Specification.</p>
       </tp:docstring>
     </property>
 
@@ -223,6 +274,13 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
         <p>If this property's value is empty, clients MAY fall back to using
           the Telepathy <tp:type>Protocol</tp:type> name, possibly with its
           capitalization adjusted.</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>EnglishName</code>. The corresponding value
+          is a string, following the syntax of the "localestring" type from
+          the Desktop Entry Specification.</p>
       </tp:docstring>
     </property>
 
@@ -243,6 +301,13 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <p>If this property's value is empty, clients MAY fall back to
           generating a name based on the <tp:type>Protocol</tp:type> name.</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>Icon</code>. The corresponding value
+          is a string, following the syntax of the "localestring" type from
+          the Desktop Entry Specification.</p>
       </tp:docstring>
     </property>
 
@@ -364,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 0000000..3722c3b
--- /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/Protocol_Interface_Presence.xml b/spec/Protocol_Interface_Presence.xml
index 47a37ea..ddff332 100644
--- a/spec/Protocol_Interface_Presence.xml
+++ b/spec/Protocol_Interface_Presence.xml
@@ -20,9 +20,8 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Presence.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.8">(draft 1)</tp:added>
+  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Presence">
+    <tp:added version="0.21.3">(as stable API)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Protocol"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/all.xml b/spec/all.xml
index 9140a1f..afb48df 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.10</tp:version>
+<tp:version>0.21.4</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,22 +45,28 @@ 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"/>
   <xi:include href="Connection_Interface_Balance.xml"/>
   <xi:include href="Connection_Interface_Capabilities.xml"/>
   <xi:include href="Connection_Interface_Cellular.xml"/>
+  <xi:include href="Connection_Interface_Client_Types.xml"/>
+  <xi:include href="Connection_Interface_Communication_Policy.xml"/>
   <xi:include href="Connection_Interface_Contact_Capabilities.xml"/>
   <xi:include href="Connection_Interface_Contact_Groups.xml"/>
   <xi:include href="Connection_Interface_Contact_Info.xml"/>
   <xi:include href="Connection_Interface_Contact_List.xml"/>
   <xi:include href="Connection_Interface_Contacts.xml"/>
   <xi:include href="Connection_Interface_Forwarding.xml"/>
+  <xi:include href="Connection_Interface_Keepalive.xml"/>
   <xi:include href="Connection_Interface_Location.xml"/>
   <xi:include href="Connection_Interface_Mail_Notification.xml"/>
+  <xi:include href="Connection_Interface_Power_Saving.xml"/>
   <xi:include href="Connection_Interface_Presence.xml"/>
   <xi:include href="Connection_Interface_Renaming.xml"/>
+  <xi:include href="Connection_Interface_Resources.xml"/>
   <xi:include href="Connection_Interface_Requests.xml"/>
   <xi:include href="Connection_Interface_Service_Point.xml"/>
   <xi:include href="Connection_Interface_Simple_Presence.xml"/>
@@ -95,6 +102,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    <xi:include href="Channel_Type_DBus_Tube.xml"/>
    <xi:include href="Channel_Type_File_Transfer.xml"/>
    <xi:include href="Channel_Type_Room_List.xml"/>
+   <xi:include href="Channel_Type_Server_TLS_Connection.xml"/>
    <xi:include href="Channel_Type_Stream_Tube.xml"/>
    <xi:include href="Channel_Type_Streamed_Media.xml"/>
    <xi:include href="Channel_Type_Text.xml"/>
@@ -108,6 +116,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"/>
@@ -121,12 +130,25 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    <xi:include href="Channel_Interface_Mergeable_Conference.xml"/>
    <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"/>
   </tp:section>
  </tp:section>
 
+ <tp:section name="Authentication Objects">
+  <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+    <p>
+      A set of objects to be used for authentication purposes, such
+      as TLS certificates or handshakes for negotiating end-to-end
+      security.
+    </p>
+  </tp:docstring>
+  <xi:include href="Authentication_TLS_Certificate.xml"/>
+ </tp:section>
+
  <tp:section name="Media">
   <xi:include href="Media_Session_Handler.xml"/>
   <xi:include href="Media_Stream_Handler.xml"/>
@@ -160,6 +182,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">
@@ -171,9 +194,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 60a93c9..268087b 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -182,7 +182,8 @@
       represent a self-signed certificate: see the Self Signed error for that.
       <tp:rationale>
         This corresponds to Cert_Untrusted in the
-        <tp:type>Connection_Status_Reason</tp:type> enum, with a clarification
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Untrusted in the
+        <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum, with a clarification
         to avoid ambiguity.
       </tp:rationale>
     </tp:docstring>
@@ -193,7 +194,8 @@
       Raised if the server provided an expired SSL/TLS certificate.
       <tp:rationale>
         This corresponds to Cert_Expired in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Expired in
+        the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
@@ -204,7 +206,8 @@
       valid at some point in the future.
       <tp:rationale>
         This corresponds to Cert_Not_Activated in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        <tp:type>Connection_Status_Reason</tp:type> enum and to
+        Not_Activated in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
@@ -215,18 +218,23 @@
       the expected fingerprint.
       <tp:rationale>
         This corresponds to Cert_Fingerprint_Mismatch in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        <tp:type>Connection_Status_Reason</tp:type> enum and to
+        Fingerprint_Mismatch in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
 
   <tp:error name="Cert.Hostname Mismatch">
-    <tp:docstring>
-      Raised if the server provided an SSL/TLS certificate that did not match
-      its hostname.
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Raised if the server provided an SSL/TLS certificate that did not match
+      its hostname.</p>
+      <p>You MAY be able to get more details about the expected and certified
+      hostnames by looking up the 'expected-hostname' and 'certificate-hostname'
+      keys in the details map that came together with this error.</p>
       <tp:rationale>
         This corresponds to Cert_Hostname_Mismatch in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Hostname_Mismatch
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
@@ -236,19 +244,61 @@
       Raised if the server provided an SSL/TLS certificate that is self-signed
       and untrusted.
       <tp:rationale>
-        This corresponds to Cert_Hostname_Mismatch in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        This corresponds to Cert_Self_Signed in the
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Self_Signed
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Cert.Revoked">
+    <tp:docstring>
+      Raised if the server provided an SSL/TLS certificate that has been
+      revoked.
+      <tp:rationale>
+        This corresponds to Cert_Revoked in the
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Revoked
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Cert.Insecure">
+    <tp:added version="0.19.11"/>
+    <tp:docstring>
+      Raised if the server provided an SSL/TLS certificate that uses an
+      insecure cipher algorithm or is cryptographically weak.
+      <tp:rationale>
+        This corresponds to Cert_Insecure in the
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Insecure
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
 
   <tp:error name="Cert.Invalid">
+    <tp:added version="0.19.11"/>
     <tp:docstring>
       Raised if the server provided an SSL/TLS certificate that is
       unacceptable in some way that does not have a more specific error.
       <tp:rationale>
         This corresponds to Cert_Other_Error in the
-        <tp:type>Connection_Status_Reason</tp:type> enum.
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Unknown
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Cert.Limit Exceeded">
+    <tp:added version="0.19.11"/>
+    <tp:docstring>
+      Raised if the length in bytes of the server certificate, or the depth of the
+      server certificate chain exceeds the limits imposed by the crypto
+      library.
+      <tp:rationale>
+        This corresponds to Cert_Limit_Exceeded in the
+        <tp:type>Connection_Status_Reason</tp:type> enum and to Limit_Exceeded
+        in the <tp:type>TLS_Certificate_Reject_Reason</tp:type> enum.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
@@ -433,6 +483,31 @@
     </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:error name="Rejected">
+    <tp:added version="0.21.2"/>
+    <tp:docstring>
+      Raised when an incoming or outgoing <tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
+      rejected by the the receiver.
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Picked Up Elsewhere">
+    <tp:added version="0.21.3"/>
+    <tp:docstring>
+      Raised when a call was terminated as a result of the local user
+      picking up the call on a different resource.
+    </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 c017ba5..014f8ad 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>
diff --git a/spec/template.xml b/spec/template.xml
index d752d72..7264720 100644
--- a/spec/template.xml
+++ b/spec/template.xml
@@ -22,7 +22,7 @@
 
   <interface name="org.freedesktop.Telepathy.Foo.DRAFT"
     tp:causes-havoc="experimental">
-    <tp:added version="0.19.UNRELEASED">(draft 1)</tp:added>
+    <tp:added version="0.21.UNRELEASED">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Foo.</p>