Merge branch 'report-abuse' into gnome-2-34

16 files changed, 266 insertions, 669 deletions

diff --git a/extensions/Channel_Interface_Conference.xml b/extensions/Channel_Interface_Conference.xml
deleted file mode 100644
index afb99c5ca..000000000
--- a/extensions/Channel_Interface_Conference.xml
+++ /dev/null
@@ -1,635 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Conference"
-  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2009 Collabora Limited</tp:copyright>
-  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
-  <tp:license xmlns="http://www.w3.org/1999/xhtml">
-    <p>This library is free software; you can redistribute it and/or
-      modify it under the terms of the GNU Lesser General Public
-      License as published by the Free Software Foundation; either
-      version 2.1 of the License, or (at your option) any later version.</p>
-
-    <p>This library is distributed in the hope that it will be useful,
-      but WITHOUT ANY WARRANTY; without even the implied warranty of
-      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-      Lesser General Public License for more details.</p>
-
-    <p>You should have received a copy of the GNU Lesser General Public
-      License along with this library; if not, write to the Free Software
-      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-      02110-1301, USA.</p>
-  </tp:license>
-  <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Conference">
-    <tp:added version="0.19.13">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires
-      interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>An interface for multi-user conference channels that can "continue
-        from" one or more individual channels. This could be used to invite
-        other contacts to an existing 1-1 text conversation, combine two phone
-        calls into one conference call, and so on, with roughly the same API in
-        each case.</p>
-
-      <tp:rationale>
-        <p>This interface addresses freedesktop.org <a
-            href="http://bugs.freedesktop.org/show_bug.cgi?id=24906">bug
-            #24906</a> (GSM-compatible conference calls) and <a
-            href="http://bugs.freedesktop.org/show_bug.cgi?id=24939">bug
-            #24939</a> (upgrading calls and chats to multi-user).
-          See those bugs for more rationale and use cases.</p>
-      </tp:rationale>
-
-      <p>Existing channels are upgraded by requesting a new channel of the same
-        <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>,
-        listing the channels to be merged into the new conference in the
-        <tp:member-ref>InitialChannels</tp:member-ref> property of the request.
-        If <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
-        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
-        <var>Allowed_Properties</var> in <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>,
-        ad-hoc conferences to a set of contacts may be created by requesting a
-        channel, specifying
-        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and/or
-        <tp:member-ref>InitialInviteeIDs</tp:member-ref> to be the contacts in
-        question. A request may specify these alongside
-        <tp:member-ref>InitialChannels</tp:member-ref>, to simultaneously
-        upgrade a channel to a conference and invite others to join it.</p>
-
-      <p>Channels with this interface MAY also implement <tp:dbus-ref
-        namespace='ofdT.Channel.Interface'>MergeableConference.DRAFT</tp:dbus-ref>
-        to support merging more 1-1 channels into an ongoing conference.
-        Similarly, 1-1 channels MAY implement <tp:dbus-ref
-        namespace='ofdT.Channel.Interface'>Splittable.DRAFT</tp:dbus-ref> to
-        support being broken out of a Conference channel.</p>
-
-      <p>The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Group</tp:dbus-ref> interface on Conference channels MAY use
-          channel-specific handles for participants; clients SHOULD support
-          both Conferences that have channel-specific handles, and those that
-          do not.</p>
-
-      <tp:rationale>
-        <p>In the GSM case, the Conference's Group interface MAY have
-          channel-specific handles, to represent the fact that the same
-          phone number may be in a conference twice (for instance, it could be
-          the number of a corporate switchboard).</p>
-
-        <p>In the XMPP case, the Conference's Group interface SHOULD have
-          channel-specific handles, to reflect the fact that the participants
-          have MUC-specific identities, and the user might also be able to see
-          their global identities, or not.</p>
-
-        <p>In most other cases, including MSN and link-local XMPP, the
-          Conference's Group interface SHOULD NOT have channel-specific
-          handles, since users' identities are always visible.</p>
-      </tp:rationale>
-
-      <p>Connection managers implementing channels with this interface
-        MUST NOT allow the object paths of channels that could be merged
-        into a Conference to be re-used, unless the channel re-using the
-        object path is equivalent to the channel that previously used it.</p>
-
-      <tp:rationale>
-        <p>If you upgrade some channels into a conference, and then close
-          the original channels, <tp:member-ref>InitialChannels</tp:member-ref>
-          (which is immutable) will contain paths to channels which no longer
-          exist. This implies that you should not re-use channel object paths,
-          unless future incarnations of the path are equivalent.</p>
-
-        <p>For instance, on protocols where you can only have
-          zero or one 1-1 text channels with Emily at one time, it would
-          be OK to re-use the same object path for every 1-1 text channel
-          with Emily; but on protocols where this is not true, it would
-          be misleading.</p>
-      </tp:rationale>
-
-      <h4>Examples of usage</h4>
-
-      <p>A pair of 1-1 GSM calls <var>C1</var> and <var>C2</var> can be merged
-        into a single conference call by calling:</p>
-
-      <blockquote>
-        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...Call,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]
-          })</code>
-      </blockquote>
-
-      <p>which returns a new channel <var>Cn</var> implementing the conference
-        interface. (As a quirk of GSM, both 1-1 will cease to function normally
-        until they are <tp:dbus-ref
-          namespace="ofdT.Channel.Interface.Splittable.DRAFT">Split</tp:dbus-ref>
-        from the conference, or the conference ends.)</p>
-
-      <p>An XMPP 1-1 conversation <var>C3</var> (with
-        <tt>chris@example.com</tt>, say) can be continued in a newly created
-        multi-user chatroom by calling:</p>
-
-      <blockquote>
-        <code>CreateChannel({
-            ...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
-          })</code>
-      </blockquote>
-
-      <p>Or, to invite <tt>emily@example.net</tt> to join the newly-created MUC
-        at the same time:</p>
-
-      <blockquote>
-        <code>CreateChannel({
-            ...ChannelType: ...Text,
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3],
-            ...<tp:member-ref>InitialInviteeIDs</tp:member-ref>: ['emily@example.net']
-          })</code>
-      </blockquote>
-
-      <p>To continue <var>C3</var> in a particular multi-user
-        chatroom (rather than the implementation inventing a unique name for
-        the room), call:</p>
-
-      <blockquote>
-        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>({
-            ...ChannelType: ...Text,
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: ...Room,
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: 'telepathy@conf.example.com',
-            ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
-          })</code>
-      </blockquote>
-
-      <p>Note the use of EnsureChannel — if a channel for
-        <tt>telepathy@conf.example.com</tt> is already open, this SHOULD be
-        equivalent to inviting <tt>chris@example.com</tt> to the existing
-        channel.</p>
-
-      <p>In the above cases, the text channel <var>C3</var> SHOULD remain open
-        and fully functional (until explicitly closed by a client); new
-        incoming 1-1 messages from <tt>chris@example.com</tt> SHOULD appear in
-        <var>C3</var>, and messages sent using <var>C3</var> MUST be relayed
-        only to <tt>chris@example.com</tt>.</p>
-
-      <tp:rationale>
-        <p>If there is an open 1-1 text channel with a contact, in every
-          other situation new messages will appear in that channel. Given
-          that the old channel remains open — which is the least surprising
-          behaviour, and eases us towards a beautiful world where channels
-          never close themselves — it stands to reason that it should be
-          where new messages from Chris should appear. On MSN, creating a
-          conference from <var>C3</var> should migrate the underlying
-          switchboard from <var>C3</var> to the new channel; this is an
-          implementation detail, and should not affect the representation on
-          D-Bus. With a suitable change of terminology, Skype has the same
-          behaviour.</p>
-
-        <p>If the current handler of that channel doesn't want this to happen
-          (maybe it transformed the existing tab into the group chat window,
-          and so there'd be no UI element still around to show new messages),
-          then it should just <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> the
-          old 1-1 channel; it'll respawn if necessary.</p>
-      </tp:rationale>
-
-      <p>Either of the XMPP cases could work for Call channels, to
-        upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
-        could in principle work for link-local XMPP (XEP-0174).</p>
-
-      <p>XMPP and MSN do not natively have a concept of merging two or more
-        channels C1, C2... into one channel, Cn. However, the GSM-style
-        merging API can be supported on XMPP and MSN, as an API short-cut
-        for upgrading C1 into a conference Cn (which invites the
-        TargetHandle of C1 into Cn), then immediately inviting the
-        TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.</p>
-
-      <h4>Sample <tp:dbus-ref namespace='ofdT.Connection.Interface.Requests'
-                             >RequestableChannelClasses</tp:dbus-ref></h4>
-
-      <p>A GSM connection might advertise the following channel class for
-        conference calls:</p>
-
-      <blockquote>
-        <code>
-( Fixed = {<br/>
-    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
-      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref><br/>
-  },<br/>
-  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
-              <tp:dbus-ref namespace='ofdT.Channel.Type.StreamedMedia'
-                          >InitialAudio</tp:dbus-ref>
-            ]<br/>
-)
-        </code>
-      </blockquote>
-
-      <p>This indicates support for starting audio-only conference calls by
-        merging two or more existing channels (since
-        <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
-        <tp:member-ref>InitialInviteeIDs</tp:member-ref> are not allowed).</p>
-
-      <p>An XMPP connection might advertise the following classes for ad-hoc
-        multi-user text chats:</p>
-
-      <blockquote>
-        <code>
-( Fixed = {<br/>
-    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
-      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref><br/>
-  },<br/>
-  Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
-              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
-              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
-              <tp:member-ref>InvitationMessage</tp:member-ref>
-            ]<br/>
-),<br/>
-( Fixed = {<br/>
-    ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
-      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
-    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
-      Room<br/>
-  },<br/>
-  Allowed = [ <tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
-              <tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref>,<br/>
-              <tp:member-ref>InitialChannels</tp:member-ref>,
-              <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
-              <tp:member-ref>InitialInviteeIDs</tp:member-ref>,
-              <tp:member-ref>InvitationMessage</tp:member-ref>
-            ]<br/>
-)
-        </code>
-      </blockquote>
-
-      <p>The first class indicates support for starting ad-hoc (nameless) chat
-        rooms, upgraded from existing 1-1 channels and/or inviting new
-        contacts, along with a message to be sent along with the invitations.
-        The second indicates support for upgrading to a particular named chat
-        room.</p>
-    </tp:docstring>
-
-    <property name="Channels" tp:name-for-bindings="Channels"
-      access="read" type="ao">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The individual <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s that
-          are continued by this conference, which have the same <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
-              >ChannelType</tp:dbus-ref> as this one, but with <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
-              >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
-
-        <p>This property MUST NOT be requestable; instead, the
-          <tp:member-ref>InitialChannels</tp:member-ref> property may be
-          specified when requesting a channel.</p>
-
-        <tp:rationale>
-          <p>This is consistent with requesting
-            <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
-            <tp:member-ref>InitialInviteeIDs</tp:member-ref>, rather than
-            requesting <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.Members</tp:dbus-ref>
-            and some hypothetical ID version of that property.</p>
-       </tp:rationale>
-
-        <p>Change notification is via the
-          <tp:member-ref>ChannelMerged</tp:member-ref> and
-          <tp:member-ref>ChannelRemoved</tp:member-ref> signals.</p>
-      </tp:docstring>
-    </property>
-
-    <signal name="ChannelMerged" tp:name-for-bindings="Channel_Merged">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a new channel is added to the value of
-          <tp:member-ref>Channels</tp:member-ref>.</p>
-      </tp:docstring>
-
-      <arg name="Channel" type="o">
-        <tp:docstring>The channel that was added to
-          <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
-      </arg>
-
-      <arg name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
-        <tp:docstring>A new channel-specific handle for the <tp:dbus-ref
-          namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> of
-          <var>Channel</var>, as will appear in
-          <tp:member-ref>OriginalChannels</tp:member-ref>, or <tt>0</tt> if a
-          global handle is used for
-          <var>Channel</var>'s TargetHandle on the <tp:dbus-ref
-            namespace="ofdT.Channel.Interface">Group</tp:dbus-ref> interface
-          of this channel.</tp:docstring>
-      </arg>
-
-      <arg name="Properties" type="a{sv}"
-           tp:type="Qualified_Property_Value_Map">
-        <tp:docstring><var>Channel</var>'s immutable properties.</tp:docstring>
-      </arg>
-    </signal>
-
-    <signal name="ChannelRemoved" tp:name-for-bindings="Channel_Removed">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a channel is removed from the value of
-          <tp:member-ref>Channels</tp:member-ref>, either because it closed
-          or because it was split using the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Splittable.DRAFT.Split</tp:dbus-ref> method.</p>
-
-        <p>If a channel is removed because it was closed, <tp:dbus-ref
-          namespace='ofdT.Channel'>Closed</tp:dbus-ref> should be emitted
-          before this signal.</p>
-      </tp:docstring>
-
-      <arg name="Channel" type="o">
-        <tp:docstring>The channel that was removed from
-          <tp:member-ref>Channels</tp:member-ref>.</tp:docstring>
-      </arg>
-
-      <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          Additional information about the removal, which may include
-          the same well-known keys as the Details argument of
-          <tp:dbus-ref namespace="ofdT.Channel.Interface.Group"
-            >MembersChangedDetailed</tp:dbus-ref>, with the same semantics.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <property name="InitialChannels" tp:name-for-bindings="Initial_Channels"
-      access="read" type="ao">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The initial value of <tp:member-ref>Channels</tp:member-ref>.</p>
-
-        <p>This property SHOULD be requestable. Omitting it from a request is
-          equivalent to providing it with an empty list as value. Requests
-          where its value has at least two channel paths SHOULD be expected to
-          succeed on any implementation of this interface. If
-          <tp:member-ref>InitialInviteeHandles</tp:member-ref> and
-          <tp:member-ref>InitialInviteeIDs</tp:member-ref> are
-          <var>Allowed_Properties</var> in <tp:dbus-ref
-            namespace='ofdT.Connection.Interface.Requests'
-            >RequestableChannelClasses</tp:dbus-ref>, then requests with zero
-          or one channel paths SHOULD also succeed; otherwise, clients SHOULD
-          NOT make requests with zero or one paths for this property.</p>
-
-        <tp:rationale>
-          <p>In GSM, a pair of calls can be merged into a conference, but you
-            can't start a conference call from zero or one existing calls. In
-            XMPP and MSN, you can create a new chatroom, or upgrade one 1-1
-            channel into a chatroom; however, on these protocols, it is also
-            possible to fake GSM-style merging by upgrading the first channel,
-            then inviting the targets of all the other channels into it.</p>
-        </tp:rationale>
-
-        <p>If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD
-          NOT be altered by merging them into a conference. However, depending on
-          the protocol, the Channels MAY be placed in a "frozen" state by placing
-          them in this property's value or by calling
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.</p>
-
-        <tp:rationale>
-          <p>In Jingle, nothing special will happen to merged calls. UIs MAY
-            automatically place calls on hold before merging them, if that is
-            the desired behaviour; this SHOULD always work. Not doing
-            an implicit hold/unhold seems to preserve least-astonishment.</p>
-
-          <p>In GSM, the calls that are merged go into a state similar to
-            Hold, but they cannot be unheld, only split from the conference
-            call using <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-              >Channel.Interface.Splittable.DRAFT.Split</tp:dbus-ref>.</p>
-        </tp:rationale>
-
-        <p>Depending on the protocol, it might be signalled to remote users
-          that this channel is a continuation of all the requested channels,
-          or that it is only a continuation of the first channel in the
-          list.</p>
-
-        <tp:rationale>
-          <p>In MSN, the conference steals the underlying switchboard (protocol
-            construct) from one of its component channels, so the conference
-            appears to remote users to be a continuation of that channel and no
-            other. The connection manager has to make some arbitrary choice, so
-            we arbitrarily mandate that it SHOULD choose the first channel in
-            the list as the one to continue.</p>
-        </tp:rationale>
-
-        <p>This property is immutable.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="InitialInviteeHandles"
-      tp:name-for-bindings="Initial_Invitee_Handles"
-      access="read" type="au" tp:type="Contact_Handle[]">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A list of additional contacts invited to this conference when it
-          was created.</p>
-
-        <p>If it is possible to invite new contacts when creating a conference
-          (as opposed to merging several channels into one new conference
-          channel), this property SHOULD be requestable, and appear in the allowed
-          properties in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-            >RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property
-          SHOULD NOT be requestable, and its value SHOULD always be the empty
-          list.</p>
-
-        <tp:rationale>
-          <p>On GSM you have to place a 1-1 call before you can merge it into a
-            conference; on the other hand, you can invite new contacts to XMPP
-            Muji calls and XMPP/MSN/Skype ad-hoc chat rooms without starting a
-            1-1 channel with them first.</p>
-        </tp:rationale>
-
-        <p>If included in a request, the given contacts are automatically
-          invited into the new channel, as if they had been added with
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Group.AddMembers</tp:dbus-ref>(InitialInviteeHandles,
-          <tp:member-ref>InvitationMessage</tp:member-ref>) immediately after
-          the channel was created.</p>
-
-        <tp:rationale>
-          <p>This is a simple convenience API for the common case that a UI
-            upgrades a 1-1 chat to a multi-user chat solely in order to invite
-            someone else to participate.</p>
-        </tp:rationale>
-
-        <p>If the local user was not the initiator of this channel, the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Group.SelfHandle</tp:dbus-ref> SHOULD appear in the value of this
-          property, together with any other contacts invited at the same time
-          (if that information is known).</p>
-
-        <p>This property is immutable.</p>
-
-        <p>InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be
-          combined in a single request.</p>
-
-        <tp:rationale>
-          <p>For example, if you have a 1-1 channel C1 with Rob, and you want
-            to invite Sjoerd to join the discussion, you can do so by
-            requesting a channel with InitialChannels=[C1] and
-            InitialInviteeHandles=[sjoerd],
-            or InitialChannels=[C1] and
-            InitialInviteeIDs=["sjoerd@example.com"].</p>
-        </tp:rationale>
-
-        <p>If a request includes some combination of InitialInviteeHandles,
-          InitialInviteeIDs and InitialChannels, then the value of
-          InitialInviteeHandles on the resulting channel SHOULD be the union of
-          the handles from InitialInviteeHandles, the handles corresponding
-          to the InitialInviteeIDs, and the target handles of the
-          InitialChannels, with any duplicate handles removed. Because this
-          property is immutable, its value SHOULD be computed before the
-          channel is announced via the NewChannels signal.</p>
-
-        <tp:rationale>
-          <p>This simplifies identification of new channels in clients - they
-            only have to look at one of the properties, not both. For example,
-            after either of the requests mentioned above, the NewChannels
-            signal would announce the channel with InitialChannels=[C1],
-            InitialInviteeHandles=[rob, sjoerd], and
-            InitialInviteeIDs=["rob@example.net", "sjoerd.example.com"].</p>
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-    <property name="InitialInviteeIDs"
-      tp:name-for-bindings="Initial_Invitee_IDs"
-      access="read" type="as">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A list of additional contacts invited to this conference when it
-          was created.</p>
-
-        <p>This property SHOULD be requestable if and only if
-          <tp:member-ref>InitialInviteeHandles</tp:member-ref> is requestable.
-          Its semantics are the same, except that it takes a list of the
-          string representations of contact handles; invitations are sent to
-          any contact present in either or both of these properties.</p>
-
-        <p>When a channel is created, the values of InitialInviteeHandles and
-          InitialInviteeIDs MUST correspond to each other. In particular, this
-          means that the value of InitialInviteeIDs will include the TargetID
-          of each channel in InitialChannels, and the ID corresponding to each
-          handle in InitialInviteeHandles.</p>
-
-        <p>This property is immutable.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="InvitationMessage" tp:name-for-bindings="Invitation_Message"
-      access="read" type="s">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The message that was sent to the
-          <tp:member-ref>InitialInviteeHandles</tp:member-ref> when they were
-          invited.</p>
-
-        <p>This property SHOULD be requestable, and appear in the allowed
-          properties in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
-            >RequestableChannelClasses</tp:dbus-ref>, in protocols where
-          invitations can have an accompanying text message.</p>
-
-        <tp:rationale>
-          <p>This allows invitations with a message to be sent when using
-            <tp:member-ref>InitialInviteeHandles</tp:member-ref> or
-            <tp:member-ref>InitialInviteeIDs</tp:member-ref>.</p>
-        </tp:rationale>
-
-        <p>If the local user was not the initiator of this channel, the
-          message with which they were invited (if any) SHOULD appear in the
-          value of this property.</p>
-
-        <p>This property is immutable.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="OriginalChannels" tp:name-for-bindings="Original_Channels"
-              type="a{uo}" tp:type="Channel_Originator_Map"
-              access="read">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>On GSM conference calls, it is possible to have the same phone
-          number in a conference twice; for instance, it could be the number of
-          a corporate switchboard. This is represented using channel-specific
-          handles; whether or not a channel uses channel-specific handles is
-          reported in <tp:dbus-ref
-          namespace='ofdT.Channel.Interface'>Group.GroupFlags</tp:dbus-ref>.
-          The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref>
-          property specifies the mapping from opaque channel-specific handles
-          to actual numbers; this property specifies the original 1-1 channel
-          corresponding to each channel-specific handle in the conference.</p>
-
-        <p>In protocols where this situation cannot arise, such as XMPP,
-          this property MAY remain empty.</p>
-
-        <p>For example, consider this situation:</p>
-
-        <ol>
-          <li>Place a call (with path <tt>/call/to/simon</tt>) to the contact
-            <tt>+441234567890</tt> (which is assigned the handle <var>h</var>,
-            say), and ask to be put through to Simon McVittie;</li>
-          <li>Put that call on hold;</li>
-          <li>Place another call (with path <tt>/call/to/jonny</tt>) to
-            <tt>+441234567890</tt>, and ask to be put
-            through to Jonny Lamb;</li>
-          <li>Request a new channel with
-            <tp:member-ref>InitialChannels</tp:member-ref>:
-            <tt>['/call/to/simon', '/call/to/jonny']</tt>.</li>
-        </ol>
-
-        <p>The new channel will have the following properties, for some handles
-          <var>s</var> and <var>j</var>:</p>
-
-        <blockquote>
-          <code>{<br/>
-            ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>:
-                Channel_Specific_Handles | (other flags),<br/>
-            ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>:
-                [self_handle, s, j],<br/>
-            ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>:
-                { s: h, j: h },<br/>
-            ...<tp:member-ref>InitialChannels</tp:member-ref>:
-                ['/call/to/simon', '/call/to/jonny'],<br/>
-            ...<tp:member-ref>Channels</tp:member-ref>:
-                ['/call/to/simon', '/call/to/jonny'],<br/>
-            ...<tp:member-ref>OriginalChannels</tp:member-ref>:
-                { s: '/call/to/simon', j: '/call/to/jonny' },<br/>
-            # ...standard properties like ChannelType: Group elided...<br/>
-          }</code>
-        </blockquote>
-
-        <p>Change notification is via the
-          <tp:member-ref>ChannelMerged</tp:member-ref> and
-          <tp:member-ref>ChannelRemoved</tp:member-ref> signals: if
-          <var>Channel_Specific_Handle</var> in the former is non-zero, this
-          property SHOULD be updated to map that handle to the merged channel's
-          path.</p>
-      </tp:docstring>
-    </property>
-
-    <tp:mapping name="Channel_Originator_Map">
-      <tp:member name="Channel_Specific_Handle" type="u" tp:type="Contact_Handle">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          A channel-specific handle for a participant in this conference.
-        </tp:docstring>
-      </tp:member>
-      <tp:member name="Original_Channel" type="o">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          The object path of <tp:member-ref>Channels</tp:member-ref>
-          representing the original 1-1 channel with
-          <var>Channel_Specific_Handle</var>.
-        </tp:docstring>
-      </tp:member>
-
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        A mapping from members of a conference to the original 1-1 channel with
-        that contact, if any. See
-        <tp:member-ref>OriginalChannels</tp:member-ref> for details.
-      </tp:docstring>
-    </tp:mapping>
-  </interface>
-</node>
diff --git a/extensions/Connection_Interface_Contact_Blocking.xml b/extensions/Connection_Interface_Contact_Blocking.xml
new file mode 100644
index 000000000..543d43a5c
--- /dev/null
+++ b/extensions/Connection_Interface_Contact_Blocking.xml
@@ -0,0 +1,172 @@
+<?xml version="1.0" ?>
+<node name="/Connection_Interface_Contact_Blocking" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+      USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactBlocking.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface for connections where contacts can be blocked from
+        communicating with this user and receiving this user's presence.</p>
+
+      <p>When this interface becomes stable, it will replace the <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy.Channel.Type"
+          >ContactList</tp:dbus-ref> channel with TargetHandleType
+        Handle_Type_List and TargetID 'deny'.</p>
+    </tp:docstring>
+
+    <method name="BlockContacts" tp:name-for-bindings="Block_Contacts">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Direct the server to block some contacts. The precise effect is
+          protocol-dependent, but SHOULD include ignoring all current and
+          subsequent communications from the given contacts, avoiding sending
+          presence to them in future, and if they were already receiving the
+          local user's presence, behaving as if the local user went
+          offline.</p>
+
+        <p><em>FIXME: do we need to allow this on protocols where it won't
+            persist, or where we can't edit the block lists?</em></p>
+      </tp:docstring>
+
+      <arg name="Contacts" type="au" direction="in" tp:type="Contact_Handle[]">
+        <tp:docstring>Some contacts to block.</tp:docstring>
+      </arg>
+
+      <arg name="Report_Abusive" type="b" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>In addition to blocking, report these contacts as abusive to the
+            server administrators.</p>
+
+          <p>Clients can determine whether this capability is available by
+            checking the
+            <tp:member-ref>ContactBlockingCapabilities</tp:member-ref>
+            property. If the capability is not present and this argument is
+            true, the error <tp:error-ref>NotCapable</tp:error-ref> SHOULD
+            be raised.</p>
+
+          <tp:rationale>
+            Some protocol libraries, in their conformance requirements,
+            require the ability to report blocked contacts as abusive.
+          </tp:rationale>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="UnblockContacts" tp:name-for-bindings="Unblock_Contacts">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Reverse the effects of a previous call to
+          <tp:member-ref>BlockContacts</tp:member-ref>.</p>
+      </tp:docstring>
+
+      <arg name="Contacts" type="au" direction="in" tp:type="Contact_Handle[]">
+        <tp:docstring>Some contacts to unblock.</tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="RequestBlockedContacts"
+      tp:name-for-bindings="Request_Blocked_Contacts">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>List the contacts that are blocked.</p>
+
+        <p>Clients SHOULD allow a relatively long timeout for calls to this
+          method, since on some protocols contact blocking is part of the
+          contact list, which can take a significant time to retrieve.</p>
+      </tp:docstring>
+
+      <arg name="Contacts" type="au" direction="out" tp:type="Contact_Handle[]">
+        <tp:docstring>The list of blocked contacts.</tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="BlockedContactsChanged"
+      tp:name-for-bindings="Blocked_Contacts_Changed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the list of blocked contacts is first retrieved
+          (before returning from any pending calls to
+          <tp:member-ref>RequestBlockedContacts</tp:member-ref>), and
+          whenever the list of blocked contacts subsequently changes.</p>
+      </tp:docstring>
+
+      <arg name="BlockedContacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>Contacts added to the result of
+          <tp:member-ref>RequestBlockedContacts</tp:member-ref>.</tp:docstring>
+      </arg>
+
+      <arg name="UnblockedContacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>Contacts removed from the result of
+          <tp:member-ref>RequestBlockedContacts</tp:member-ref>.</tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:contact-attribute name="blocked" type="b">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if the contact would be in the result of
+          <tp:member-ref>RequestBlockedContacts</tp:member-ref>;
+          False or omitted if the contact is not blocked, or if it is
+          unknown whether the contact is blocked.</p>
+      </tp:docstring>
+    </tp:contact-attribute>
+
+    <property name="ContactBlockingCapabilities"
+              tp:name-for-bindings="Contact_Blocking_Capabilities"
+              tp:type="Contact_Blocking_Capabilities" type="u" access="read"
+              tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Additional capabilities for contact blocking (i.e. whether we can
+          report abusive contacts).</p>
+
+        <p><b>Note:</b> there is no capability for supporting blocking itself,
+          the presence of this interface indicates that contact blocking is
+          supported.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:flags name="Contact_Blocking_Capabilities" type="u"
+              value-prefix="Contact_Blocking_Capability">
+      <tp:flag suffix="Can_Report_Abusive" value="1">
+        <tp:docstring>
+          This protocol is capable of reporting abusive contacts to the server
+          administrators.
+        </tp:docstring>
+      </tp:flag>
+    </tp:flags>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/extensions/Makefile.am b/extensions/Makefile.am
index 8f4c8e581..79a5016eb 100644
--- a/extensions/Makefile.am
+++ b/extensions/Makefile.am
@@ -13,10 +13,10 @@ EXTRA_DIST = \
     generic-types.xml \
     misc.xml \
     Debug.xml \
