Update to spec 0.21.8.

47 files changed, 4059 insertions, 1010 deletions

diff --git a/qt4/spec/Account_Interface_Addressing.xml b/qt4/spec/Account_Interface_Addressing.xml
new file mode 100644
index 000000000..4b2846b68
--- /dev/null
+++ b/qt4/spec/Account_Interface_Addressing.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" ?>
+<node name="/Account_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.Account.Interface.Addressing">
+    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+    <tp:added version="0.21.5">(as stable API)</tp:added>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Some accounts can be used for multiple protocols; for instance, SIP
+        and Skype accounts can often be used to contact the PSTN, MSN and
+        Yahoo accounts can contact each other, and XMPP accounts can
+        potentially contact many protocols via a transport.</p>
+      <p>However, if the user does not intend to make use of this functionality,
+        user interfaces can improve clarity by not displaying it: for instance,
+        if a user prefers to call phone numbers via a particular SIP account,
+        when an address book displays a contact with a phone number, it is
+        desirable to display a "call with SIP" button for that account, but
+        avoid displaying similar buttons for any other configured SIP or
+        Skype accounts.</p>
+      <p>The purpose of this interface is to allow this "for use with" information
+        to be recorded and retrieved.</p>
+    </tp:docstring>
+
+    <property name="URISchemes" type="as" access="read"
+              tp:name-for-bindings="URI_Schemes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of fields indicating the type of URI addressing scheme
+          the the account should be used for (eg 'tel') indicating the
+          account is intended for use by applications offering a telephony
+          UI, or 'sip' or 'xmpp' for those protocols</p>
+        <p>Note that these fields signify intent, not ability: It is
+          entirely possible that an account which can be used for a
+          given URI scheme is not wanted for it by the user, and
+          therefore not flagged as such in this field.</p>
+      </tp:docstring>
+    </property>
+
+    <method name="SetURISchemeAssociation"
+            tp:name-for-bindings="Set_URI_Scheme_Association">
+      <tp:docstring>
+        <p>Associate (or disassociate) an account with a particular
+          URI addressing scheme, (such as 'tel' for telephony)</p>
+      </tp:docstring>
+
+      <arg name="URI_Scheme" direction="in" type="s">
+        <tp:docstring>
+          <p>URI scheme to associate/disassociate the account with/from</p>
+        </tp:docstring>
+      </arg>
+
+      <arg name="Association" direction="in" type="b">
+        <tp:docstring>
+          <p>True to associate this account with a given addressing scheme</p>
+          <p>False if the account should not be associated with said scheme</p>
+        </tp:docstring>
+      </arg>
+
+    </method>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Call_Content.xml b/qt4/spec/Call_Content.xml
index 8df078b66..17ed71095 100644
--- a/qt4/spec/Call_Content.xml
+++ b/qt4/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,65 +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>
 
+    <signal name="Removed" tp:name-for-bindings="Removed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <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">
+      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>.
+          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="Name" tp:name-for-bindings="Name" type="s" 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 name of the content.
-          [FIXME: rationale?]</p>
-      </tp:docstring>
-    </property>
+        <p>The name of the content.</p>
 
-    <property name="Type" tp:name-for-bindings="Type"
-        type="u" tp:type="Media_Stream_Type" access="read">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The media type of this 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">
@@ -92,52 +174,57 @@
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Early_Media" value="1">
+      <tp:enumvalue suffix="Initial" 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: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>
@@ -145,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/qt4/spec/Call_Content_Codec_Offer.xml b/qt4/spec/Call_Content_Codec_Offer.xml
index 31ff0b3c9..f88143f69 100644
--- a/qt4/spec/Call_Content_Codec_Offer.xml
+++ b/qt4/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,14 +56,32 @@
       </tp:docstring>
     </method>
 
-    <property name="RemoteContactCodecMap"
-      tp:name-for-bindings="Remote_Contact_Codec_Map"
-      type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read">
+    <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="RemoteContactCodecs"
+      tp:name-for-bindings="Remote_Contact_Codecs"
+      type="a(usuua{ss})" tp:type="Codec[]" access="read"
+      tp:immutable="yes">
+      <tp:docstring>
+        A list of codecs the remote contact supports.
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
+      type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
       <tp:docstring>
-        A map from remote contacts to the lists of codecs they support.
+        The contact handle that this codec offer applies to.
       </tp:docstring>
     </property>
 
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Call_Content_Interface_Media.xml b/qt4/spec/Call_Content_Interface_Media.xml
index 8b9a17c84..274d8b213 100644
--- a/qt4/spec/Call_Content_Interface_Media.xml
+++ b/qt4/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,142 @@
   <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>
+
+      <h4>Codec negotiation</h4>
+
+      <p>When a new <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channel
+        appears, whether it was requested or not, a <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        will either be waiting in the
+        <tp:member-ref>CodecOffer</tp:member-ref> property, or will
+        appear at some point via the
+        <tp:member-ref>NewCodecOffer</tp:member-ref> signal.</p>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        property on the codec offer lists the codecs which are
+        supported by the remote contact, and so will determine the
+        codecs that should be proposed by the local user's streaming
+        implementation. An empty list means all codecs can be proposed.</p>
+
+      <p>For incoming calls on protocols where codecs are proposed when
+        starting the call (for example, <a
+        href="http://xmpp.org/extensions/xep-0166.html">Jingle</a>),
+        the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        will contain information on the codecs that have already been
+        proposed by the remote contact, otherwise the codec map will
+        be the empty list.</p>
+
+      <p>The streaming implementation should look at the remote codec
+        map and the codecs known by the local user and call
+        <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT.Accept</tp:dbus-ref>
+        on the intersection of these two codec lists.</p>
+
+      <p>This means that in practice, outgoing calls will have a codec
+        offer pop up with no information in the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
+        so the local user will call <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
+        with the list of all codecs supported. If this codec offer is
+        accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
+        will fire with the details of the codecs passed into
+        <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>. If
+        the call is incoming, then the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        will contain details of the remote contact's codecs and the
+        local user will call <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
+        with the codecs that both sides understand. After the codec
+        set is accepted, <tp:member-ref>CodecsChanged</tp:member-ref>
+        will fire to signal this change.</p>
+
+      <h4>Protocols without codec negotiation</h4>
+
+      <p>For protocols where the codecs are not negotiable, instead of
+        popping up the initial content's <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        object with an empty <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
+        the CM should set the supported codec values to known codec
+        values in the said object's codec map.</p>
+
+      <h4>Changing codecs mid-call</h4>
+
+      <p>To update the codec list used mid-call, the
+        <tp:member-ref>UpdateCodecs</tp:member-ref> method should be
+        called with details of the new codec list. If this is
+        accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
+        will be emitted with the new codec set.</p>
+
+      <p>If the other side decides to update his or her codec list
+        during a call, a new <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        object will appear through
+        <tp:member-ref>NewCodecOffer</tp:member-ref> which should be
+        acted on as documented above.</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 +167,22 @@
       <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:member name="Remote_Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The contact handle that this codec offer applies to.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Remote_Contact_Codecs" type="a(usuua{ss})"
+          tp:type="Codec[]">
         <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.RemoteContactCodecs</tp:dbus-ref> property
           of the codec offer.
         </tp:docstring>
       </tp:member>
@@ -118,16 +197,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 +215,31 @@
       </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 a <tp:dbus-ref
+            namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+            object exists and is referred to in the
+            <tp:member-ref>CodecOffer</tp:member-ref> property which
+            should be used instead of calling this method, or before
+            the content's initial <tp:dbus-ref
+            namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+            object has appeared.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
     </method>
 
     <property name="ContactCodecMap" tp:name-for-bindings="Contact_Codec_Map"
@@ -156,72 +248,82 @@
         <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>
+          <code>(Contact, Offer, Codecs)</code>.</p>
       </tp:docstring>
-
+      <arg name="Contact" type="u">
+        <tp:docstring>
+          The contact the codec offer belongs to.
+        </tp:docstring>
+      </arg>
       <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">
+      <arg name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
         <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.RemoteContactCodecs</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">RemoteContactCodecs</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>
 
     <property name="CodecOffer" tp:name-for-bindings="Codec_Offer"
-      type="(oa{ua(usuua{ss})})" tp:type="Codec_Offering" access="read">
+      type="(oua(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, its
+            <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContact</tp:dbus-ref> and
+            <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> properties.
             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"
+          >RemoteContact</tp:dbus-ref> and
+          <tp:dbus-ref namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >RemoteContactCodecs</tp:dbus-ref>
+          properties here saves a D-Bus round-trip - it shouldn't be
+          necessary to get these properties 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/qt4/spec/Call_Content_Interface_Mute.xml b/qt4/spec/Call_Content_Interface_Mute.xml
index eea724f59..f926e03cd 100644
--- a/qt4/spec/Call_Content_Interface_Mute.xml
+++ b/qt4/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/qt4/spec/Call_Stream.xml b/qt4/spec/Call_Stream.xml
index 0fbb9c8aa..1d7b28147 100644
--- a/qt4/spec/Call_Stream.xml
+++ b/qt4/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,22 +155,32 @@
           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="Interfaces" tp:name-for-bindings="Interfaces"
-      type="as" tp:type="DBus_Interface[]" access="read">
+      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
@@ -150,21 +190,16 @@
       </tp:docstring>
     </property>
 
-    <property name="Senders" tp:name-for-bindings="Senders"
+    <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
@@ -173,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/qt4/spec/Call_Stream_Endpoint.xml b/qt4/spec/Call_Stream_Endpoint.xml
index fbab2cfa3..4818168dc 100644
--- a/qt4/spec/Call_Stream_Endpoint.xml
+++ b/qt4/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/qt4/spec/Call_Stream_Interface_Media.xml b/qt4/spec/Call_Stream_Interface_Media.xml
index b1b9e1932..9e62c8744 100644
--- a/qt4/spec/Call_Stream_Interface_Media.xml
+++ b/qt4/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,55 @@
   <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.
+      <h4>ICE restarts</h4>
+
+      <p>If the <tp:dbus-ref
+        namespace="ofdT.Call.Stream.Endpoint.DRAFT">RemoteCredentialsSet</tp:dbus-ref>
+        signal is fired during a call once it has been called before
+        whilst setting up the call for initial use, and the
+        credentials have changed, then there has been an ICE
+        restart. In such a case, the CM SHOULD also empty the remote
+        candidate list in the <tp:dbus-ref
+        namespace="ofdT.Call.Stream">Endpoint.DRAFT</tp:dbus-ref>.</p>
+
+      <p>If the CM does an ICE restart, then the
+        <tp:member-ref>PleaseRestartICE</tp:member-ref> signal is
+        emitted and the streaming implementation should then call
+        <tp:member-ref>SetCredentials</tp:member-ref> again.</p>
+
+      <p>For more information on ICE restarts see
+        <a href="http://tools.ietf.org/html/rfc5245#section-9.1.1.1">RFC 5245
+        section 9.1.1.1</a></p>
+    </tp:docstring>
 
-        <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 +103,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,44 +143,41 @@
     <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:enumvalue suffix="Unknown" value="0">
+        <tp:docstring>
+          The stream transport type is unknown or not applicable
+          (for streams that do not have a configurable transport).
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Raw_UDP" value="1">
         <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:enumvalue suffix="ICE" value="2">
         <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:enumvalue suffix="GTalk_P2P" value="3">
         <tp:docstring>
           Google Talk peer-to-peer connectivity establishment, as implemented
           by libjingle 0.3.
@@ -165,16 +185,6 @@
           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:docstring>
           The transport used by Windows Live Messenger 2009 or later, which
@@ -183,79 +193,106 @@
           interface.]
         </tp:docstring>
       </tp:enumvalue>
+      <tp:enumvalue suffix="SHM" value="5">
+        <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:enumvalue suffix="Multicast" value="6">
+        <tp:added version="0.21.5"/>
+        <tp:docstring>
+          Multicast transport.
+        </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 +371,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 +384,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,17 +425,23 @@
     <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>
       </tp:docstring>
     </property>
+
+    <signal name="PleaseRestartICE"
+      tp:name-for-bindings="Please_Restart_ICE">
+      <tp:docstring>
+        Emitted when the CM does an ICE restart to notify the
+        streaming implementation that it should call
+        <tp:member-ref>SetCredentials</tp:member-ref> again.
+      </tp:docstring>
+    </signal>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Channel.xml b/qt4/spec/Channel.xml
index b1772d7d4..11d3e509c 100644
--- a/qt4/spec/Channel.xml
+++ b/qt4/spec/Channel.xml
@@ -87,10 +87,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           property.</p>
 
         <p>This is fixed for the lifetime of the channel, so channels which
-          could potentially be used to communicate with multiple contacts
-          (such as streamed media calls defined by their members, or ad-hoc
-          chatrooms like MSN switchboards) must have TargetHandleType set
-          to Handle_Type_None and TargetHandle set to 0.</p>
+          could potentially be used to communicate with multiple contacts,
+          and do not have an identity of their own (such as a Handle_Type_Room
+          handle), must have TargetHandleType set to Handle_Type_None and
+          TargetHandle set to 0.</p>
 
         <p>Unlike in the telepathy-spec 0.16 API, there is no particular
           uniqueness guarantee - there can be many channels with the same
diff --git a/qt4/spec/Channel_Dispatcher.xml b/qt4/spec/Channel_Dispatcher.xml
index 474c809f2..2dd000b40 100644
--- a/qt4/spec/Channel_Dispatcher.xml
+++ b/qt4/spec/Channel_Dispatcher.xml
@@ -101,6 +101,165 @@
 
     <method name="CreateChannel" tp:name-for-bindings="Create_Channel">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Equivalent to calling
+          <tp:member-ref>CreateChannelWithHints</tp:member-ref> with an empty
+          <var>Hints</var> parameter.</p>
+      </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.</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="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.</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>
+        <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="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="EnsureChannel" tp:name-for-bindings="Ensure_Channel">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Equivalent to calling
+          <tp:member-ref>EnsureChannelWithHints</tp:member-ref> with an empty
+          <var>Hints</var> parameter.</p>
+      </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.</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="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>EnsureChannelWithHints</tp:member-ref>.</p>
+        </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="CreateChannelWithHints"
+            tp:name-for-bindings="Create_Channel_With_Hints">
+      <tp:added version="0.21.5">
+        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
@@ -235,6 +394,19 @@
         </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">Hints</tp:dbus-ref>
+            property.</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
@@ -256,7 +428,15 @@
 
     </method>
 
-    <method name="EnsureChannel" tp:name-for-bindings="Ensure_Channel">
+    <method name="EnsureChannelWithHints"
+            tp:name-for-bindings="Ensure_Channel_With_Hints">
+      <tp:added version="0.21.5">
+        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
@@ -275,7 +455,7 @@
 
         <tp:rationale>
           <p>The rationale is as for <tp:dbus-ref