-    Channel_Interface_Conference.xml \
     Logger.xml \
     Authentication_TLS_Certificate.xml \
     Channel_Type_Server_TLS_Connection.xml \
+    Connection_Interface_Contact_Blocking.xml \
     $(NULL)
 
 noinst_LTLIBRARIES = libemp-extensions.la
diff --git a/extensions/misc.xml b/extensions/misc.xml
index 320d488fd..6d0961b72 100644
--- a/extensions/misc.xml
+++ b/extensions/misc.xml
@@ -5,9 +5,9 @@
 <tp:title>Misc extensions for Empathy</tp:title>
 
 <xi:include href="Debug.xml" />
-<xi:include href="Channel_Interface_Conference.xml" />
 <xi:include href="Logger.xml" />
 <xi:include href="Authentication_TLS_Certificate.xml" />
 <xi:include href="Channel_Type_Server_TLS_Connection.xml" />
+<xi:include href="Connection_Interface_Contact_Blocking.xml" />
 
 </tp:spec>
diff --git a/libempathy-gtk/empathy-contact-blocking-dialog.c b/libempathy-gtk/empathy-contact-blocking-dialog.c
index 3d0b9afe9..a46820c5d 100644
--- a/libempathy-gtk/empathy-contact-blocking-dialog.c
+++ b/libempathy-gtk/empathy-contact-blocking-dialog.c
@@ -285,8 +285,9 @@ contact_blocking_dialog_am_prepared (GObject *am,
       TpAccount *account = ptr->data;
       TpConnection *conn;
 
-      g_signal_connect (account, "status-changed",
-          G_CALLBACK (contact_blocking_dialog_connection_status_changed), self);
+      tp_g_signal_connect_object (account, "status-changed",
+          G_CALLBACK (contact_blocking_dialog_connection_status_changed),
+          self, 0);
 
       conn = tp_account_get_connection (TP_ACCOUNT (account));
 
@@ -404,8 +405,9 @@ contact_blocking_dialog_deny_channel_prepared (GObject *channel,
       g_object_ref (conn), channel);
   contact_blocking_dialog_refilter_account_chooser (self);
 
-  g_signal_connect (channel, "group-members-changed",
-      G_CALLBACK (contact_blocking_dialog_deny_channel_members_changed), self);
+  tp_g_signal_connect_object (channel, "group-members-changed",
+      G_CALLBACK (contact_blocking_dialog_deny_channel_members_changed),
+      self, 0);
 }
 
 static void
diff --git a/libempathy-gtk/empathy-contact-dialogs.c b/libempathy-gtk/empathy-contact-dialogs.c
index 0b388851e..2f23a9163 100644
--- a/libempathy-gtk/empathy-contact-dialogs.c
+++ b/libempathy-gtk/empathy-contact-dialogs.c
@@ -85,15 +85,17 @@ subscription_dialog_response_cb (GtkDialog *dialog,
 					     contact, "");
 	}
 	else if (response == GTK_RESPONSE_REJECT) {
+		gboolean abusive;
+
 		/* confirm the blocking */
 		if (empathy_block_contact_dialog_show (GTK_WINDOW (dialog),
-						       contact, NULL)) {
+						       contact, &abusive)) {
 			empathy_contact_list_remove (
 					EMPATHY_CONTACT_LIST (manager),
 					contact, "");
 			empathy_contact_list_set_blocked (
 					EMPATHY_CONTACT_LIST (manager),
-					contact, TRUE);
+					contact, TRUE, abusive);
 		} else {
 			/* if they don't confirm, return back to the
 			 * first dialog */
@@ -530,8 +532,6 @@ empathy_block_contact_dialog_show (GtkWindow      *parent,
 	}
 
 	res = gtk_dialog_run (GTK_DIALOG (dialog));
-	gtk_widget_destroy (dialog);
-
 	if (abusive != NULL) {
 		if (abusive_check != NULL) {
 			*abusive = gtk_toggle_button_get_active (
@@ -541,6 +541,7 @@ empathy_block_contact_dialog_show (GtkWindow      *parent,
 		}
 	}
 
+	gtk_widget_destroy (dialog);
 	g_object_unref (manager);
 
 	return res == GTK_RESPONSE_REJECT;
diff --git a/libempathy-gtk/empathy-contact-menu.c b/libempathy-gtk/empathy-contact-menu.c
index 9984de42d..64056eebf 100644
--- a/libempathy-gtk/empathy-contact-menu.c
+++ b/libempathy-gtk/empathy-contact-menu.c
@@ -232,7 +232,7 @@ empathy_contact_block_menu_item_toggled (GtkCheckMenuItem *item,
 {
 	static guint block_signal = 0;
 	EmpathyContactManager *manager;
-	gboolean blocked;
+	gboolean blocked, abusive;
 
 	if (block_signal > 0)
 		return;
@@ -250,13 +250,13 @@ empathy_contact_block_menu_item_toggled (GtkCheckMenuItem *item,
 			"window");
 
 		if (!empathy_block_contact_dialog_show (GTK_WINDOW (parent),
-					contact, NULL))
+					contact, &abusive))
 			return;
 	}
 
 	manager = empathy_contact_manager_dup_singleton ();
 	empathy_contact_list_set_blocked (EMPATHY_CONTACT_LIST (manager),
-					  contact, blocked);
+					  contact, blocked, abusive);
 	g_object_unref (manager);
 
 	/* update the toggle with the blocked status */
diff --git a/libempathy-gtk/empathy-individual-dialogs.c b/libempathy-gtk/empathy-individual-dialogs.c
index e32ff05b6..22af8d567 100644
--- a/libempathy-gtk/empathy-individual-dialogs.c
+++ b/libempathy-gtk/empathy-individual-dialogs.c
@@ -240,7 +240,6 @@ empathy_block_individual_dialog_show (GtkWindow *parent,
   g_string_free (str, TRUE);
 
   res = gtk_dialog_run (GTK_DIALOG (dialog));
-  gtk_widget_destroy (dialog);
 
   if (abusive != NULL)
     {
@@ -251,5 +250,7 @@ empathy_block_individual_dialog_show (GtkWindow *parent,
         *abusive = FALSE;
     }
 
+  gtk_widget_destroy (dialog);
+
   return res == GTK_RESPONSE_REJECT;
 }
diff --git a/libempathy-gtk/empathy-individual-view.c b/libempathy-gtk/empathy-individual-view.c
index 55d25f801..d952b8269 100644
--- a/libempathy-gtk/empathy-individual-view.c
+++ b/libempathy-gtk/empathy-individual-view.c
@@ -2352,11 +2352,14 @@ individual_view_remove_activate_cb (GtkMenuItem *menuitem,
               text, can_block);
       if (res == GTK_RESPONSE_YES || res == GTK_RESPONSE_REJECT)
         {
+          gboolean abusive;
+
           if (res == GTK_RESPONSE_REJECT &&
-              empathy_block_individual_dialog_show (parent, individual, NULL))
+              empathy_block_individual_dialog_show (parent, individual,
+                &abusive))
             {
               empathy_individual_manager_set_blocked (manager, individual,
-                  TRUE);
+                  TRUE, abusive);
             }
           else
             {
diff --git a/libempathy/empathy-contact-list.c b/libempathy/empathy-contact-list.c
index d8af8938f..d28866735 100644
--- a/libempathy/empathy-contact-list.c
+++ b/libempathy/empathy-contact-list.c
@@ -282,12 +282,13 @@ empathy_contact_list_remove_from_favourites (EmpathyContactList *list,
 void
 empathy_contact_list_set_blocked (EmpathyContactList *list,
 				  EmpathyContact     *contact,
-				  gboolean            blocked)
+				  gboolean            blocked,
+				  gboolean            abusive)
 {
 	EmpathyContactListIface *iface = EMPATHY_CONTACT_LIST_GET_IFACE (list);
 
 	if (iface->set_blocked != NULL)
-		iface->set_blocked (list, contact, blocked);
+		iface->set_blocked (list, contact, blocked, abusive);
 }
 
 gboolean
diff --git a/libempathy/empathy-contact-list.h b/libempathy/empathy-contact-list.h
index 8be93baf9..cf523bf2a 100644
--- a/libempathy/empathy-contact-list.h
+++ b/libempathy/empathy-contact-list.h
@@ -81,7 +81,8 @@ struct _EmpathyContactListIface {
 					       EmpathyContact     *contact);
 	void             (*set_blocked)       (EmpathyContactList *list,
 			                       EmpathyContact     *contact,
-					       gboolean            blocked);
+					       gboolean            blocked,
+					       gboolean            abusive);
 	gboolean         (*get_blocked)       (EmpathyContactList *list,
 			                       EmpathyContact     *contact);
 };