-              namespace='org.freedesktop.Telepathy.ChannelDispatcher'>CreateChannel</tp:dbus-ref>.</p>
+              namespace='org.freedesktop.Telepathy.ChannelDispatcher'>CreateChannelWithHints</tp:dbus-ref>.</p>
         </tp:rationale>
       </tp:docstring>
 
@@ -311,7 +491,8 @@
             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>CreateChannel</tp:member-ref>.</p>
+            parameter to
+            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -324,8 +505,8 @@
             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>CreateChannel</tp:member-ref>, except as noted
-            here.</p>
+            <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
@@ -359,6 +540,14 @@
         </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">Hints</tp:dbus-ref>
+          property.</tp:docstring>
+      </arg>
+
       <arg direction="out" name="Request" type="o">
         <tp:docstring>
           A
@@ -380,6 +569,27 @@
 
     </method>
 
+    <property name="SupportsRequestHints"
+              tp:name-for-bindings="Supports_Request_Hints"
+              type="b" access="read">
+      <tp:added version="0.21.5"/>
+      <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, and also new enough to emit <tp:dbus-ref
+          namespace="ofdT.ChannelRequest">SucceededWithChannel</tp:dbus-ref>
+        before the older <tp:dbus-ref
+          namespace="ofdT.ChannelRequest">Succeeded</tp:dbus-ref> signal.
+        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/qt4/spec/Channel_Dispatcher_Interface_Operation_List.xml b/qt4/spec/Channel_Dispatcher_Interface_Operation_List.xml
index d61123f9c..be06f5caa 100644
--- a/qt4/spec/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/qt4/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/qt4/spec/Channel_Interface_Conference.xml b/qt4/spec/Channel_Interface_Conference.xml
index afb99c5ca..abda59eef 100644
--- a/qt4/spec/Channel_Interface_Conference.xml
+++ b/qt4/spec/Channel_Interface_Conference.xml
@@ -355,7 +355,7 @@
     </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>
 
@@ -413,14 +413,13 @@
             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>
@@ -460,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>
 
@@ -496,7 +493,7 @@
 
     <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>
@@ -512,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
@@ -539,8 +534,6 @@
         <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>
 
diff --git a/qt4/spec/Channel_Interface_DTMF.xml b/qt4/spec/Channel_Interface_DTMF.xml
index c74dd5136..d74ea6fa7 100644
--- a/qt4/spec/Channel_Interface_DTMF.xml
+++ b/qt4/spec/Channel_Interface_DTMF.xml
@@ -19,7 +19,10 @@ 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
@@ -126,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
@@ -191,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/qt4/spec/Channel_Interface_Hold.xml b/qt4/spec/Channel_Interface_Hold.xml
index 1e3a832d9..ef5a08f19 100644
--- a/qt4/spec/Channel_Interface_Hold.xml
+++ b/qt4/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/qt4/spec/Channel_Interface_Mergeable_Conference.xml b/qt4/spec/Channel_Interface_Mergeable_Conference.xml
index 03e89683c..cd606c1b7 100644
--- a/qt4/spec/Channel_Interface_Mergeable_Conference.xml
+++ b/qt4/spec/Channel_Interface_Mergeable_Conference.xml
@@ -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/qt4/spec/Channel_Interface_Messages.xml b/qt4/spec/Channel_Interface_Messages.xml
index d4fde0d2b..62e83846a 100644
--- a/qt4/spec/Channel_Interface_Messages.xml
+++ b/qt4/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 "*/*"
@@ -103,6 +104,8 @@ USA.</p>
           This list MUST NOT be empty, since all Messages implementations
           MUST accept messages containing a single "text/plain" part.</p>
 
+        <p>Items in this list MUST be normalized to lower-case.</p>
+
         <p>Some examples of how this property interacts with the
           <tp:member-ref>MessagePartSupportFlags</tp:member-ref>:</p>
 
@@ -141,9 +144,24 @@ USA.</p>
       </tp:docstring>
     </property>
 
+    <property name="MessageTypes" type="au"
+      tp:type="Channel_Text_Message_Type[]" access="read"
+      tp:name-for-bindings="Message_Types"
+      tp:immutable="yes">
+      <tp:added version="0.21.5">
+        This supersedes <tp:dbus-ref namespace="ofdT.Channel.Type.Text"
+          >GetMessageTypes</tp:dbus-ref>; fall back to that method for
+        compatibility with older connection managers.
+      </tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of message types which may be sent on this channel.</p>
+      </tp:docstring>
+    </property>
+
     <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.
@@ -287,6 +305,17 @@ USA.</p>
             image.</p>
         </tp:rationale>
 
+        <p>Connection managers, clients and extensions to this specification
+          SHOULD NOT include <tp:type>Handle</tp:type>s as values in a
+          Message_Part, except for <code>message-sender</code> in the
+          header.</p>
+
+        <tp:rationale>
+          <p>Reference-counting handles in clients becomes problematic if
+            the channel proxy cannot know whether particular map values
+            are handles or not.</p>
+        </tp:rationale>
+
         <h4>Example messages</h4>
 
         <p>A rich-text message, with an embedded image, might be represented
@@ -489,6 +518,12 @@ USA.</p>
 
     <tp:simple-type type="s" name="Message_Header_Key">
       <tp:added version="0.19.8"/>
+      <tp:changed version="0.21.5">
+        Removed <tt>protocol-token</tt>—which had never been implemented—and
+        respecified <tt>message-token</tt> not to have unimplementable
+        uniqueness guarantees.
+      </tp:changed>
+
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Well-known keys for the first <tp:type>Message_Part</tp:type> of a
           message, which contains metadata about the message as a whole, along
@@ -497,39 +532,37 @@ USA.</p>
           one or the other.</p>
 
           <dl>
-            <dt>message-token (s)</dt>
-            <dd>
-              <p>An opaque, globally-unique identifier for the entire message.
-                This MAY be treated as if it were a MIME Message-ID, e.g. for
-                the mid: and cid: URI schemes. If omitted, there is no suitable
-                token; the protocol-token key SHOULD be provided if the protocol
-                identifies messages in some less unique way.</p>
-            </dd>
-
-            <dt>protocol-token (s - <tp:type>Protocol_Message_Token</tp:type>)</dt>
+            <dt>message-token (s -
+              <tp:type>Protocol_Message_Token</tp:type>)
+            </dt>
             <dd>
-              <p>An opaque token for the entire message, with whatever uniqueness
-                guarantee is provided by the underlying protocol. As described
-                for the Protocol_Message_Token type, this token is <em>not</em>
-                guaranteed to be unique between contacts, or even within the
-                scope of a Channel.</p>
+              <p>An opaque identifier for the message, as used by the
+                underlying protocol. For outgoing messages, this SHOULD be
+                globally unique; for incoming messages, this is <em>not</em>
+                guaranteed to uniquely identify a message, <em>even within the
+                scope of a single channel or contact</em>; the only guarantee
+                made is that two messages with different <tt>message-token</tt>
+                headers are different messages.</p>
+
+              <p>Clients wishing to determine whether a new message with the
+                <tt>scrollback</tt> header matches a previously-logged message
+                with the same <tt>message-token</tt> SHOULD compare the
+                message's sender, contents, <tt>message-sent</tt> or
+                <tt>message-received</tt> timestamp, etc. Note that, in XMPP,
+                the server only supplies a timestamp for scrollback messages,
+                not for messages received while you are in a room; thus,
+                non-scrollback messages will lack a <tt>message-sent</tt>
+                timestamp.</p>
 
               <tp:rationale>
-                <p>In practice, in most protocols there is no token with the
-                  uniqueness guarantees demanded for message-token; the
-                  definition of message-token was inappropriate, but must now
-                  be preserved for the benefit of clients that rely on it, at
-                  least until Telepathy breaks backwards compatibility.</p>
-              </tp:rationale>
-
-              <p>The message-token and protocol-token SHOULD NOT both be present;
-                clients requiring an identifier with the semantics of the
-                protocol-token SHOULD look for the message-token first, falling
-                back to the protocol-token.</p>
-
-              <tp:rationale>
-                <p>This is for compatibility with CMs older than the
-                  protocol-token key.</p>
+                <p>In practice, most protocols do not provide globally-unique
+                  identifiers for messages. Connection managers, being
+                  stateless, do not have the necessary information — namely, IM
+                  logs — to generate reliable unique tokens for messages.</p>
+
+                <p>For instance, some XMPP clients (including Gabble) stamp
+                  messages they send with unique identifiers, but others number
+                  outgoing messages in a conversation from 1 upwards.</p>
               </tp:rationale>
             </dd>
 
@@ -547,6 +580,13 @@ USA.</p>
             <dd>The contact who sent the message. If 0 or omitted, the contact
               who sent the message could not be determined.</dd>
 
+            <dt>message-sender-id (s)</dt>
+            <dd>The identifier of the contact who sent the message,
+              i.e. the result of calling <tp:dbus-ref
+                namespace="ofdT.Connection">InspectHandles</tp:dbus-ref>
+              on <code>message-sender</code>. If omitted, clients MUST
+              fall back to looking at <code>message-sender</code>.</dd>
+
             <dt>sender-nickname (s)</dt>
             <dd>The nickname chosen by the sender of the message, which can be
               different for each message in a conversation.</dd>
@@ -599,7 +639,8 @@ USA.</p>
               does not make sense on outgoing messages, and SHOULD NOT
               appear there.</dd>
           </dl>
-          </tp:docstring>
+
+      </tp:docstring>
     </tp:simple-type>
 
     <tp:simple-type type="s" name="Message_Body_Key">
@@ -650,6 +691,12 @@ USA.</p>
 
               <p>Clients MUST ignore parts without a 'content-type' key, which
                 are reserved for future expansion.</p>
+
+              <p>When sending messages, clients SHOULD normalize the
+                content-type to lower case, but connection managers SHOULD NOT
+                rely on this. When signalling sent or received messages,
+                connection managers MUST normalize the content-type to lower
+                case.</p>
             </dd>
 
             <dt>lang (s)</dt>
@@ -701,16 +748,19 @@ USA.</p>
             <dt>needs-retrieval (b)</dt>
             <dd>If false or omitted, the connection
               manager already holds this part in memory. If present and true,
-              this part will be retrieved on demand (like MIME's
-              message/external-body), so clients should expect retrieval to
-              take time; if this specification is later extended to provide a
-              streaming version of GetPendingMessageContent, clients should
-              use it for parts with this flag.</dd>
+              this part must be retrieved on demand (like MIME's
+              <tt>message/external-body</tt>) by a mechanism to be defined later.
+
+              <tp:rationale>The mechanism was meant to be
+                <tp:member-ref>GetPendingMessageContent</tp:member-ref>, but
+                that didn't work out. It's worth leaving the header in in
+                preparation for a future mechanism.
+              </tp:rationale>
+            </dd>
 
             <dt>truncated (b)</dt>
-            <dd>The content available via the 'content' key or
-              GetPendingMessageContent has been truncated by the server
-              or connection manager (equivalent to
+            <dd>The content available via the 'content' key has been truncated
+              by the server or connection manager (equivalent to
               Channel_Text_Message_Flag_Truncated in the Text interface).
             </dd>
 
@@ -824,20 +874,6 @@ USA.</p>
                 the sender. This is sometimes the only way to match it
                 against the sent message, so we include it here.
               </tp:rationale>
-
-              <p>Unlike in the Messages interface, content not visible
-                in the value for this key cannot be retrieved by another
-                means, so the connection manager SHOULD be more
-                aggressive about including (possibly truncated) message
-                content in the 'content' key.</p>
-
-              <tp:rationale>
-                The Messages interface needs to allow all content to be
-                retrieved, but in this interface, the content we provide is
-                merely a hint; so some is better than none, and it doesn't
-                seem worth providing an API as complex as Messages'
-                GetPendingMessageContent for the echoed message.
-              </tp:rationale>
             </dd>
 
           </dl>
@@ -846,6 +882,11 @@ USA.</p>
 
     <tp:simple-type type="u" name="Message_Part_Index"
       array-name="Message_Part_Index_List">
+      <tp:deprecated version="0.21.5">
+        This type is only used by
+        <tp:member-ref>GetPendingMessageContent</tp:member-ref>, which is
+        unimplemented and deprecated.
+      </tp:deprecated>
       <tp:added version="0.17.17"/>
       <tp:docstring>
         The index of a message part within a message.
@@ -854,6 +895,11 @@ USA.</p>
 
     <tp:mapping name="Message_Part_Content_Map">
       <tp:added version="0.17.17"/>
+      <tp:deprecated version="0.21.5">
+        This structure is only used by
+        <tp:member-ref>GetPendingMessageContent</tp:member-ref>, which is
+        unimplemented and deprecated.
+      </tp:deprecated>
       <tp:docstring>
         A mapping from message part indexes to their content, as returned by
         <tp:member-ref>GetPendingMessageContent</tp:member-ref>.
@@ -886,7 +932,7 @@ USA.</p>
           is no particular identification for a message.</p>
 
         <p>CM implementations SHOULD use an identifier expected to be unique,
-          such as a UUID, if possible.</p>
+          such as a UUID, for outgoing messages (if possible).</p>
 
         <p>Some protocols can only track a limited number of messages
           in a small message-ID space (SMS messages are identified by a single
@@ -944,12 +990,27 @@ USA.</p>
         <p>If this method fails, message submission to the server has failed
           and no signal on this interface (or the Text interface) is
           emitted.</p>
+
+        <p>If this method succeeds, message submission to the server has
+          succeeded, but the message has not necessarily reached its intended
+          recipient. If a delivery failure is detected later, this is
+          signalled by receiving a message whose <code>message-type</code>
+          header maps to
+          <tp:type>Channel_Text_Message_Type</tp:type>_Delivery_Report.
+          Similarly, if delivery is detected to have been successful
+          (which is not possible in all protocols), a successful delivery
+          report will be signalled.</p>
       </tp:docstring>
 
       <arg direction="in" type="aa{sv}" tp:type="Message_Part[]"
         name="Message">
         <tp:docstring>
-          The message content, including any attachments or alternatives
+          The message content, including any attachments or alternatives.
+          This MUST NOT include the following headers, or any others that
+          do not make sense for a client to specify:
+          <code>message-sender</code>, <code>message-sender-id</code>,
+          <code>message-sent</code>, <code>message-received</code>,
+          <code>pending-message-id</code>.
         </tp:docstring>
       </arg>
       <arg direction="in" name="Flags" type="u"
@@ -1059,6 +1120,14 @@ USA.</p>
             part to generate a <tt>text/plain</tt> alternative which is also
             included in this signal argument.</p>
 
+          <p>The connection manager SHOULD include the
+            <code>message-sender</code>, <code>message-sender-id</code> and
+            <code>message-sent</code> headers in the representation of the
+            message that is signalled here. If the channel has
+            channel-specific handles, the <code>message-sender</code> and
+            <code>message-sender-id</code> SHOULD reflect the sender that
+            other contacts will see.</p>
+
           <p>If the connection manager can predict that the message will be
             altered during transmission, this argument SHOULD reflect what
             other contacts will receive, rather than being a copy of the
@@ -1087,15 +1156,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>
 
@@ -1122,6 +1195,14 @@ USA.</p>
 
     <method name="GetPendingMessageContent"
       tp:name-for-bindings="Get_Pending_Message_Content">
+      <tp:deprecated version='0.21.5'
+                     xmlns="http://www.w3.org/1999/xhtml">
+        This method has never been implemented, and in any case would have been
+        impossible to use correctly when multiple clients (such as a logger and
+        the handler) are interested in a text channel. See <a
+          href='https://bugs.freedesktop.org/show_bug.cgi?id=26417'>freedesktop.org
+        bug #26417</a> for more details.
+      </tp:deprecated>
       <tp:docstring>
         Retrieve the content of one or more parts of a pending message.
         Note that this function may take a considerable amount of time
@@ -1340,7 +1421,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/qt4/spec/Channel_Interface_SASL_Authentication.xml b/qt4/spec/Channel_Interface_SASL_Authentication.xml
new file mode 100644
index 000000000..38568b1dd
--- /dev/null
+++ b/qt4/spec/Channel_Interface_SASL_Authentication.xml
@@ -0,0 +1,704 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_SASL_Authentication"
+      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.SASLAuthentication">
+    <tp:added version="0.21.5">(as stable API)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>A channel interface for SASL authentication,
+        as defined by
+        <a href="http://tools.ietf.org/html/rfc4422">RFC 4422</a>.
+        When this interface appears on a <tp:dbus-ref
+          namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+        channel, it represents authentication with the server. In future,
+        it could also be used to authenticate with secondary services,
+        or even to authenticate end-to-end connections with contacts. As a result,
+        this interface does not REQUIRE <tp:dbus-ref namespace="ofdT.Channel.Type"
+        >ServerAuthentication</tp:dbus-ref> to allow for a potential future
+        Channel.Type.PeerAuthentication interface.</p>
+
+      <p>In any protocol that requires a password, the connection manager can
+        use this channel to let a user interface carry out a simple SASL-like
+        handshake with it, as a way to get the user's credentials
+        interactively. This can be used to connect to protocols that may
+        require a password, without requiring that the password is saved in
+        the <tp:dbus-ref
+          namespace="ofdT">Account.Parameters</tp:dbus-ref>.</p>
+
+      <p>In some protocols, such as XMPP, authentication with the server
+        is also carried out using SASL. In these protocols, a channel with this
+        interface can provide a simple 1:1 mapping of the SASL negotiations
+        taking place in the protocol, allowing more advanced clients to
+        perform authentication via SASL mechanisms not known to the
+        connection manager.</p>
+
+      <tp:rationale>
+        <p>By providing SASL directly when the protocol supports it, we can
+          use mechanisms like Kerberos or Google's <code>X-GOOGLE-TOKEN</code>
+          without specific support in the connection manager.</p>
+      </tp:rationale>
+
+      <p>For channels managed by a
+        <tp:dbus-ref namespace="ofdT">ChannelDispatcher</tp:dbus-ref>,
+        only the channel's <tp:dbus-ref
+          namespace="ofdT.Client">Handler</tp:dbus-ref> may call the
+        methods on this interface. Other clients MAY observe the
+        authentication process by watching its signals and properties.</p>
+
+      <tp:rationale>
+        <p>There can only be one Handler, which is a good fit for SASL's
+          1-1 conversation between a client and a server.</p>
+      </tp:rationale>
+    </tp:docstring>
+
+    <tp:simple-type name="SASL_Mechanism" type="s"
+      array-name="SASL_Mechanism_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A SASL mechanism, as defined by
+          <a href="http://tools.ietf.org/html/rfc4422">RFC 4422</a>
+          and registered in
+          <a href="http://www.iana.org/assignments/sasl-mechanisms">the
+            IANA registry of SASL mechanisms</a>, or an unregistered
+          SASL mechanism such as <code>X-GOOGLE-TOKEN</code> used in the
+          same contexts.</p>
+
+        <p>As a special case, pseudo-mechanisms starting with
+          <code>X-TELEPATHY-</code> are defined by this specification.
+          Use of these pseudo-mechanisms indicates that the user's credentials
+          are to be passed to the connection manager, which will then use
+          them for authentication with the service, either by implementing
+          the client side of some SASL mechanisms itself or by using a
+          non-SASL protocol. The only such pseudo-mechanism currently
+          defined is <code>X-TELEPATHY-PASSWORD</code>.</p>
+
+        <p>The <code>X-TELEPATHY-PASSWORD</code> mechanism is extremely
+          simple:</p>
+
+        <ul>
+          <li>The client MUST call
+            <tp:member-ref>StartMechanismWithData</tp:member-ref>, with
+            Initial_Data set to the password encoded in UTF-8.
+            For simplicity, calling <tp:member-ref>StartMechanism</tp:member-ref>
+            followed by calling <tp:member-ref>Respond</tp:member-ref> is not
+            allowed in this mechanism.</li>
+
+          <li>The connection manager uses the password, together with
+            authentication details from the Connection parameters, to
+            authenticate itself to the server.</li>
+
+          <li>When the connection manager finishes its attempt to authenticate
+            to the server, the channel's state changes to
+            either SASL_Status_Server_Succeeded or
+            SASL_Status_Server_Failed as appropriate.</li>
+        </ul>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <property name="AvailableMechanisms"
+      tp:name-for-bindings="Available_Mechanisms"
+      type="as" tp:type="SASL_Mechanism[]"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The SASL mechanisms as offered by the server, plus any
+          pseudo-SASL mechanisms supported by the connection manager for
+          credentials transfer. For instance, in a protocol that
+          natively uses SASL (like XMPP), this might be
+          <code>[ "X-TELEPATHY-PASSWORD", "PLAIN", "DIGEST-MD5",
+            "SCRAM-SHA-1" ]</code>.</p>
+
+        <p>To make it possible to implement a very simple password-querying
+          user interface without knowledge of any particular SASL mechanism,
+          implementations of this interface MUST implement the
+          pseudo-mechanism <code>X-TELEPATHY-PASSWORD</code>, unless none
+          of the available mechanisms use a password at all.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="HasInitialData" tp:name-for-bindings="Has_Initial_Data"
+      type="b" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, <tp:member-ref>StartMechanismWithData</tp:member-ref>
+          can be expected to work for SASL mechanisms not starting with
+          <code>X-TELEPATHY-</code> (this is the case in most, but not all,
+          protocols). If false, <tp:member-ref>StartMechanism</tp:member-ref>
+          must be used instead.</p>
+
+        <p>This property does not affect the <code>X-TELEPATHY-</code>
+          pseudo-mechanisms such as <code>X-TELEPATHY-PASSWORD</code>,
+          which can use
+          <tp:member-ref>StartMechanismWithData</tp:member-ref> regardless
+          of the value of this property.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CanTryAgain" tp:name-for-bindings="Can_Try_Again"
+      type="b" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, <tp:member-ref>StartMechanism</tp:member-ref> and (if
+          supported) <tp:member-ref>StartMechanismWithData</tp:member-ref>
+          can be expected to work when in one of the Failed states. If
+          false, the only thing you can do after failure is to close the
+          channel.</p>
+
+        <tp:rationale>
+          <p>Retrying isn't required to work, although some protocols and
+            implementations allow it.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property type="u" tp:type="SASL_Status" access="read"
+      name="SASLStatus" tp:name-for-bindings="SASL_Status">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The current status of this channel.
+        Change notification is via the
+        <tp:member-ref>SASLStatusChanged</tp:member-ref> signal.
+      </tp:docstring>
+    </property>
+
+    <property type="s" tp:type="DBus_Error_Name" access="read"
+      name="SASLError" tp:name-for-bindings="SASL_Error">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The reason for the <tp:member-ref>SASLStatus</tp:member-ref>, or
+          an empty string if the state is neither
+          Server_Failed nor Client_Failed.</p>
+
+        <p>In particular, an ordinary authentication failure (as would
+          be produced for an incorrect password) SHOULD be represented by
+          <tp:error-ref>AuthenticationFailed</tp:error-ref>,
+          cancellation by the user's request SHOULD be represented
+          by <tp:error-ref>Cancelled</tp:error-ref>, and
+          cancellation by a local process due to inconsistent or invalid
+          challenges from the server SHOULD be represented by
+          <tp:error-ref>ServiceConfused</tp:error-ref>.</p>
+
+        <p>If this interface appears on a <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          channel, and connection to the server fails with an authentication
+          failure, this error code SHOULD be copied into the
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="SASLErrorDetails"
+      tp:name-for-bindings="SASL_Error_Details"
+      access="read" type="a{sv}" tp:type="String_Variant_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>SASLError</tp:member-ref> is non-empty,
+          any additional information about the last
+          disconnection; otherwise, the empty map. The keys and values are
+          the same as for the second argument of
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>.</p>
+
+        <p>If this interface appears on a <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          channel, and connection to the server fails with an authentication
+          failure, these details SHOULD be copied into the
+          <tp:dbus-ref
+            namespace="ofdT">Connection.ConnectionError</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="AuthorizationIdentity"
+      tp:name-for-bindings="Authorization_Identity"
+      type="s" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The identity for which authorization is being attempted,
+          typically the 'account' from the <tp:dbus-ref
+            namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>
+          parameters, normalized and formatted according to the
+          conventions used for SASL in this protocol.</p>
+
+        <tp:rationale>
+          <p>The normalization used for SASL might not be the same
+            normalization used elsewhere: for instance, in a protocol
+            with email-like identifiers such as XMPP or SIP, the user
+            "juliet@example.com" might have to authenticate to the
+            example.com server via SASL PLAIN as "juliet".</p>
+        </tp:rationale>
+
+        <p>This is usually achieved by using the authorization identity for
+          authentication, but an advanced Handler could offer the option
+          to authenticate under a different identity.</p>
+
+        <p>The terminology used here is that the authorization identity
+          is who you want to act as, and the authentication identity is
+          used to prove that you may do so. For instance, if Juliet is
+          authorized to access a role account, "sysadmin@example.com",
+          and act on its behalf, it might be possible to authenticate
+          as "juliet@example.com" with her own password, but request to
+          be authorized as "sysadmin@example.com" instead of her own
+          account. See
+          <a href="http://tools.ietf.org/html/rfc4422#section-3.4.1">RFC
+            4422 §3.4.1</a> for more details.</p>
+
+        <tp:rationale>
+          <p>In SASL the authorization identity is normally guessed from
+            the authentication identity, but the information available
+            to the connection manager is the identity for which
+            authorization is required, such as the desired JID in XMPP,
+            so that's what we signal to UIs; it's up to the UI to
+            choose whether to authenticate as the authorization identity
+            or some other identity.</p>
+
+          <p>As a concrete example, the "sysadmin" XMPP account mentioned
+            above would have <code>{ 'account': 'sysadmin@example.com' }</code>
+            in its Parameters, and this property would also be
+            'sysadmin@example.com'. A simple Handler would
+            merely prompt for sysadmin@example.com's password,
+            and use that JID as both the authorization and authentication
+            identity, which might result in SASL PLAIN authentication with the
+            initial response
+            '\000sysadmin@example.com\000root'.</p>
+
+          <p>A more advanced Handler might also ask for an authentication
+            identity, defaulting to 'sysadmin@example.com'; if Juliet
+            provided authentication identity 'juliet@example.com' and
+            password 'romeo', the Handler might perform SASL PLAIN
+            authentication using the initial response
+            'sysadmin@example.com\000juliet@example.com\000romeo'.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="DefaultUsername"
+      tp:name-for-bindings="Default_Username"
+      type="s" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The default username for use with SASL mechanisms that deal
+          with a "simple username" (as defined in <a
+          href="http://tools.ietf.org/html/rfc4422">RFC 4422</a>). If
+          such a SASL mechanism is in use, clients SHOULD default to
+          using the DefaultUsername; also, if the client uses
+          the DefaultUsername, it SHOULD assume that the authorization
+          identity <tp:member-ref>AuthorizationIdentity</tp:member-ref>
+          will be derived from it by the server.</p>
+
+        <tp:rationale>
+          <p>In XMPP, <a href="http://trac.tools.ietf.org/wg/xmpp/trac/ticket/49">
+            servers typically expect</a> "user@example.com" to
+            authenticate with username "user"; this was a SHOULD in <a
+            href="http://tools.ietf.org/html/rfc3920">RFC 3920</a>.</p>
+
+          <p><a
+            href="http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-19">3920bis</a>
+            weakens that SHOULD to "in the absence of local information
+            provided by the server, an XMPP client SHOULD assume that
+            the authentication identity for such a SASL mechanism is the
+            combination of a user name and password, where the simple
+            user name is the localpart of the user's JID".</p>
+        </tp:rationale>
+
+        <p>For example, in the simple case, if the user connects with
+        <tp:dbus-ref
+        namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>({
+        account: "<tt>user@example.com</tt>" }) and use PLAIN with
+        password "password", he or she should authenticate like so:
+        "<tt>\0user\0password</tt>" and the channel will look like
+        this:</p>
+
+<blockquote><pre>{ "...<tp:member-ref>DefaultUsername</tp:member-ref>": "user",
+  "...<tp:member-ref>AuthorizationIdentity</tp:member-ref>": "user@example.com }
+</pre></blockquote>
+
+        <p>In the complex case, if the same user is using his or her
+          sysadmin powers to log in as the "announcements" role address,
+          he or she would connect with <tp:dbus-ref
+            namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>({
+          account: "<tt>announcements@example.com</tt>" }) and the SASL
+          channel would look like this:</p>
+
+<blockquote><pre>{ "...<tp:member-ref>DefaultUsername</tp:member-ref>": "announcements",
+  "...<tp:member-ref>AuthorizationIdentity</tp:member-ref>": "announcements@example.com }
+</pre></blockquote>
+
+        <p>A sufficiently elaborate UI could give the opportunity
+          to override the username from "announcements" to "user".
+          The user's simple username is still "user", and the password is
+          still "password", but this time he or she is trying to authorize
+          to act as <tt>announcements@example.com</tt>, so the UI would
+          have to perform SASL PLAIN with this string:
+          "<tt>announcements@example.com\0user\0password</tt>", where
+          "announcements@example.com" is the
+          <tp:member-ref>AuthorizationIdentity</tp:member-ref>.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="DefaultRealm" tp:name-for-bindings="Default_Realm"
+      type="s" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The default realm (as defined in
+          <a href="http://tools.ietf.org/html/rfc2831#section-2.1.1">RFC
+            2831</a>) to use for authentication, if the server does not
+          supply one.</p>
+
+        <tp:rationale>
+          <p>The server is not required to provide a realm; if it doesn't,
+            the client is expected to ask the user or provide a sensible
+            default, typically the requested DNS name of the server.
+            In some implementations of <code>DIGEST-MD5</code>, the
+            server does not specify a realm, but expects that the client
+            will choose a particular default, and authentication will
+            fail if the client's default is different. Connection
+            managers for protocols where this occurs are more easily able
+            to work around these implementations than a generic client
+            would be.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <method name="StartMechanism" tp:name-for-bindings="Start_Mechanism">
+      <arg direction="in" name="Mechanism" type="s" tp:type="SASL_Mechanism">
+        <tp:docstring>
+          The chosen mechanism.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start an authentication try using <var>Mechanism</var>, without
+          sending initial data (an "initial response" as defined in RFC
+          4422).</p>
+
+        <tp:rationale>
+          <p>This method is appropriate for mechanisms where the client
+            cannot send anything until it receives a challenge from the
+            server, such as
+            <code><a href="http://tools.ietf.org/html/rfc2831">DIGEST-MD5</a></code>
+            in "initial authentication" mode.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The channel is not in a state where starting authentication makes
+            sense (i.e. SASL_Status_Not_Started, or (if
+            <tp:member-ref>CanTryAgain</tp:member-ref> is true)
+            SASL_Status_Server_Failed or
+            SASL_Status_Client_Failed). You should call
+            <tp:member-ref>AbortSASL</tp:member-ref> and wait for
+            SASL_Status_Client_Failed before starting another attempt.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The server or connection manager doesn't implement the given
+            SASL mechanism. Choose a SASL mechanism from
+            <tp:member-ref>AvailableMechanisms</tp:member-ref>, or abort
+            authentication if none of them are suitable.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="StartMechanismWithData"
+      tp:name-for-bindings="Start_Mechanism_With_Data">
+      <arg direction="in" name="Mechanism" type="s" tp:type="SASL_Mechanism">
+        <tp:docstring>
+          The chosen mechanism.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Initial_Data" type="ay">
+        <tp:docstring>
+          Initial data (an "initial response" in RFC 4422's terminology) to send
+          with the mechanism.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Start an authentication try using <var>Mechanism</var>, and send
+          <var>Initial_Data</var> as the "initial response" defined in
+          <a href="http://tools.ietf.org/html/rfc4422#section-3.3">RFC 4422
+            §3.3</a>.</p>
+
+        <tp:rationale>
+          <p>This method is appropriate for mechanisms where the client may
+            send data first, such as <code>PLAIN</code>, or must send data
+            first, such as
+            <code><a href="http://tools.ietf.org/html/rfc2831">DIGEST-MD5</a></code>
+            in "subsequent authentication" mode.</p>
+
+          <p>Having two methods allows any mechanism where it makes a difference
+            to distinguish between the absence of an initial response
+            (<tp:member-ref>StartMechanism</tp:member-ref>) and a zero-byte
+            initial response (StartMechanismWithData, with Initial_Data
+            empty).</p>
+        </tp:rationale>
+
+        <p>If the <tp:member-ref>HasInitialData</tp:member-ref>
+          property is false, this indicates that the underlying protocol
+          does not make it possible to send initial data. In such protocols,
+          this method may only be used for the <code>X-TELEPATHY-</code>
+          pseudo-mechanisms (such as <code>X-TELEPATHY-PASSWORD</code>),
+          and will fail if used with an ordinary SASL mechanism.</p>
+
+        <tp:rationale>
+          <p>For instance, the IRC SASL extension implemented in Charybdis and
+            Atheme does not support initial data - the first message in the
+            exchange only carries the mechanism. This is significant if using
+            <code><a href="http://tools.ietf.org/html/rfc2831">DIGEST-MD5</a></code>,
+            which cannot be used in the faster "subsequent authentication"
+            mode on a protocol not supporting initial data.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The channel is not in a state where starting authentication makes
+            sense (i.e. SASL_Status_Not_Started, or (if
+            <tp:member-ref>CanTryAgain</tp:member-ref> is true)
+            SASL_Status_Server_Failed or
+            SASL_Status_Client_Failed). You should call
+            <tp:member-ref>AbortSASL</tp:member-ref> and wait for
+            SASL_Status_Client_Failed before starting another attempt.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The server or connection manager doesn't implement the given
+            SASL mechanism (choose one from
+            <tp:member-ref>AvailableMechanisms</tp:member-ref>, or abort
+            authentication if none of them are suitable), or doesn't allow
+            initial data to be sent (as indicated by
+            <tp:member-ref>HasInitialData</tp:member-ref>; call
+            <tp:member-ref>StartMechanism</tp:member-ref> instead).
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="Respond" tp:name-for-bindings="Respond">
+      <arg direction="in" name="Response_Data" type="ay">
+        <tp:docstring>
+          The response data.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Send a response to the the last challenge received via
+          <tp:member-ref>NewChallenge</tp:member-ref>.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Either the state is not In_Progress, or no challenge has been
+            received yet, or you have already responded to the last challenge.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="AcceptSASL" tp:name-for-bindings="Accept_SASL">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If the channel's status is SASL_Status_Server_Succeeded,
+          this method confirms successful authentication and advances
+          the status of the channel to SASL_Status_Succeeded.</p>
+
+        <p>If the channel's status is SASL_Status_In_Progress, calling this
+          method indicates that the last
+          <tp:member-ref>NewChallenge</tp:member-ref> signal was in fact
+          additional data sent after a successful SASL negotiation, and
+          declares that from the client's point of view, authentication
+          was successful. This advances the state of the channel to
+          SASL_Status_Client_Accepted.</p>
+
+        <p>In mechanisms where the server authenticates itself to the client,
+          calling this method indicates that the client considers this to have
+          been successful. In the case of <tp:dbus-ref
+            namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          channels, this means that the connection manager MAY continue to
+          connect, and MAY advance the <tp:dbus-ref
+            namespace="ofdT">Connection.Status</tp:dbus-ref> to Connected.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Either the state is neither In_Progress nor Server_Succeeded, or no
+            challenge has been received yet, or you have already responded to
+            the last challenge.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="AbortSASL" tp:name-for-bindings="Abort_SASL">
+      <arg direction="in" name="Reason" type="u" tp:type="SASL_Abort_Reason">
+        <tp:docstring>
+          Reason for abort.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Debug_Message" type="s">
+        <tp:docstring>
+          Debug message for abort.
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Abort the current authentication try.</p>
+
+        <p>If the current status is SASL_Status_Server_Failed or
+          SASL_Status_Client_Failed, this method returns successfully, but has
+          no further effect. If the current status is SASL_Status_Succeeded
+          or SASL_Status_Client_Accepted then NotAvailable is raised.
+          Otherwise, it changes the channel's state to
+          SASL_Status_Client_Failed, with an appropriate error name and
+          reason code.</p>
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The current state is either Succeeded or Client_Accepted.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="SASLStatusChanged" tp:name-for-bindings="SASL_Status_Changed">
+      <tp:docstring>
+        Emitted when the status of the channel changes.
+      </tp:docstring>
+      <arg type="u" tp:type="SASL_Status" name="Status">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLStatus</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+      <arg type="s" tp:type="DBus_Error_Name" name="Reason">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLError</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+      <arg type="a{sv}" tp:type="String_Variant_Map" name="Details">
+        <tp:docstring>
+          The new value of <tp:member-ref>SASLErrorDetails</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="NewChallenge" tp:name-for-bindings="New_Challenge">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new challenge is received from the server, or when
+          a message indicating successful authentication and containing
+          additional data is received from the server.</p>
+
+        <p>When the channel's handler is ready to proceed, it should respond
+          to the challenge by calling <tp:member-ref>Respond</tp:member-ref>,
+          or respond to the additional data by calling
+          <tp:member-ref>AcceptSASL</tp:member-ref>. Alternatively, it may call
+          <tp:member-ref>AbortSASL</tp:member-ref> to abort authentication.</p>
+      </tp:docstring>
+      <arg name="Challenge_Data" type="ay">
+        <tp:docstring>
+          The challenge data or additional data from the server.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:enum name="SASL_Abort_Reason" type="u">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A reason why SASL authentication was aborted by the client.</p>
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Invalid_Challenge" value="0">
+        <tp:docstring>
+          The server sent an invalid challenge or data.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="User_Abort" value="1">
+        <tp:docstring>
+          The user aborted the authentication.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:enum name="SASL_Status" type="u" plural="SASL_Statuses">
+      <tp:enumvalue suffix="Not_Started" value="0">
+        <tp:docstring>
+          The initial state. The Handler SHOULD either
+          call <tp:member-ref>AbortSASL</tp:member-ref>, or connect to the
+          <tp:member-ref>NewChallenge</tp:member-ref> signal then call
+          <tp:member-ref>StartMechanism</tp:member-ref> or
+          <tp:member-ref>StartMechanismWithData</tp:member-ref>.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="In_Progress" value="1">
+        <tp:docstring>
+          The challenge/response exchange is in progress. The Handler SHOULD
+          call either <tp:member-ref>Respond</tp:member-ref> or
+          <tp:member-ref>AcceptSASL</tp:member-ref> exactly once per emission
+          of <tp:member-ref>NewChallenge</tp:member-ref>, or call
+          <tp:member-ref>AbortSASL</tp:member-ref> at any time.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Server_Succeeded" value="2">
+        <tp:docstring>
+          The server has indicated successful authentication, and the
+          connection manager is waiting for confirmation from the Handler.
+          The Handler must call either <tp:member-ref>AcceptSASL</tp:member-ref> or
+          <tp:member-ref>AbortSASL</tp:member-ref> to indicate whether it
+          considers authentication to have been successful.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Client_Accepted" value="3">
+        <tp:docstring>
+          The Handler has indicated successful authentication, and the
+          connection manager is waiting for confirmation from the server.
+          The state will progress to either Succeeded or Server_Failed when
+          confirmation is received.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Succeeded" value="4">
+        <tp:docstring>
+          Everyone is happy (the server sent success, and the client has called
+          <tp:member-ref>AcceptSASL</tp:member-ref>). Connection to the server
+          will proceed as soon as this state is reached. The Handler SHOULD
+          call <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+          to close the channel.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Server_Failed" value="5">
+        <tp:docstring>
+          The server has indicated an authentication failure.
+          If <tp:member-ref>CanTryAgain</tp:member-ref> is true,
+          the client may try to authenticate again, by calling
+          <tp:member-ref>StartMechanism</tp:member-ref> or
+          <tp:member-ref>StartMechanismWithData</tp:member-ref> again.
+          Otherwise, it should give up completely, by calling <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+          on the channel.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Client_Failed" value="6">
+        <tp:docstring>
+          The client has indicated an authentication failure. The
+          possible actions are the same as for Server_Failed.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Channel_Interface_SMS.xml b/qt4/spec/Channel_Interface_SMS.xml
index b0dce6647..4cfe3f2f8 100644
--- a/qt4/spec/Channel_Interface_SMS.xml
+++ b/qt4/spec/Channel_Interface_SMS.xml
@@ -27,9 +27,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       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>
+      <p>This interface contains SMS-specific properties for text
+        channels.</p>
+
+      <p>The presence of this interface on a channel does not imply that
+        messages will be delivered via SMS.</p>
+
+      <p>This interface MAY appear in the
+        <tp:dbus-ref namespace="ofdT.Channel">Interfaces</tp:dbus-ref> property
+        of channels where <tp:member-ref>SMSChannel</tp:member-ref> would be
+        immutable and false. It SHOULD appear on channels where
+        <tp:member-ref>SMSChannel</tp:member-ref> is immutable and true, and
+        also on channels where <tp:member-ref>SMSChannel</tp:member-ref> is
+        mutable (i.e. channels that might fall back to sending SMS at any
+        time, such as on MSN).</p>
 
       <h4>Handler filters</h4>
 
@@ -51,7 +62,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </tp:docstring>
 
     <property name="Flash" tp:name-for-bindings="Flash"
-      type="b" access="read" >
+      type="b" access="read" tp:immutable="yes">
       <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
@@ -89,5 +100,80 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:rationale>
       </tp:docstring>
     </property>
+
+    <property name="SMSChannel"
+              tp:name-for-bindings="SMS_Channel"
+              type="b"
+              access="read" tp:requestable="yes" tp:immutable="sometimes">
+      <tp:added version="0.21.7"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If TRUE, messages sent and received on this channel are transmitted
+          via SMS.</p>
+
+        <p>If this property is included in the channel request, the
+          Connection Manager MUST return an appropriate channel (i.e. if TRUE
+          the channel must be for SMSes, if FALSE it must not), or else fail
+          to provide the requested channel with the
+          <tp:error-ref>NotCapable</tp:error-ref>
+          error.</p>
+
+        <p>For example, to explicitly request an SMS channel to a contact.
+          You might construct a channel request like:</p>
+
+        <blockquote><pre>{
+  Channel.Type: Channel.Type.Text,
+  Channel.TargetHandleType: Handle_Type_Contact,
+  Channel.TargetID: escher.cat,
+  Channel.Interface.SMS.SMSChannel: True,
+}</pre></blockquote>
+
+        <tp:rationale>
+          Some protocols allow us to send SMSes to a remote contact, without
+          knowing the phone number to which those SMSes will be sent. This
+          provides a mechanism to request such channels.
+        </tp:rationale>
+
+        <p>If this property is not included in the channel request, the
+          Connection Manager MAY return an SMS channel if that is the most
+          appropriate medium (i.e. if the channel target is a phone
+          number).</p>
+
+        <tp:rationale>
+          To some types of identifiers (i.e. phone numbers) it only makes
+          sense to return an SMS channel, this is what happens currently with
+          telepathy-ring. We don't want to break this behaviour when we are
+          not explicit about the type of channel we want. Alternatively, for
+          protocols where there is an SMS fallback for IM messages, it's
+          possible that we don't care what sort of channel we get, and simply
+          want notification of the transport.
+        </tp:rationale>
+
+        <p>Some protocols have a fallback to deliver IM messages via SMS.
+          On these protocols, the Connection Manager SHOULD set the property
+          value as appropriate, and notify its change with
+          <tp:member-ref>SMSChannelChanged</tp:member-ref>.</p>
+
+        <tp:rationale>
+          Protocols such as MSN can fall back to delivering IM messages via
+          SMS. Where possible we want clients to be able to inform the user
+          that their messages are going to be redirected to the remote
+          contact's phone.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <signal name="SMSChannelChanged"
+            tp:name-for-bindings="SMS_Channel_Changed">
+      <tp:added version="0.21.7"/>
+      <arg name="SMSChannel" type="b">
+        <tp:docstring>
+          The new value for <tp:member-ref>SMSChannel</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        This signal indicates a change in the
+        <tp:member-ref>SMSChannel</tp:member-ref> property.
+      </tp:docstring>
+    </signal>
   </interface>
 </node>
diff --git a/qt4/spec/Channel_Interface_Securable.xml b/qt4/spec/Channel_Interface_Securable.xml
new file mode 100644
index 000000000..d9d971394
--- /dev/null
+++ b/qt4/spec/Channel_Interface_Securable.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Securable"
+  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.Channel.Interface.Securable">
+    <tp:added version="0.21.5">as stable API</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface exists to expose security information about
+        <tp:dbus-ref namespace="ofdT">Channel</tp:dbus-ref>s. The two
+        properties are sometimes immutable and can be used to make
+        decisions on how cautious to be about transferring sensitive
+        data. The special case of <tp:dbus-ref
+        namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+        channels is one example of where the two properties are
+        immutable.</p>
+
+      <p>For example, clients MAY use these properties to decide
+        whether the <code>PLAIN</code> mechanism is acceptable for a
+        <tp:dbus-ref
+        namespace="ofdT.Channel.Interface">SASLAuthentication</tp:dbus-ref>
+        channel.</p>
+    </tp:docstring>
+
+    <property name="Encrypted"
+      tp:name-for-bindings="Encrypted" type="b"
+      access="read" tp:immutable="sometimes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if this channel occurs over an encrypted
+          connection. This <strong>does not</strong> imply that steps
+          have been taken to avoid man-in-the-middle attacks.</p>
+
+        <tp:rationale>
+          <p>For future support for <a
+              href="http://tools.ietf.org/html/rfc5056">RFC 5056 Channel
+              Binding</a> it is desirable to be able to use some SASL
+            mechanisms over an encrypted connection to an unverified peer,
+            which can prove that it is the desired destination during
+            the SASL negotiation.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="Verified"
+      tp:name-for-bindings="Verified" type="b"
+      access="read" tp:immutable="sometimes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if this channel occurs over a connection that is
+          protected against tampering, and has been verified to be with
+          the desired destination: for instance, one where TLS was
+          previously negotiated, and the TLS certificate has been
+          verified against a configured certificate authority or
+          accepted by the user.</p>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Channel_Interface_Splittable.xml b/qt4/spec/Channel_Interface_Splittable.xml
index 7509c9c89..760c13406 100644
--- a/qt4/spec/Channel_Interface_Splittable.xml
+++ b/qt4/spec/Channel_Interface_Splittable.xml
@@ -53,12 +53,12 @@
       </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/qt4/spec/Channel_Request.xml b/qt4/spec/Channel_Request.xml
index 1d59eb874..1a9c397ef 100644
--- a/qt4/spec/Channel_Request.xml
+++ b/qt4/spec/Channel_Request.xml
@@ -209,6 +209,92 @@
       </tp:docstring>
     </signal>
 
+    <property name="Hints" tp:name-for-bindings="Hints"
+      type="a{sv}" access="read">
+      <tp:added version="0.21.5"/>
+      <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. Clients SHOULD namespace hint names by having them
+          start with a reversed domain name, in the same way as D-Bus
+          interface names.</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 does not currently interpret any of these
+          hints: they are solely for communication between cooperating
+          clients. If hints that do affect the channel dispatcher are added in
+          future, their names will start with an appropriate reversed domain
+          name (e.g. <code>org.freedesktop.Telepathy</code> for hints defined
+          by this specification, or an appropriate vendor name for third-party
+          plugins).</p>
+
+        <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.21.5"/>
+      <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>
+
+        <p>This signal MUST be emitted if the
+          <tp:dbus-ref namespace="ofdT">ChannelDispatcher</tp:dbus-ref>'s
+          <tp:dbus-ref
+            namespace="ofdT.ChannelDispatcher">SupportsRequestHints</tp:dbus-ref>
+          property is true. If supported, it MUST be emitted before
+          the <tp:member-ref>Succeeded</tp:member-ref> signal.</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="Connection_Properties" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A subset of the Connection's properties, currently unused.
+            This parameter may be used in future.</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>
+
+      <arg name="Channel_Properties" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The same immutable properties of the Channel that would appear
+            in a <tp:dbus-ref namespace="ofdT.Connection.Interface.Requests"
+              >NewChannels</tp:dbus-ref> signal.</p>
+        </tp:docstring>
+      </arg>
+
+    </signal>
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Channel_Type_Call.xml b/qt4/spec/Channel_Type_Call.xml
index 68dc7ffc7..039c1f982 100644
--- a/qt4/spec/Channel_Type_Call.xml
+++ b/qt4/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>
 
@@ -713,38 +1143,51 @@ 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="u" tp:type="Stream_Transport_Type" 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 <tp:type>Stream_Transport_Type</tp:type>_Unknown,
+          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
@@ -752,25 +1195,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>
+          <tp:dbus-ref namespace="ofdT.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: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
@@ -788,19 +1227,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>
 
@@ -813,12 +1252,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>
 
@@ -828,13 +1267,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>
 
@@ -852,11 +1327,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>
 
@@ -875,32 +1345,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>
 
@@ -931,7 +1401,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/qt4/spec/Channel_Type_Contact_Search.xml b/qt4/spec/Channel_Type_Contact_Search.xml
index de58bfcc0..fefa77a26 100644
--- a/qt4/spec/Channel_Type_Contact_Search.xml
+++ b/qt4/spec/Channel_Type_Contact_Search.xml
@@ -31,7 +31,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>A channel type for searching server-stored user directories. A new
         channel should be requested by a client for each search attempt, and
         closed when the search is completed or the required result has been
-        found.</p>
+        found. Channels of this type should have <tp:dbus-ref
+        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
+        <code>None</code> (and hence <tp:dbus-ref
+        namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref> <code>0</code> and
+        <tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref>
+        <code>""</code>). Requests for channels of this type need only
+        optionally specify the <tp:member-ref>Server</tp:member-ref> property
+        (if it is an allowed property in the connection's <tp:dbus-ref
+        namespace='ofdT.Connection.Interface.Requests'>RequestableChannelClasses</tp:dbus-ref>).</p>
 
       <p>Before searching, the
         <tp:member-ref>AvailableSearchKeys</tp:member-ref> property should be
@@ -240,8 +248,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </tp:simple-type>
 
-    <property name="Limit" type="u" access="read"
-      tp:name-for-bindings="Limit">
+    <property name="Limit" type="u" access="read" tp:name-for-bindings="Limit"
+      tp:immutable='yes' tp:requestable='sometimes'>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If supported by the protocol, the maximum number of results that
           should be returned, where <code>0</code> represents no limit. If the
@@ -254,23 +262,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <code>2</code>, the search service SHOULD only return <i>Antonius</i>
           and <i>Bridget</i>.</p>
 
-        <p>This property cannot change during the lifetime of the channel.
-          This property SHOULD be in the Allowed_Properties of a
-          <tp:type>Requestable_Channel_Class</tp:type> if and only if the
-          protocol supports specifying a limit; implementations SHOULD use
+        <p>This property SHOULD be requestable if and only if the protocol
+          supports specifying a limit; implementations SHOULD use
           <code>0</code> as the default if possible, or a protocol-specific
           sensible default otherwise.</p>
       </tp:docstring>
     </property>
 
     <property name="AvailableSearchKeys" type="as" access="read"
-      tp:name-for-bindings="Available_Search_Keys">
+      tp:name-for-bindings="Available_Search_Keys" tp:immutable='yes'>
       <tp:docstring>
         The set of search keys supported by this channel. Example values
         include [""] (for protocols where several address fields are
         implicitly searched) or ["x-n-given", "x-n-family", "nickname",
         "email"] (for XMPP XEP-0055, without extensibility via Data Forms).
-        This property cannot change during the lifetime of a channel.
 
         <tp:rationale>
           It can be in the <tp:dbus-ref
@@ -352,7 +357,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>
@@ -426,7 +431,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </signal>
 
     <property name="Server" tp:name-for-bindings="Server"
-      type="s" access="read">
+      type="s" access="read" tp:requestable='sometimes' tp:immutable='yes'>
       <tp:docstring>
         <p>For protocols which support searching for contacts on multiple
           servers with different DNS names (like XMPP), the DNS name of the
@@ -439,9 +444,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             User Directory").</p>
         </tp:rationale>
 
-        <p>This property cannot change during the lifetime of the channel.
-          This property SHOULD be in the Allowed_Properties of a
-          <tp:type>Requestable_Channel_Class</tp:type> if and only if the
+        <p>This property SHOULD be requestable if and only if the
           protocol supports querying multiple different servers;
           implementations SHOULD use a sensible default if possible if this
           property is not specified in a channel request.</p>
diff --git a/qt4/spec/Channel_Type_Server_Authentication.xml b/qt4/spec/Channel_Type_Server_Authentication.xml
new file mode 100644
index 000000000..76599aa35
--- /dev/null
+++ b/qt4/spec/Channel_Type_Server_Authentication.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Type_Server_Authentication" 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.Type.ServerAuthentication">
+    <tp:added version="0.21.5">(as stable API)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>The type for a channel representing an authentication step with the
+        server. The actual authentication functionality is implemented by
+        the additional interface named in
+        <tp:member-ref>AuthenticationMethod</tp:member-ref>,
+        such as <tp:dbus-ref namespace="ofdT"
+          >Channel.Interface.SASLAuthentication</tp:dbus-ref>.</p>
+
+      <p>Future authentication steps also supported by this channel type might
+        include solving a captcha and/or agreeing to an EULA or terms-of-use
+        document; each of these would be represented by a channel with this
+        type, but a different
+        <tp:member-ref>AuthenticationMethod</tp:member-ref>.</p>
+
+      <p>Channels of this type will normally be be signalled and dispatched
+        while the <tp:dbus-ref namespace="ofdT">Connection</tp:dbus-ref>
+        owning them is in the CONNECTING state. They MAY also appear on a
+        Connection in the CONNECTED state, for instance if periodic
+        re-authentication is required.</p>
+
+      <p>Normally, only one channel of this type will
+        exist on a given Connection; if there is more than one, the handler
+        must complete authentication with each of them in turn.</p>
+
+      <p>Channels of this type cannot be requested with methods such as
+        <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+        They always have <tp:dbus-ref
+          namespace="ofdT.Channel">Requested</tp:dbus-ref> = False,
+        <tp:dbus-ref
+          namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = None
+        and <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        = 0.</p>
+
+      <p>While it is CONNECTING, the Connection MUST NOT proceed with
+        connection, or signal
+        <tp:dbus-ref namespace="ofdT.Connection">StatusChanged</tp:dbus-ref>
+        to the CONNECTED state, until each channel of this type has either
+        been accepted as having a positive result (for instance, on SASL
+        channels this is done with the <tp:dbus-ref
+          namespace="ofdT.Channel.Interface.SASLAuthentication"
+          >AcceptSASL</tp:dbus-ref> method), or closed with the <tp:dbus-ref
+          namespace="ofdT.Channel">Close</tp:dbus-ref> method.</p>
+
+      <tp:rationale>
+        <p>ServerAuthentication channels normally represent the client
+          authenticating itself to the server, but can also be used for the
+          server to authenticate itself to the client (i.e. prove that it is
+          in fact the desired server and not an imposter). Until the
+          authentication handler has confirmed this, connection should not
+          continue.</p>
+      </tp:rationale>
+
+      <p>If a channel of this type is closed with the <tp:dbus-ref
+            namespace="ofdT.Channel">Close</tp:dbus-ref> method before
+        authentication has succeeded, this indicates that the Handler has
+        given up its attempts to authenticate or that no Handler is
+        available.</p>
+
+      <p>If this occurs, the connection manager MAY attempt to continue
+        connection (for instance, performing SASL authentication by using any
+        credentials passed to <tp:dbus-ref
+          namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>,
+        for instance from the <tp:dbus-ref
+          namespace="ofdT">Account.Parameters</tp:dbus-ref>). If this fails
+        or has already been tried, the <tp:dbus-ref
+          namespace="ofdT">Connection</tp:dbus-ref> will
+        disconnect.</p>
+
+      <tp:rationale>
+        <p>In particular, the <tp:dbus-ref
+            namespace="ofdT">ChannelDispatcher</tp:dbus-ref> will close the
+          channel if it cannot find a handler.</p>
+      </tp:rationale>
+
+      <p>When the connection is done with the channel and it is no
+        longer needed, it is left open until either the connection state
+        turns to DISCONNECTED or the handler closes the channel. The
+        channel SHOULD NOT close itself once finished with.</p>
+    </tp:docstring>
+
+    <property name="AuthenticationMethod"
+              tp:name-for-bindings="Authentication_Method"
+              type="s" tp:type="DBus_Interface" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>This property defines the method used for the authentication step
+          represented by this channel, which MUST be one of this channel's
+          <tp:dbus-ref namespace="ofdT.Channel">Interfaces</tp:dbus-ref>.</p>
+
+        <p>The initially-defined interface that can be used here is
+          <tp:dbus-ref namespace="ofdT"
+            >Channel.Interface.SASLAuthentication</tp:dbus-ref>.</p>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Channel_Type_Text.xml b/qt4/spec/Channel_Type_Text.xml
index 9cbfea21a..0cd4d5bb2 100644
--- a/qt4/spec/Channel_Type_Text.xml
+++ b/qt4/spec/Channel_Type_Text.xml
@@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </tp:license>
   <interface name="org.freedesktop.Telepathy.Channel.Type.Text">
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires
+    interface="org.freedesktop.Telepathy.Channel.Interface.Messages"/>
+    <tp:changed version="0.21.5">The Messages interface is now
+      mandatory</tp:changed>
 
     <tp:simple-type name="Message_ID" type="u" array-name="Message_ID_List">
       <tp:docstring>
@@ -31,6 +35,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:simple-type>
 
     <tp:struct name="Pending_Text_Message" array-name="Pending_Text_Message_List">
+      <tp:deprecated version="0.21.5">New APIs should use
+        an array of <tp:type>Message_Part</tp:type> instead.</tp:deprecated>
       <tp:docstring>A struct (message ID, timestamp in seconds since
         1970-01-01 00:00 UTC, sender's handle, message type, flags, text)
         representing a pending text message, as returned by
@@ -67,6 +73,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </method>
 
     <method name="GetMessageTypes" tp:name-for-bindings="Get_Message_Types">
+      <tp:deprecated version="0.21.5">Consulting
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >MessageTypes</tp:dbus-ref> is preferred.
+      </tp:deprecated>
       <arg direction="out" type="au" tp:type="Channel_Text_Message_Type[]"
         name="Available_Types">
         <tp:docstring>
@@ -81,6 +91,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <method name="ListPendingMessages"
       tp:name-for-bindings="List_Pending_Messages">
+      <tp:deprecated version="0.21.5">Consulting
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >PendingMessages</tp:dbus-ref> is preferred.
+      </tp:deprecated>
       <arg direction="in" name="Clear" type="b">
         <tp:docstring>
           If true, behave as if
@@ -114,6 +128,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </method>
 
     <signal name="LostMessage" tp:name-for-bindings="Lost_Message">
+      <tp:deprecated version="0.21.5">In practice, this signal
+        was not emitted, and does not have useful semantics.</tp:deprecated>
       <tp:docstring>
         This signal is emitted to indicate that an incoming message was
         not able to be stored and forwarded by the connection manager
@@ -122,6 +138,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </signal>
 
     <signal name="Received" tp:name-for-bindings="Received">
+      <tp:deprecated version="0.21.5">The
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >MessageReceived</tp:dbus-ref> signal is more informative.
+      </tp:deprecated>
       <arg name="ID" type="u">
         <tp:docstring>
           A numeric identifier for acknowledging the message
@@ -162,6 +182,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </signal>
 
     <method name="Send" tp:name-for-bindings="Send">
+      <tp:deprecated version="0.21.5">The
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >SendMessage</tp:dbus-ref> method is more flexible.
+      </tp:deprecated>
       <arg direction="in" name="Type" type="u" tp:type="Channel_Text_Message_Type">
         <tp:docstring>
           An integer indicating the type of the message
@@ -231,6 +255,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:enum>
 
     <signal name="SendError" tp:name-for-bindings="Send_Error">
+      <tp:deprecated version="0.21.5">Delivery reporting is now
+        provided by the <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Messages</tp:dbus-ref> interface.
+      </tp:deprecated>
       <arg name="Error" type="u" tp:type="Channel_Text_Send_Error">
         <tp:docstring>
           The error that occurred
@@ -266,6 +294,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </signal>
 
     <signal name="Sent" tp:name-for-bindings="Sent">
+      <tp:deprecated version="0.21.5">The
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >MessageSent</tp:dbus-ref> signal is more informative.
+      </tp:deprecated>
       <arg name="Timestamp" type="u" tp:type="Unix_Timestamp">
         <tp:docstring>
           Unix timestamp indicating when the message was sent
@@ -335,6 +367,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:enum>
 
     <tp:flags name="Channel_Text_Message_Flags" value-prefix="Channel_Text_Message_Flag" type="u">
+      <tp:deprecated version="0.21.5">The
+        <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Messages</tp:dbus-ref> interface has an extensible data structure
+        including separate booleans for most of these flags.
+      </tp:deprecated>
       <tp:flag suffix="Truncated" value="1">
         <tp:docstring>
         The incoming message was truncated to a shorter length by the
@@ -480,77 +517,98 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </tp:property>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A channel type for sending and receiving messages in plain text,
-        with no formatting. In future specifications, channels for sending
-        and receiving messages that can be reduced to plain text (i.e.
-        formatted text) should also have this type.</p>
+      <p>A channel type for sending and receiving messages. This channel type
+        is primarily used for textual messages, but can also be used for
+        formatted text, text with "attachments", or binary messages on some
+        protocols.</p>
+
+      <p>Most of the methods and signals on this interface are deprecated,
+        since they only support plain-text messages with limited metadata.
+        See the mandatory <tp:dbus-ref
+          namespace="ofdT.Channel.Interface">Messages</tp:dbus-ref>
+        interface for the modern equivalents.</p>
 
       <p>When a message is received, an identifier is assigned and a
-        <tp:member-ref>Received</tp:member-ref> signal emitted, and the message
-        placed in a pending queue which can be inspected with
-        <tp:member-ref>ListPendingMessages</tp:member-ref>. A client which has
-        handled the message by showing it to the user (or equivalent) should
-        acknowledge the receipt using the
-        <tp:member-ref>AcknowledgePendingMessages</tp:member-ref> method,
-        and the message will then be removed from the pending queue. Numeric
-        identifiers for received messages may be reused over the lifetime of
-        the channel.</p>
-
-      <p>Each message has an associated 'type' value, which should be one
-        of the values allowed by
-        <tp:type>Channel_Text_Message_Type</tp:type>.</p>
-
-      <p>Each message also has a flags value, which is a bitwise OR of the
-        flags given in <tp:type>Channel_Text_Message_Flags</tp:type>.</p>
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >MessageReceived</tp:dbus-ref> signal emitted, and the message
+        is placed in a pending queue represented by the
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >PendingMessages</tp:dbus-ref> property.
+        When the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+        for a channel has handled the message by showing it to the user
+        (or equivalent), it should acknowledge the receipt of that message
+        using the <tp:member-ref>AcknowledgePendingMessages</tp:member-ref>
+        method, and the message will then be removed from the pending queue.
+        Numeric identifiers for received messages may be reused over the
+        lifetime of the channel.</p>
 
       <p>Sending messages can be requested using the
-        <tp:member-ref>Send</tp:member-ref> method, which will return
-        successfully and emit the <tp:member-ref>Sent</tp:member-ref> signal
-        when the message has been delivered to the server, or return an error
-        with no signal emission if there is a failure. If a message is sent but
-        delivery of the message later fails, this is indicated with the
-        <tp:member-ref>SendError</tp:member-ref> signal.</p>
-
-      <p>On protocols where additional contacts cannot be invited into
-        a one-to-one chat, or where a one-to-one chat is just a series of
-        individual personal messages rather than being represented by some
-        object on the server (i.e. most protocols), one-to-one chats should be
-        represented by a Text channel with <tp:type>Handle_Type</tp:type>
-        CONTACT.</p>
+        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
+          >SendMessage</tp:dbus-ref> method, which will return
+        successfully when the message has been submitted for sending, or
+        return an error with no signal emission if there is an immediate
+        failure. If a message is submitted for sending but delivery of the
+        message later fails, this is indicated by a delivery report, which
+        is received in the same way as an incoming message.</p>
+
+      <p>Simple one-to-one chats (such as streams of private messages in
+        XMPP or IRC) should be represented by a Text channel whose
+        <tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>
+        is <tp:type>Handle_Type</tp:type>_Contact. The expected way to
+        request such a channel is to set the ChannelType, TargetHandleType,
+        and either TargetHandle or TargetID in a call to EnsureChannel.</p>
 
       <p>Named chat rooms whose identity can be saved and used again later
         (IRC channels, Jabber MUCs) are expected to be represented by Text
-        channels with <tp:type>Handle_Type</tp:type> ROOM and the <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface">Group</tp:dbus-ref>
-        interface; they should usually also have the Properties interface.</p>
-
-      <p>Unnamed, transient chat rooms defined only by their members (e.g. on
-        MSN) are expected to be represented by Text channels with handle type
-        0, handle 0, the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">Group</tp:dbus-ref>
-        interface, and optionally the Properties interface.</p>
-
-      <p>On protocols where a conversation with a user is actually just
-        a nameless chat room starting with exactly two members, to which
-        more members can be invited, calling
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">RequestChannel</tp:dbus-ref>
-        with type Text
-        and handle type CONTACT should continue to succeed, but may return
-        a channel with handle type 0, handle 0, the group interface,
-        and the local and remote contacts in its members.</p>
+        channels with <tp:type>Handle_Type</tp:type>_Room and the <tp:dbus-ref
+          namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        interface. In protocols where a chatroom can be used as a continuation
+        of one or more one-to-one chats, these channels should also have the
+        <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
+        interface.</p>
+
+      <p>Unnamed, transient chat rooms which cannot be rejoined by their
+        unique identifier (e.g. a conversation on MSN which has, or once had,
+        three or more participants) are expected to be represented by Text
+        channels with Handle_Type_None (and hence TargetHandle 0), the
+        <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        interface, and optionally the
+        <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
+        interface.</p>
+
+      <p>On protocols like MSN where a conversation with a user is actually
+        just a nameless chat room starting with exactly two members, to which
+        more members can be invited, the initial one-to-one conversation
+        SHOULD be represented with Handle_Type_Contact. If a third participant
+        joins or is invited, this SHOULD be represented by signalling
+        a new <tp:dbus-ref
+          namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref> channel
+        with the one-to-one channel in its <tp:dbus-ref
+          namespace="ofdT.Channel.Interface.Conference"
+          >InitialChannels</tp:dbus-ref>, migrating the underlying protocol
+        object from the one-to-one channel to the Conference channel,
+        and creating a new protocol-level conversation if the one-to-one
+        channel is re-used. See the Conference interface for more details.</p>
+
+      <tp:rationale>
+        <p>This keeps the presentation of all one-to-one conversations
+          uniform, and makes it easier to hand over a conversation from a
+          1-1-specific UI to a more elaborate multi-user UI; while it does
+          require UIs to understand Conference to follow the
+          upgrade, UIs that will deal with XMPP need to understand Conference
+          anyway.</p>
+      </tp:rationale>
 
       <p>If a channel of type Text is closed while it has pending messages,
-        the connection manager MUST allow this, but SHOULD open a new,
-        identical channel to deliver those messages, signalling it as a new
-        channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">NewChannel</tp:dbus-ref>
-        signal (with the suppress_handler parameter set to FALSE).</p>
-
-      <p>If messages were sent on the old channel but the
-        <tp:member-ref>Sent</tp:member-ref>signal has not yet been emitted
-        for those messages, the new channel SHOULD emit Sent for those
-        messages when appropriate - it behaves like a continuation of the
-        old channel.</p>
+        the connection manager MUST allow this, but SHOULD open a new channel
+        to deliver those messages, signalling it as a new channel with the
+        <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+        signal. The new channel should resemble the old channel, but have
+        Requested = FALSE regardless of its previous value; the InitiatorHandle
+        and InitiatorID should correspond to the sender of one of the pending
+        messages.</p>
 
       <tp:rationale>
         <p>In effect, this turns this situation, in which a client
@@ -573,16 +631,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <li>UI calls Close on text channel</li>
           <li>text channel emits Closed and closes</li>
           <li>message arrives</li>
-          <li>new text channel is created, connection emits NewChannel</li>
+          <li>new text channel is created, connection emits NewChannels</li>
           <li>(the same or a different) UI handles it</li>
         </ul>
 
-        <p>suppress_handler must be set to FALSE so the replacement channel
+        <p>Requested must be set to FALSE so the replacement channel
           will be handled by something.</p>
+
+        <p>In practice, connection managers usually implement this by keeping
+          the same internal object that represented the old channel, adjusting
+          its properties, signalling that it was closed, then immediately
+          re-signalling it as a new channel.</p>
       </tp:rationale>
 
       <p>As a result, Text channels SHOULD implement <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable</tp:dbus-ref>.</p>
+          namespace="ofdT">Channel.Interface.Destroyable</tp:dbus-ref>.</p>
 
       <tp:rationale>
         <p>This "respawning" behaviour becomes problematic if there is no
diff --git a/qt4/spec/Client_Handler.xml b/qt4/spec/Client_Handler.xml
index 2cceed170..3a922e8cc 100644
--- a/qt4/spec/Client_Handler.xml
+++ b/qt4/spec/Client_Handler.xml
@@ -103,8 +103,7 @@
             <code>/org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1</code>
             with BypassApproval = TRUE,
             whose <tp:member-ref>HandlerChannelFilter</tp:member-ref>
-            matches closely related Text channels by their Bundle property.
-            (This is use-case dis5)</p>
+            matches closely related Text channels by their Bundle property.</p>
         </tp:rationale>
 
         <p>For service-activatable handlers, this property should be specified
diff --git a/qt4/spec/Client_Handler_Future.xml b/qt4/spec/Client_Handler_Future.xml
index da31fadc3..4c1a8b761 100644
--- a/qt4/spec/Client_Handler_Future.xml
+++ b/qt4/spec/Client_Handler_Future.xml
@@ -33,6 +33,29 @@
         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">
diff --git a/qt4/spec/Client_Interface_Requests.xml b/qt4/spec/Client_Interface_Requests.xml
index cfab58de7..3cecfce49 100644
--- a/qt4/spec/Client_Interface_Requests.xml
+++ b/qt4/spec/Client_Interface_Requests.xml
@@ -125,8 +125,8 @@
             and <tp:dbus-ref
               namespace="org.freedesktop.Telepathy.ChannelRequest">Account</tp:dbus-ref>
             MUST be included, and <tp:dbus-ref
-              namespace="ofdT.ChannelRequest.FUTURE">Hints</tp:dbus-ref>
-            SHOULD be included if implemented.</p>
+              namespace="ofdT.ChannelRequest">Hints</tp:dbus-ref>
+            MUST be included if implemented.</p>
         </tp:docstring>
       </arg>
     </method>
diff --git a/qt4/spec/Connection.xml b/qt4/spec/Connection.xml
index 72f1e343c..51ec1ab23 100644
--- a/qt4/spec/Connection.xml
+++ b/qt4/spec/Connection.xml
@@ -222,6 +222,9 @@ USA.</p>
     </method>
 
     <method name="HoldHandles" tp:name-for-bindings="Hold_Handles">
+      <tp:changed version="0.21.6">If
+        <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+        this method no longer does anything.</tp:changed>
       <arg direction="in" name="Handle_Type" type="u" tp:type="Handle_Type">
         <tp:docstring>
           The type of handle to be held
@@ -235,7 +238,13 @@ USA.</p>
       </arg>
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Notify the connection manger that your client is holding a copy
+        <p>If <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+          which SHOULD always be the case in this version of telepathy-spec,
+          this method does nothing and returns successfully, unless
+          the given handle type or any of the given handles is invalid.</p>
+
+        <p>In older connection managers, this method
+        notifies the connection manger that your client is holding a copy
         of handles which may not be in use in any existing channel or
         list, and were not obtained by using the
         <tp:member-ref>RequestHandles</tp:member-ref> method. For
@@ -390,6 +399,9 @@ USA.</p>
     </signal>
 
     <method name="ReleaseHandles" tp:name-for-bindings="Release_Handles">
+      <tp:changed version="0.21.6">If
+        <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+        this method no longer does anything.</tp:changed>
       <arg direction="in" name="Handle_Type" type="u" tp:type="Handle_Type">
         <tp:docstring>
           An integer handle type (as defined in RequestHandle)
@@ -403,10 +415,17 @@ USA.</p>
       </arg>
 
       <tp:docstring>
-        Explicitly notify the connection manager that your client is no
+        <p>If <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+          which SHOULD always be the case in this version of telepathy-spec,
+          this method does nothing and returns successfully, unless
+          the given handle type or any of the given handles is invalid.</p>
+
+        <p>In older connection managers, this method
+        explicitly notifies the connection manager that your client is no
         longer holding any references to the given handles, and that they
         may be deallocated if they are not held by any other clients or
-        referenced by any existing channels. See HoldHandles for notes.
+        referenced by any existing channels. See
+        <tp:member-ref>HoldHandles</tp:member-ref> for notes.</p>
       </tp:docstring>
 
       <tp:possible-errors>
@@ -421,11 +440,6 @@ USA.</p>
             One of the given handles is not valid
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            One of the given handles is not held by this client
-          </tp:docstring>
-        </tp:error>
       </tp:possible-errors>
     </method>
 
@@ -622,6 +636,9 @@ USA.</p>
     </tp:simple-type>
 
     <method name="RequestHandles" tp:name-for-bindings="Request_Handles">
+      <tp:changed version="0.21.6">If
+        <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+        this method no longer has its reference-counting effect.</tp:changed>
       <arg direction="in" name="Handle_Type" type="u" tp:type="Handle_Type">
         <tp:docstring>
           The type of handle required
@@ -641,17 +658,23 @@ USA.</p>
         </tp:docstring>
       </arg>
 
-      <tp:docstring>
-        Request several handles from the connection manager which represent a
-        number of contacts, rooms or server-stored lists on the service. The
-        connection manager should record that these handles are in use by the
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Request several handles from the connection manager which represent a
+          number of contacts, rooms or server-stored lists on the service.</p>
+
+        <p>If <tp:member-ref>HasImmortalHandles</tp:member-ref> is true,
+          which SHOULD always be the case in this version of telepathy-spec,
+          the handles remain valid until the connection disconnects.</p>
+
+        <p>The implementation of this method in older connection managers
+        must 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:member-ref>ReleaseHandles</tp:member-ref>
         method. Where the identifier refers to an entity that already has a
         handle in this connection manager, this handle should be returned
         instead. The handle number 0 must not be returned by the connection
-        manager.
+        manager.</p>
       </tp:docstring>
 
       <tp:possible-errors>
@@ -722,7 +745,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>
 
@@ -985,7 +1008,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.
@@ -1050,6 +1073,137 @@ 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>
+
+    <property name="HasImmortalHandles"
+      tp:name-for-bindings="Has_Immortal_Handles"
+      access="read" type="b">
+      <tp:added version="0.21.6"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if handles last for the whole lifetime of the Connection.
+          This SHOULD be the case in all connection managers, but clients
+          MUST interoperate with older connection managers
+          (which reference-count handles).</p>
+      </tp:docstring>
+    </property>
+
     <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/qt4/spec/Connection_Interface_Anonymity.xml b/qt4/spec/Connection_Interface_Anonymity.xml
index 31f1554f8..704263cb9 100644
--- a/qt4/spec/Connection_Interface_Anonymity.xml
+++ b/qt4/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/qt4/spec/Connection_Interface_Cellular.xml b/qt4/spec/Connection_Interface_Cellular.xml
index 3dc29e329..99a360283 100644
--- a/qt4/spec/Connection_Interface_Cellular.xml
+++ b/qt4/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,32 +41,13 @@
           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>
-
-        <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>
       </tp:docstring>
     </property>
 
     <property name="OverrideMessageServiceCentre"
         tp:name-for-bindings="Override_Message_Service_Centre"
-        type="b" access="readwrite">
+        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>
@@ -82,31 +64,12 @@
             by Mission Control, rather than the UI needing to save it elsewhere
             to be restored if the user wants to reactivate it.</p>
         </tp:rationale>
-
-        <p>Connections with this interface SHOULD provide this property as a
-          parameter of the same (fully-qualified) name to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy"
-            >ConnectionManager.RequestConnection</tp:dbus-ref>, with the
-          <code>DBus_Property</code> flag. For connections managed by the
-          <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>,
-          this property SHOULD be set via the Account Manager as follows:</p>
-
-        <blockquote>
-          <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Account"
-            >UpdateParameters</tp:dbus-ref>({
-              "org.freedesktop.Telepathy.Connection.Interface.Cellular.OverrideMessageServiceCentre": True
-              }, [])</code>
-        </blockquote>
-
-        <p>The AccountManager provides change-notification, as long as all
-          other clients cooperate by using it instead of setting this property
-          directly.</p>
       </tp:docstring>
     </property>
 
     <property name="MessageServiceCentre" tp:name-for-bindings="Message_Service_Centre"
-      type="s" access="readwrite">
+      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
@@ -120,26 +83,6 @@
           <tp:member-ref>OverrideMessageServiceCentre</tp:member-ref> is
           <code>False</code>, this property's value should be ignored by the CM
           in favour of the SIM's default SMSC.</p>
-
-        <p>Connections with this interface SHOULD provide this property as a
-          parameter of the same (fully-qualified) name to <tp:dbus-ref
-            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>
       </tp:docstring>
     </property>
 
@@ -171,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
@@ -180,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/qt4/spec/Connection_Interface_Communication_Policy.xml b/qt4/spec/Connection_Interface_Communication_Policy.xml
index 9a92fa047..31343de68 100644
--- a/qt4/spec/Connection_Interface_Communication_Policy.xml
+++ b/qt4/spec/Connection_Interface_Communication_Policy.xml
@@ -146,13 +146,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:rationale>
       </tp:docstring>
       <tp:member type="as" tp:type="DBus_Interface[]"
-        name="Chanel_Types">
+        name="Channel_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">
+        name="Supported_Policies">
         <tp:docstring>
           A list of supported policies.
         </tp:docstring>
diff --git a/qt4/spec/Connection_Interface_Contact_Info.xml b/qt4/spec/Connection_Interface_Contact_Info.xml
index ce77a56af..527d32522 100644
--- a/qt4/spec/Connection_Interface_Contact_Info.xml
+++ b/qt4/spec/Connection_Interface_Contact_Info.xml
@@ -470,6 +470,36 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             any parameters may be used.</p>
         </tp:docstring>
       </tp:flag>
+
+      <tp:flag suffix="Overwritten_By_Nickname" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Indicates that this field will be overwritten when the user's alias
+            is changed with <tp:dbus-ref
+              namespace="ofdT.Connection.Interface.Aliasing">SetAliases</tp:dbus-ref>
+            or when the Account's <tp:dbus-ref
+              namespace="ofdT.Account">Nickname</tp:dbus-ref>
+            is updated.  Clients that allow the editing of the Alias and the
+            ContactInfo in the same location should hide fields with this flag.</p>
+          <tp:rationale>
+            <p>If a client allowed the user to edit both the nickname and the
+              ContactInfo field at the same time, the user could set them to two
+              different values even though they map to the same property.  This
+              would result in surprising behavior where the second value would
+              win over the first.</p>
+          </tp:rationale>
+          <p>In addition to hiding this field when editing ContactInfo together
+            with the user's nickname, it is recommended that clients call
+            <tp:member-ref>SetContactInfo</tp:member-ref> before setting the
+            user's nickname.</p>
+          <tp:rationale>
+            <p>This ensures that if the user changes the nickname, the correct
+              value will get set even if the stale nickname is mistakenly sent
+              along with <tp:member-ref>SetContactInfo</tp:member-ref>.</p>
+          </tp:rationale>
+          <p>If used, this flag typically appears on either the 'nickname' or
+            'fn' field.</p>
+        </tp:docstring>
+      </tp:flag>
     </tp:flags>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/qt4/spec/Connection_Interface_Contact_List.xml b/qt4/spec/Connection_Interface_Contact_List.xml
index d602c19f1..033c64d1d 100644
--- a/qt4/spec/Connection_Interface_Contact_List.xml
+++ b/qt4/spec/Connection_Interface_Contact_List.xml
@@ -173,10 +173,12 @@
 
       <arg direction="in" name="Hold" type="b">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Whether to hold the handles on behalf of the calling process.
-            Equivalent to the corresponding argument to <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
-              >GetContactAttributes</tp:dbus-ref>.</p>
+          <p>If true, all handles that appear as keys in the result have been
+            held on behalf of the calling process, as if by a call to
+            <tp:dbus-ref namespace="ofdT">Connection.HoldHandles</tp:dbus-ref>.
+            (If <tp:dbus-ref namespace="ofdT.Connection"
+              >HasImmortalHandles</tp:dbus-ref> is true, which SHOULD be the
+            case in all new connection managers, this has no effect.)</p>
         </tp:docstring>
       </arg>
 
@@ -574,8 +576,9 @@
       </tp:member>
     </tp:mapping>
 
-    <signal name="ContactsChanged"
-      tp:name-for-bindings="Contacts_Changed">
+    <signal name="ContactsChangedWithID"
+      tp:name-for-bindings="Contacts_Changed_With_ID">
+      <tp:added version="0.21.8"/>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Emitted when the contact list becomes available, when contacts'
           basic stored properties change, when new contacts are added to the
@@ -611,13 +614,53 @@
         </tp:docstring>
       </arg>
 
-      <arg name="Removals" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
+      <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The identifiers of the contacts in the <var>Changes</var> map.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Removals" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           The contacts that have been removed from the list that would be
           returned by
           <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.
+          contacts MUST NOT be listed both here and in <var>Changes</var>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="ContactsChanged"
+      tp:name-for-bindings="Contacts_Changed">
+      <tp:deprecated version="0.21.8">Connection managers MUST still
+        emit this signal, but clients SHOULD listen for the
+        <tp:member-ref>ContactsChangedWithID</tp:member-ref> signal in
+        addition, and ignore this signal after ContactsChangedWithID has been
+        emitted at least once.
+      </tp:deprecated>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted immediately after
+          <tp:member-ref>ContactsChangedWithID</tp:member-ref>, under the same
+          circumstances.</p>
+
+        <p>If clients receive this signal without first receiving a
+          corresponding <tp:member-ref>ContactsChangedWithID</tp:member-ref>,
+          they MUST assume that only this signal will be emitted.</p>
+      </tp:docstring>
+
+      <arg type="a{u(uus)}" name="Changes" tp:type="Contact_Subscription_Map">
+        <tp:docstring>
+          The same as the corresponding argument to
+          <tp:member-ref>ContactsChangedWithID</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Removals" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          The same as the corresponding argument to
+          <tp:member-ref>ContactsChangedWithID</tp:member-ref>, except that it
+          only includes handles and not identifiers.
         </tp:docstring>
       </arg>
     </signal>
@@ -652,15 +695,27 @@
           subscribe to their presence, i.e. that their subscribe attribute
           becomes Yes.</p>
 
+        <p>Connection managers SHOULD NOT attempt to enforce a
+          mutual-subscription policy (i.e. when this method is called, they
+          should not automatically allow the contacts to see the local user's
+          presence). User interfaces that require mutual subscription
+          MAY call <tp:member-ref>AuthorizePublication</tp:member-ref>
+          at the same time as this method.</p>
+
+        <tp:rationale>
+          <p>Whether to enforce mutual subscription is a matter of policy,
+            so it is left to the user interface and/or the server.</p>
+        </tp:rationale>
+
         <p>Before calling this method on a connection where <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing"
             >GetAliasFlags</tp:dbus-ref> returns the <code>User_Set</code> flag,
           user interfaces SHOULD obtain, from the user, an alias to
           identify the contact in future, and store it using <tp:dbus-ref
             namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing"
-            >SetAliases</tp:dbus-ref>.
+            >SetAliases</tp:dbus-ref>.</p>
 
-          The user MAY be
+        <p>The user MAY be
           prompted using the contact's current self-assigned nickname, or
           something derived from the contact's (presumably self-assigned)
           identifier, as a default, but these names chosen by the contact
@@ -793,6 +848,19 @@
           presence is sent to that contact, i.e. that their publish attribute
           becomes Yes.</p>
 
+        <p>Connection managers SHOULD NOT attempt to enforce a
+          mutual-subscription policy (i.e. when this method is called, they
+          should not automatically request that the contacts allow the user to
+          subscribe to their presence). User interfaces that require mutual
+          subscription MAY call
+          <tp:member-ref>RequestSubscription</tp:member-ref> at the same time
+          as this method.</p>
+
+        <tp:rationale>
+          <p>Whether to enforce mutual subscription is a matter of policy,
+            so it is left to the user interface and/or the server.</p>
+        </tp:rationale>
+
         <p>For contacts with publish=Yes, this method has no effect; it
           MUST return successfully if all contacts given have this state.</p>
 
diff --git a/qt4/spec/Connection_Interface_Contacts.xml b/qt4/spec/Connection_Interface_Contacts.xml
index cd769cebc..1020190d4 100644
--- a/qt4/spec/Connection_Interface_Contacts.xml
+++ b/qt4/spec/Connection_Interface_Contacts.xml
@@ -152,13 +152,16 @@
       </arg>
 
       <arg direction="in" name="Hold" type="b">
-        <tp:docstring>
-          If true, all handles in the result have been held on behalf of the
-          calling process, as if by a call to
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.HoldHandles</tp:dbus-ref>.
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>If true, all handles that appear as keys in the result have been
+            held on behalf of the calling process, as if by a call to
+            <tp:dbus-ref namespace="ofdT">Connection.HoldHandles</tp:dbus-ref>.
+            (If <tp:dbus-ref namespace="ofdT.Connection"
+              >HasImmortalHandles</tp:dbus-ref> is true, which SHOULD be the
+            case in all new connection managers, this has no effect.)</p>
 
           <tp:rationale>
-            For further round-trip avoidance.
+            <p>For further round-trip avoidance.</p>
           </tp:rationale>
         </tp:docstring>
       </arg>
diff --git a/qt4/spec/Connection_Interface_Keepalive.xml b/qt4/spec/Connection_Interface_Keepalive.xml
new file mode 100644
index 000000000..9f4ac6833
--- /dev/null
+++ b/qt4/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/qt4/spec/Connection_Interface_Location.xml b/qt4/spec/Connection_Interface_Location.xml
index 6c69a80c5..fe5492345 100644
--- a/qt4/spec/Connection_Interface_Location.xml
+++ b/qt4/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/qt4/spec/Connection_Interface_Mail_Notification.xml b/qt4/spec/Connection_Interface_Mail_Notification.xml
index cfe67a8f8..395e1019d 100644
--- a/qt4/spec/Connection_Interface_Mail_Notification.xml
+++ b/qt4/spec/Connection_Interface_Mail_Notification.xml
@@ -19,10 +19,16 @@ 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:client-interest>
+      <tp:docstring>
+        A client MUST notify interest in this feature before it will be
+        enabled.
+      </tp:docstring>
+    </tp:client-interest>
 
     <tp:flags name="Mail_Notification_Flags" value-prefix="Mail_Notification_Flag" type="u" >
       <tp:flag suffix="Supports_Unread_Mail_Count" value="1">
@@ -470,65 +476,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 +553,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/qt4/spec/Connection_Interface_Power_Saving.xml b/qt4/spec/Connection_Interface_Power_Saving.xml
index ae82d2fa2..571bf6d51 100644
--- a/qt4/spec/Connection_Interface_Power_Saving.xml
+++ b/qt4/spec/Connection_Interface_Power_Saving.xml
@@ -2,7 +2,7 @@
 <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:copyright> Copyright © 2007-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
@@ -19,9 +19,8 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Connection.Interface.PowerSaving.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.12"/>
+    name="org.freedesktop.Telepathy.Connection.Interface.PowerSaving">
+    <tp:added version="0.21.5">(as stable API)</tp:added>
     <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
diff --git a/qt4/spec/Connection_Manager.xml b/qt4/spec/Connection_Manager.xml
index 709a9b952..d75d866dd 100644
--- a/qt4/spec/Connection_Manager.xml
+++ b/qt4/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/qt4/spec/Media_Stream_Handler.xml b/qt4/spec/Media_Stream_Handler.xml
index c9ae78f46..123ea8be7 100644
--- a/qt4/spec/Media_Stream_Handler.xml
+++ b/qt4/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/qt4/spec/Protocol.xml b/qt4/spec/Protocol.xml
index e37fe224d..5e2c9b197 100644
--- a/qt4/spec/Protocol.xml
+++ b/qt4/spec/Protocol.xml
@@ -65,6 +65,7 @@ RequestableChannelClasses=text;
 VCardField=x-example
 EnglishName=Example
 Icon=im-example
+AuthenticationTypes=org.freedesktop.Telepathy.Channel.Type.ServerTLSConnection;org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication;
 
 [text]
 org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
@@ -74,11 +75,12 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
     </tp:docstring>
 
     <property name="Interfaces" tp:name-for-bindings="Interfaces"
-      access="read" type="as" tp:type="DBus_Interface[]">
+      access="read" type="as" tp:type="DBus_Interface[]"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of interfaces supported by this Protocol object.</p>
 
-        <p>This property is immutable, and should not be confused with
+        <p>This property should not be confused with
           <tp:member-ref>ConnectionInterfaces</tp:member-ref>,
           which refers to the interfaces of <em>connections</em> to this
           protocol.</p>
@@ -94,12 +96,13 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
     </property>
 
     <property name="Parameters" tp:name-for-bindings="Parameters"
-      access="read" type="a(susv)" tp:type="Param_Spec[]">
+      access="read" type="a(susv)" tp:type="Param_Spec[]"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The parameters which must or may be provided to the
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.ConnectionManager"
             >RequestConnection</tp:dbus-ref> method when connecting to the
-          given protocol. This property is immutable.</p>
+          given protocol.</p>
 
         <p>Connection managers with a <code>.manager</code> file
           (as described as part of the
@@ -115,7 +118,8 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
     <property name="ConnectionInterfaces"
       tp:name-for-bindings="Connection_Interfaces"
-      access="read" type="as" tp:type="DBus_Interface[]">
+      access="read" type="as" tp:type="DBus_Interface[]"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of interface names which might be in the
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection"
@@ -125,7 +129,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
           will have all, some or none of these interfaces depends on server
           capabilities.</p>
 
-        <p>This property is immutable, and should not be confused with
+        <p>This property should not be confused with
           <tp:member-ref>Interfaces</tp:member-ref>.</p>
 
         <p>Connection managers with a <code>.manager</code> file
@@ -138,7 +142,8 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
     <property name="RequestableChannelClasses"
       tp:name-for-bindings="Requestable_Channel_Classes"
-      access="read" type="a(a{sv}as)" tp:type="Requestable_Channel_Class[]">
+      access="read" type="a(a{sv}as)" tp:type="Requestable_Channel_Class[]"
+      tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of channel classes which might be requestable from a
           <tp:dbus-ref namespace="org.freedesktop.Telepathy"
@@ -152,8 +157,6 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
           similarly, individual contacts are not guaranteed to support
           all of these channel classes.</p>
 
-        <p>This property is immutable.</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, using the key
@@ -206,7 +209,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
     </property>
 
     <property name="VCardField" tp:name-for-bindings="VCard_Field"
-      access="read" type="s">
+      access="read" type="s" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of the most common vCard field used for this protocol's
           contact identifiers, normalized to lower case, or the empty string
@@ -251,7 +254,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
     </property>
 
     <property name="EnglishName" tp:name-for-bindings="English_Name"
-      access="read" type="s">
+      access="read" type="s" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of the protocol in a form suitable for display to users,
           such as "AIM" or "Yahoo!", or the empty string if none is
@@ -285,7 +288,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
     </property>
 
     <property name="Icon" tp:name-for-bindings="Icon"
-      access="read" type="s">
+      access="read" type="s" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of an icon in the system's icon theme, such as "im-msn", or
           the empty string.</p>
@@ -429,6 +432,54 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       </tp:possible-errors>
     </method>
 
+    <property name="AuthenticationTypes"
+      tp:name-for-bindings="Authentication_Types" access="read" type="as"
+      tp:type="DBus_Interface[]" tp:immutable="yes">
+      <tp:added version="0.21.7"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of D-Bus interfaces which provide information as to
+          what kind of authentication channels can possibly appear
+          before the connection reaches the CONNECTED state.</p>
+
+        <p>These can either be channel types, or where the channel
+          type isn't enough information to be useful, interfaces
+          indicating a specific use of a channel type. For example,
+          <tp:dbus-ref namespace="ofdT.Channel.Type">ServerTLSConnection</tp:dbus-ref>
+          channels are obviously about TLS certificates so the channel
+          type would appear in this list. However, a
+          <tp:dbus-ref namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          channel type alone does not explain enough about the authentication type
+          in use as it is merely a base for the channel interfaces that appear in
+          said channels. In this case, CMs should use the value of the
+          <tp:dbus-ref namespace="ofdT.Channel.Type">ServerAuthentication.AuthenticationMethod</tp:dbus-ref>
+          property in this list.</p>
+
+        <p>For example, if a protocol's
+          <tp:member-ref>AuthenticationTypes</tp:member-ref> contains
+          two values:</p>
+
+        <blockquote>
+          <pre>
+[ ...<tp:dbus-ref namespace="ofdT">Channel.Type.ServerTLSConnection</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="ofdT">Channel.Interface.SASLAuthentication</tp:dbus-ref> ]</pre></blockquote>
+
+        <p>This tells a client that before the connection status
+          reached CONNECTED, a <tp:dbus-ref
+          namespace="ofdT.Channel.Type">ServerTLSConnection</tp:dbus-ref>
+          could appear carrying a TLS certificate. It also tells the
+          client that before the connection status reaches CONNECTED, a
+          <tp:dbus-ref
+          namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          channel could also appear, where <tp:dbus-ref
+          namespace="ofdT.Channel.Type">ServerAuthentication.AuthenticationMethod</tp:dbus-ref>=<tp:dbus-ref
+          namespace="ofdT.Channel.Interface">SASLAuthentication</tp:dbus-ref>. A
+          hypothetical future Channel.Interface.Captcha interface would
+          also appear in this list if the CM might require the user
+          solve a captcha before connecting.</p>
+
+      </tp:docstring>
+    </property>
+
  </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/qt4/spec/Protocol_Interface_Avatars.xml b/qt4/spec/Protocol_Interface_Avatars.xml
index 262741e1a..cd913510d 100644
--- a/qt4/spec/Protocol_Interface_Avatars.xml
+++ b/qt4/spec/Protocol_Interface_Avatars.xml
@@ -20,9 +20,8 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Avatars.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:added version="0.19.8">(draft 1)</tp:added>
+  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Avatars">
+    <tp:added version="0.21.5">(as stable API)</tp:added>
     <tp:requires interface="org.freedesktop.Telepathy.Protocol"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/qt4/spec/Protocol_Interface_Presence.xml b/qt4/spec/Protocol_Interface_Presence.xml
index 47a37eab0..ddff33263 100644
--- a/qt4/spec/Protocol_Interface_Presence.xml
+++ b/qt4/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/qt4/spec/all.xml b/qt4/spec/all.xml
index 2709a4124..312340127 100644
--- a/qt4/spec/all.xml
+++ b/qt4/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.21.1</tp:version>
+<tp:version>0.21.8</tp:version>
 
 <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>
@@ -40,35 +40,72 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  <tp:section name="Connection Object">
   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
    <p>
-    Connections represent active protocol sessions.
+    Connections represent active protocol sessions. There are a number of core
+    interfaces which all connections should implement, and a number of optional
+    interfaces which provide various functionality related to contacts and to
+    the connection itself.
    </p>
   </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_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"/>
+
+  <tp:section name="Contact list interfaces">
+   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+    <p>
+     On protocols that support contact lists, these interface expose the user's
+     contact lists, along with presence subscription information and contact
+     list groups (if supported).
+    </p>
+   </tp:docstring>
+
+   <xi:include href="Connection_Interface_Contact_List.xml"/>
+   <xi:include href="Connection_Interface_Contact_Groups.xml"/>
+  </tp:section>
+
+  <tp:section name="Contact metadata interfaces">
+   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+    <p>
+     These optional Connection interfaces expose metadata about contacts on
+     this connection—from their current presence through to the type of client
+     they're connected with—and allow the local user to publish such metadata
+     back to their contacts.
+    </p>
+   </tp:docstring>
+
+   <xi:include href="Connection_Interface_Aliasing.xml"/>
+   <xi:include href="Connection_Interface_Avatars.xml"/>
+   <xi:include href="Connection_Interface_Capabilities.xml"/>
+   <xi:include href="Connection_Interface_Client_Types.xml"/>
+   <xi:include href="Connection_Interface_Contact_Capabilities.xml"/>
+   <xi:include href="Connection_Interface_Contact_Info.xml"/>
+   <xi:include href="Connection_Interface_Location.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_Simple_Presence.xml"/>
+  </tp:section>
+
+  <tp:section name="Connection feature interfaces">
+   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+    <p>
+     These optional Connection interfaces expose protocol-specific features,
+     and allow configuring the running connection.
+    </p>
+   </tp:docstring>
+
+   <xi:include href="Connection_Interface_Addressing.xml"/>
+   <xi:include href="Connection_Interface_Anonymity.xml"/>
+   <xi:include href="Connection_Interface_Balance.xml"/>
+   <xi:include href="Connection_Interface_Cellular.xml"/>
+   <xi:include href="Connection_Interface_Communication_Policy.xml"/>
+   <xi:include href="Connection_Interface_Forwarding.xml"/>
+   <xi:include href="Connection_Interface_Keepalive.xml"/>
+   <xi:include href="Connection_Interface_Mail_Notification.xml"/>
+   <xi:include href="Connection_Interface_Power_Saving.xml"/>
+   <xi:include href="Connection_Interface_Service_Point.xml"/>
+  </tp:section>
  </tp:section>
 
  <xi:include href="Channel_Bundle.xml"/>
@@ -101,6 +138,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_Authentication.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"/>
@@ -112,28 +150,65 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
     <p>
      A Channel may also implement one or more of the following interfaces,
-     depending on its type:
+     depending on its type. Some interfaces are only applicable to particular
+     channel types, while others may (in principle) appear on any type of
+     channel.
     </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"/>
-   <xi:include href="Channel_Interface_Conference.xml"/>
-   <xi:include href="Channel_Interface_DTMF.xml"/>
    <xi:include href="Channel_Interface_Destroyable.xml"/>
    <xi:include href="Channel_Interface_Group.xml"/>
-   <xi:include href="Channel_Interface_HTML.xml"/>
-   <xi:include href="Channel_Interface_Hold.xml"/>
-   <xi:include href="Channel_Interface_Media_Signalling.xml"/>
-   <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_SASL_Authentication.xml"/>
+   <xi:include href="Channel_Interface_Securable.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 name="Text-specific interfaces">
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>These interfaces may only appear on channels of type <tp:dbus-ref
+        namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>.</p>
+    </tp:docstring>
+
+    <xi:include href="Channel_Interface_Chat_State.xml"/>
+    <xi:include href="Channel_Interface_HTML.xml"/>
+    <xi:include href="Channel_Interface_Messages.xml"/>
+    <xi:include href="Channel_Interface_SMS.xml"/>
+   </tp:section>
+
+   <tp:section name="Streamed Media-related interfaces">
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+     <p>These interfaces are only applicable to channels of type <tp:dbus-ref
+       namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref>, with the
+       exception of the <tp:dbus-ref
+       namespace='ofdT.Channel.Interface'>Hold</tp:dbus-ref> interface, which
+       may also appear on <tp:dbus-ref
+       namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref> channels.</p>
+    </tp:docstring>
+
+    <xi:include href="Channel_Interface_Call_State.xml"/>
+    <xi:include href="Channel_Interface_DTMF.xml"/>
+    <xi:include href="Channel_Interface_Hold.xml"/>
+    <xi:include href="Channel_Interface_Media_Signalling.xml"/>
+   </tp:section>
+
+   <tp:section name="Conference-related interfaces">
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+     <p>These interfaces provide functionality for ad-hoc conference calls and
+       chat rooms. They are primarily intended for <tp:dbus-ref
+       namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>, <tp:dbus-ref
+       namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref> and
+       <tp:dbus-ref namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+       channels, but may also appear on other types of channel.</p>
+    </tp:docstring>
+
+    <xi:include href="Channel_Interface_Conference.xml"/>
+    <xi:include href="Channel_Interface_Splittable.xml"/>
+    <xi:include href="Channel_Interface_Mergeable_Conference.xml"/>
+   </tp:section>
   </tp:section>
  </tp:section>
 
@@ -179,9 +254,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  </tp:docstring>
  <xi:include href="Account_Manager.xml"/>
  <xi:include href="Account.xml"/>
+ <xi:include href="Account_Interface_Addressing.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">
@@ -193,11 +268,9 @@ 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/qt4/spec/errors.xml b/qt4/spec/errors.xml
index a5368c02f..eccbd0953 100644
--- a/qt4/spec/errors.xml
+++ b/qt4/spec/errors.xml
@@ -491,6 +491,59 @@
     </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:error name="Service Confused">
+    <tp:added version="0.21.5"/>
+    <tp:docstring>
+      Raised when a server or other piece of infrastructure indicates an
+      internal error, or when a message that makes no sense is received from
+      a server or other piece of infrastructure.
+
+      <tp:rationale>
+        For instance, this is appropriate for XMPP's
+        <code>internal-server-error</code>, and is also appropriate if
+        you receive sufficiently inconsistent information from a server that
+        you cannot continue.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Confused">
+    <tp:added version="0.21.5"/>
+    <tp:docstring>
+      Raised if a server rejects protocol messages from a connection manager
+      claiming that they do not make sense, two local processes fail to
+      understand each other, or an apparently impossible situation is
+      reached.
+
+      <tp:rationale>
+        For instance, this would be an appropriate mapping for XMPP's
+        errors bad-format, invalid-xml, etc., which can't happen unless
+        the local (or remote) XMPP implementation is faulty. This is
+        also analogous to
+        <tp:type>Media_Stream_Error</tp:type>_Invalid_CM_Behavior,
+        <code>TP_DBUS_ERROR_INCONSISTENT</code> in telepathy-glib, and
+        <code>TELEPATHY_QT4_ERROR_INCONSISTENT</code> in telepathy-qt4.
+      </tp:rationale>
+    </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/qt4/spec/template.xml b/qt4/spec/template.xml
index d752d721c..726472070 100644
--- a/qt4/spec/template.xml
+++ b/qt4/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>