@@ -125,7 +126,8 @@ void     empathy_contact_list_remove_from_favourites
 
 void     empathy_contact_list_set_blocked       (EmpathyContactList *list,
 		                                 EmpathyContact     *contact,
-						 gboolean            blocked);
+						 gboolean            blocked,
+						 gboolean            abusive);
 gboolean empathy_contact_list_get_blocked       (EmpathyContactList *list,
 						 EmpathyContact     *contact);
 
diff --git a/libempathy/empathy-contact-manager.c b/libempathy/empathy-contact-manager.c
index 2242159b5..b00f82477 100644
--- a/libempathy/empathy-contact-manager.c
+++ b/libempathy/empathy-contact-manager.c
@@ -867,7 +867,8 @@ contact_manager_remove_group (EmpathyContactList *manager,
 static void
 contact_manager_set_blocked (EmpathyContactList *manager,
 			     EmpathyContact     *contact,
-			     gboolean            blocked)
+			     gboolean            blocked,
+			     gboolean            abusive)
 {
 	EmpathyContactManagerPriv *priv = GET_PRIV (manager);
 	EmpathyContactList        *list;
@@ -879,7 +880,8 @@ contact_manager_set_blocked (EmpathyContactList *manager,
 	list = g_hash_table_lookup (priv->lists, connection);
 
 	if (list != NULL) {
-		empathy_contact_list_set_blocked (list, contact, blocked);
+		empathy_contact_list_set_blocked (list, contact,
+						  blocked, abusive);
 	}
 }
 
diff --git a/libempathy/empathy-individual-manager.c b/libempathy/empathy-individual-manager.c
index 4adf8e1cb..0a99b7c23 100644
--- a/libempathy/empathy-individual-manager.c
+++ b/libempathy/empathy-individual-manager.c
@@ -503,7 +503,8 @@ empathy_individual_manager_supports_blocking (EmpathyIndividualManager *self,
 void
 empathy_individual_manager_set_blocked (EmpathyIndividualManager *self,
     FolksIndividual *individual,
-    gboolean blocked)
+    gboolean blocked,
+    gboolean abusive)
 {
   EmpathyIndividualManagerPriv *priv;
   GList *personas, *l;
@@ -527,7 +528,7 @@ empathy_individual_manager_set_blocked (EmpathyIndividualManager *self,
       empathy_contact_set_persona (contact, FOLKS_PERSONA (persona));
       empathy_contact_list_set_blocked (
           EMPATHY_CONTACT_LIST (priv->contact_manager),
-          contact, blocked);
+          contact, blocked, abusive);
 
       g_object_unref (contact);
     }
diff --git a/libempathy/empathy-individual-manager.h b/libempathy/empathy-individual-manager.h
index cace94794..e0d8cf4de 100644
--- a/libempathy/empathy-individual-manager.h
+++ b/libempathy/empathy-individual-manager.h
@@ -102,7 +102,8 @@ gboolean empathy_individual_manager_supports_blocking (
 
 void empathy_individual_manager_set_blocked (EmpathyIndividualManager *self,
     FolksIndividual *individual,
-    gboolean blocked);
+    gboolean blocked,
+    gboolean abusive);
 
 G_END_DECLS
 #endif /* __EMPATHY_INDIVIDUAL_MANAGER_H__ */
diff --git a/libempathy/empathy-tp-chat.c b/libempathy/empathy-tp-chat.c
index 375683b62..c1e911e65 100644
--- a/libempathy/empathy-tp-chat.c
+++ b/libempathy/empathy-tp-chat.c
@@ -155,13 +155,13 @@ tp_chat_add (EmpathyContactList *list,
 		object_path = tp_proxy_get_object_path (priv->channel);
 
 		props = tp_asv_new (
-		    TP_IFACE_CHANNEL ".ChannelType", G_TYPE_STRING,
+		    TP_PROP_CHANNEL_CHANNEL_TYPE, G_TYPE_STRING,
 		        TP_IFACE_CHANNEL_TYPE_TEXT,
-		    TP_IFACE_CHANNEL ".TargetHandleType", G_TYPE_UINT,
+		    TP_PROP_CHANNEL_TARGET_HANDLE_TYPE, G_TYPE_UINT,
 		        TP_HANDLE_TYPE_NONE,
-		    EMP_IFACE_CHANNEL_INTERFACE_CONFERENCE ".InitialChannels",
+		    TP_PROP_CHANNEL_INTERFACE_CONFERENCE_INITIAL_CHANNELS,
 		        TP_ARRAY_TYPE_OBJECT_PATH_LIST, &channels,
-		    EMP_IFACE_CHANNEL_INTERFACE_CONFERENCE ".InitialInviteeIDs",
+		    TP_PROP_CHANNEL_INTERFACE_CONFERENCE_INITIAL_INVITEE_IDS,
 		        G_TYPE_STRV, invitees,
 		    /* FIXME: InvitationMessage ? */
 		    NULL);
@@ -907,7 +907,7 @@ tp_chat_update_remote_contact (EmpathyTpChat *chat)
 	 * have the group interface. If it has the conference interface, then
 	 * it is indeed a MUC. */
 	if (tp_proxy_has_interface_by_id (priv->channel,
-					  EMP_IFACE_QUARK_CHANNEL_INTERFACE_CONFERENCE)) {
+					  TP_IFACE_QUARK_CHANNEL_INTERFACE_CONFERENCE)) {
 		return;
 	}
 
@@ -1320,7 +1320,7 @@ tp_chat_constructor (GType                  type,
 			const char **oprops = g_value_get_boxed (
 				g_value_array_get_nth (array, 1));
 
-			if (tp_strv_contains (oprops, EMP_IFACE_CHANNEL_INTERFACE_CONFERENCE ".InitialChannels")) {
+			if (tp_strv_contains (oprops, TP_PROP_CHANNEL_INTERFACE_CONFERENCE_INITIAL_CHANNELS)) {
 				priv->can_upgrade_to_muc = TRUE;
 				break;
 			}
diff --git a/libempathy/empathy-tp-contact-list.c b/libempathy/empathy-tp-contact-list.c
index ec4f17245..90932a20a 100644
--- a/libempathy/empathy-tp-contact-list.c
+++ b/libempathy/empathy-tp-contact-list.c
@@ -31,6 +31,8 @@
 #include <telepathy-glib/dbus.h>
 #include <telepathy-glib/interfaces.h>
 
+#include <extensions/extensions.h>
+
 #include "empathy-tp-contact-list.h"
 #include "empathy-tp-contact-factory.h"
 #include "empathy-contact-list.h"
@@ -809,6 +811,27 @@ list_ensure_channel_cb (TpConnection *conn,
 }
 
 static void
+list_get_contact_blocking_capabilities_cb (TpProxy *conn,
+					   const GValue *value,
+					   const GError *in_error,
+					   gpointer user_data,
+					   GObject *weak_object)
+{
+	EmpathyTpContactList *list = EMPATHY_TP_CONTACT_LIST (weak_object);
+	EmpathyTpContactListPriv *priv = GET_PRIV (list);
+	EmpContactBlockingCapabilities caps;
+
+	g_return_if_fail (G_VALUE_HOLDS_UINT (value));
+
+	caps = g_value_get_uint (value);
+
+	if (caps & EMP_CONTACT_BLOCKING_CAPABILITY_CAN_REPORT_ABUSIVE) {
+		DEBUG ("Connection can report abusive contacts");
+		priv->flags |= EMPATHY_CONTACT_LIST_CAN_REPORT_ABUSIVE;
+	}
+}
+
+static void
 iterate_on_channels (EmpathyTpContactList *list,
 		     const GPtrArray *channels)
 {
@@ -922,6 +945,19 @@ conn_ready_cb (TpConnection *connection,
 		G_MAXINT, request, list_ensure_channel_cb, list, NULL, G_OBJECT (list));
 
 	g_hash_table_unref (request);
+
+	/* Find out if we support reporting abusive contacts --
+	 * this is done via the new Conn.I.ContactBlocking interface */
+	if (tp_proxy_has_interface_by_id (priv->connection,
+	    EMP_IFACE_QUARK_CONNECTION_INTERFACE_CONTACT_BLOCKING)) {
+		DEBUG ("Have Conn.I.ContactBlocking");
+
+		tp_cli_dbus_properties_call_get (priv->connection, -1,
+			EMP_IFACE_CONNECTION_INTERFACE_CONTACT_BLOCKING,
+			"ContactBlockingCapabilities",
+			list_get_contact_blocking_capabilities_cb,
+			NULL, NULL, G_OBJECT (list));
+	}
 out:
 	g_object_unref (list);
 }
@@ -1313,7 +1349,8 @@ tp_contact_list_get_flags (EmpathyContactList *list)
 static void
 tp_contact_list_set_blocked (EmpathyContactList *list,
 			     EmpathyContact     *contact,
-			     gboolean            blocked)
+			     gboolean            blocked,
+			     gboolean            abusive)
 {
 	EmpathyTpContactListPriv *priv = GET_PRIV (list);
 	TpHandle handle = empathy_contact_get_handle (contact);
@@ -1321,14 +1358,23 @@ tp_contact_list_set_blocked (EmpathyContactList *list,
 
 	g_return_if_fail (TP_IS_CHANNEL (priv->deny));
 
-	if (blocked)
+	if (blocked && abusive) {
+		/* we have to do this via the new interface */
+		g_return_if_fail (priv->flags &
+				EMPATHY_CONTACT_LIST_CAN_REPORT_ABUSIVE);
+
+		emp_cli_connection_interface_contact_blocking_call_block_contacts (
+			TP_PROXY (priv->connection), -1,
+			&handles, TRUE, NULL, NULL, NULL, NULL);
+	} else if (blocked) {
 		tp_cli_channel_interface_group_call_add_members (
 			priv->deny, -1,
 			&handles, NULL, NULL, NULL, NULL, NULL);
-	else
+	} else {
 		tp_cli_channel_interface_group_call_remove_members (
 			priv->deny, -1,
 			&handles, NULL, NULL, NULL, NULL, NULL);
+	}
 }
 
 static gboolean