133 files changed, 4253 insertions, 10725 deletions

diff --git a/Makefile b/Makefile
index 1063e4b6..6d050726 100644
--- a/Makefile
+++ b/Makefile
@@ -16,13 +16,17 @@ DISTNAME := telepathy-spec-$(VERSION)
 GENERATED_FILES = \
 	doc/spec/index.html \
 	FIXME.out \
+	doc/spec/NEWS \
 	$(NULL)
 
+doc/spec/NEWS: NEWS
+	install -m644 $< $@
+
 doc/spec/index.html: $(XMLS) tools/doc-generator.py tools/specparser.py $(TEMPLATES)
 	rm -rf doc/spec
 	install -d doc/spec
 	$(PYTHON) tools/doc-generator.py spec/all.xml doc/spec/ telepathy-spec \
-		org.freedesktop.Telepathy
+		im.telepathy1
 
 all: $(GENERATED_FILES)
 	@echo "Your spec HTML starts at:"
@@ -59,9 +63,9 @@ clean:
 
 maintainer-upload-snapshot: doc/spec/index.html
 	@install -d tmp
-	rsync $(DOC_RSYNC_FLAGS) doc/spec/ telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/spec-snapshot/
-	@echo The snapshot lives at:
-	@echo '  ' http://telepathy.freedesktop.org/spec-snapshot/
+	rsync $(DOC_RSYNC_FLAGS) doc/spec/ telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/spec-next/
+	@echo "The 'next' snapshot lives at:"
+	@echo '  ' http://telepathy.freedesktop.org/spec-next/
 
 maintainer-upload-release: doc/spec/index.html check
 	@install -d tmp
@@ -74,8 +78,7 @@ maintainer-upload-release: doc/spec/index.html check
 	gpg --verify telepathy-spec-$(VERSION).tar.gz.asc
 	rsync -vzP telepathy-spec-$(VERSION).tar.gz telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/releases/telepathy-spec/
 	rsync -vzP telepathy-spec-$(VERSION).tar.gz.asc telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/releases/telepathy-spec/
-	rsync $(DOC_RSYNC_FLAGS) doc/spec/ telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/spec/
-	rsync $(DOC_RSYNC_FLAGS) doc/spec/ telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/spec-snapshot/
+	rsync $(DOC_RSYNC_FLAGS) doc/spec/ telepathy.freedesktop.org:/srv/telepathy.freedesktop.org/www/spec-next/
 
 dist: check
 	@install -d tmp
diff --git a/NEWS b/NEWS
index a7d32572..ee53c37d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,11 +1,5 @@
-This file contains the same edited highlights as the announcement emails.
-For full details, see the ChangeLog in tarballs, or "git log" in Git
-checkouts.
-
-telepathy-spec 0.27.3 (2013-10-28)
-==================================
-
-The “Not lamp” release.
+Telepathy 0.99.4 (2013-10-29)
+=============================
 
 New stable API:
 
@@ -23,416 +17,122 @@ New stable API:
 • Conn.I.IRC_Command1, a new interface to send arbitrary IRC commands to the
   server
 
-telepathy-spec 0.27.2 (2013-09-24)
-==================================
-
-API additions and clarifications:
-
-• The Connection.SelfID property has been added containing the identifier of
-  the user on the connection.
-
-• The Connection.SelfHandleChanged signal has been deprecated and replaced
-  by the new Connection.SelfContactChanged signal.
-
-telepathy-spec 0.27.1 (2013-09-16)
-==================================
-
-The “substitute burger buns” release.
-
-Changes:
-
-• The handle-name property in room lists' room details is now mandatory
-  (Xavier)
-
-New stable API:
-
-• Account.Interface.Addressing has change-notification via the standard
-  D-Bus Properties.PropertiesChanged signal (fd.o #40393, Guillaume)
-
-Clarifications:
-
-• More Tubes properties are marked up as immutable (Will)
-
-telepathy-spec 0.27.0 (2012-05-09)
-==================================
-
-This is the first release in the 0.27 development branch.
-
-Changes since 0.26.0:
-
-• Mark ConnectionManager's Protocols and Protocol.I.Presence's Statuses
-  properties immutable (Andre Moreira Magalhae)
-
-• Add GetContactByID to get contact attributes for a single contact identifier
-  (Xavier Claessens)
-
-telepathy-spec 0.26.0 (2012-04-02)
-==================================
-
-This is the start of a new stable branch of the Telepathy
-specification.
-
-Changes since 0.25.2:
-
-• Small miscellaneous fixes to Call-related interfaces.
-
-Other notable changes since the 0.24 stable branch:
-
-• The Call1 family of interfaces is now considered stable after
-  substantial from previous drafts.
-
-• A Metadata file transfer interface has been added to transfer extra
-  data about a transfer in the channel.
-
-• A Picture channel interface has been added to retrieve and set
-  pictures for text channels and calls.
-
-telepathy-spec 0.25.2 (2012-02-20)
-==================================
-
-The "you know what they said? Well, some of it was true" release.
-
-New stable API:
-
-• The Call1 family of interfaces (except for the Mute interface) is now
-  considered stable, with significant changes since 0.25.1:
-
-  · Content.Removed signal removed, use Call1.ContentRemoved instead
-  · Content.I.DTMF added; this supersedes everything in Channel.I.DTMF
-    except the InitialTones property
-  · Various redundant contact handles removed from Content.I.Media
-  · MediaDescription.Reject has an "in" argument, not a nonsensical "out"
-    argument
-  · Stream.I.Media no longer has Pending_Pause or Paused states
-  · The Ringing state has been renamed to Initialising to avoid confusion
-    with the Ringing flag
-  · Call1.AddContent takes an initial direction as its new last parameter
-  · Call_Flag_Locally_Muted has been removed and the other Call_Flags
-    have been renumbered
-  · Call_Member_Flag_Ringing has been removed and the other Call_Member_Flags
-    have been renumbered
-  · The destination of a forwarded call is published in the CallStateDetails,
-    rather than abusing the Actor member of CallStateReason
-
-• Connection.I.Addressing1 is now stable, and identical to
-  Connection.I.Addressing.DRAFT in 0.25.1 except for its name
-
-• Account.Supersedes has been added
-
-• Connection.I.ContactList.DownloadAtConnection has been added, together with
-  the Download method
-
-• A serialization has been defined for arrays of object path in .manager
-  files (and by extension, anything sharing that format)
-
-Clarifications:
-
-• Account.Service should also be used for IRC networks
-
-• Channel.I.DTMF.InitialTones should only be used in conjunction with
-  InitialAudio=TRUE
-
-• The policy for versioned interfaces is now documented
-
-Changes to experimental API:
-
-• Channel.I.Addressing1 is the new name for Channel.I.Addressing.DRAFT,
-  but is still considered experimental
-
-telepathy-spec 0.25.1 (2011-11-23)
-==================================
-
-The “farewell whiskey chess” release.
-
-API additions and clarifications:
-
-• Call1.Content.Interface.AudioControl is a wonderful new interface to
-  allow the connection manager to recommend volume changes during calls.
-
-• The various values of Socket_Access_Control have enjoyed some
-  clarification of their meanings on different tube types.
-
-• Protocol.Interface.Addressing has been undrafted, with NormalizeURI
-  renamed to NormalizeContactURI.
-
-• Connection.Interface.Addressing is still a draft, but its methods have
-  been changed to split the return values into two mappings.
-
-telepathy-spec 0.25.0 (2011-11-10)
-==================================
-
-API additions and clarifications:
-
-• Channel.Interface.FileTransfer.Metadata has been added.
-
-• Channel.Interface.Picture has been added.
-
-• "windows-live" has been added as a known account service name.
-
-• Channel.Interface.Subject: clarify default values for properties in
-  the unknown case.
-
-• RoomConfig: add a PasswordHint property which does what you think it
-  does.
-
-• Room: add Creator, CreatorHandle and CreationTimestamp properties.
-
-• Channel.Type.ContactList has been deprecated.
-
-telepathy-spec 0.24.0 (2011-10-10)
-==================================
-
-The “underestimating the future” release.  This is the start of a new
-stable branch of the Telepathy specification.
-
-Changes since 0.23.4:
-
-• Channel.Interface.Room has been undrafted, with a few changes:
-  · The RoomID property has become RoomName;
-  · The Subject property has been split off onto a separate interface,
-    Channel.Interface.Subject (which is also undrafted).
-
-• Channel.Interface.RoomConfig has been defined to replace the remaining
-  klunky Telepathy.Properties on Channel.Type.Text.
-
-• As a result, the Telepathy.Properties interface has been deprecated,
-  since all interfaces which historically used it now have better
-  replacements.
-
-Other notable changes since the 0.22 stable branch:
-
-• Most interfaces now provide both handles and identifiers for contacts.
-  This makes life easier for telepathy-glib and telepathy-qt4 (and, by
-  extension, application authors).
-
-• A new revision of the Call family of interfaces has landed. It is
-  still marked experimental.
-
-• ChannelDispatcher has a pair of new methods, DelegateChannels() and
-  PresentChannel(), to aid user interfaces where channels can be shown
-  in a number of places (like Gnome 3).
-
-• FileTransfer now has a URI property to indicate the on-disk location
-  of the file being sent or received.
-
-telepathy-spec 0.23.4 (2011-09-29)
-==================================
-
-API additions and clarifications:
-
-• Always give contact identifiers together with handles in
-  Channel.Interface.Group. This helps clients to create contact objects without
-  extra async operations. Additions are:
-    • Channel.Interface.Group.MemberIdentifiers;
-    • Channel.Interface.Group.SelfContactChanged; and
-    • Channel.Interface.Group.HandleOwnersChangedDetailed.
-
-• AccountManager: remove note about service activation. Mission Control is
-  service-activatable and is probably the only implementation we'll ever have.
-
-• Clarify possible errors returned by AM.CreateAccount.
-
-Spec HTML improvements:
-
-• Now <tp:value-ref> is used to reference a value in a enumeration.
-
-Call DRAFT2 landed
-
-• Call interfaces are now versioned. For example
-  org.freedesktop.Telepathy.Channel.Type.Call.DRAFT is now renamed to
-  org.freedesktop.Telepathy.Channel.Type.Call1.
-
-telepathy-spec 0.23.3 (2011-07-14)
-==================================
-
-API additions and clarifications:
-
-• The semantics of the 'supersedes' header in Messages have been clarified, and
-  'original-message-sent' and 'original-message-received' headers have been
-  defined to make the timestamps used for message edits unambiguous.
-  (fd.o#37413, David)
-
-• A tonne of properties on FileTransfer have been marked as requestable and/or
-  immutable. Also, as a clarification, the spec now explicitly says that
-  approvers may set the URI property, and that handlers MUST obey this.
-  (Xavier)
-
-• A new ChannelRequest hint, DelegateToPreferredHandler, has been added.
-  (fd.o#38240, Danni)
-
-Spec HTML improvements:
-
-• Jumping to anchors within the spec HTML will no longer move the text you're
-  looking for underneath the title bar with Webkit. Yay! (Danni (my heroine))
-
-• The generated HTML spec now has a beautiful favicon. (fd.o#38594, Guillaume)
-
-And for spec developers:
-
-• `make upload-branch` now takes an optional UPLOAD_BRANCH_TO Makefile
-  variable, which allows you to override the default server, namely
-  “people.freedesktop.org” (João Paulo Rechi Vita)
-
-telepathy-spec 0.23.2 (2011-05-16)
-==================================
-
-Changes to existing API
------------------------
-
-• ChannelDispatcher.DelegateChannels() now calls HandleChannels once per
-  Channel. It also returns the list of Channels which have been delegated
-  and those which have not. (fdo #37109, Guillaume)
-
-telepathy-spec 0.23.1 (2011-05-09)
-==================================
-
-This first release in the 0.23 development branch contains all the fixes and
-additions from 0.22.3.
-
-Enhancements:
-
-• Channel.Interface.SMS.GetSMSLength() to allow SMS message chunking to be
-  shown to the user. (Danni)
-
-• ChannelDispatcher.DelegateChannels() to move channels between handlers.
-  (fdo #25293, Guillaume)
+Telepathy 0.99.3 (2013-10-28)
+=============================
 
-• ChannelDispatcher.PresentChannel(): convenient API to re-ensure an existing
-  channel. (fdo #25293, Guillaume)
+• Conn.I.Renaming is now considered as stable.
 
+Telepathy 0.99.2 (2013-09-27)
+=============================
 
-telepathy-spec 0.22.3 (2011-05-09)
-==================================
+The “no surprises” release.
 
-Fixes:
+• Connection manager names may now start with an underscore, because
+  there's no reason not to (the relevant D-Bus constructs all allow it).
 
-• Correct DBus_Property-parameter boilerplate. (fdo #37005, Will)
+Telepathy 0.99.1 (2013-09-17)
+=============================
 
-telepathy-spec 0.22.2 (2011-04-20)
-==================================
+The “house of cards” release.
 
-The “every cell stayed the same” release.
+This is the first snapshot towards Telepathy 1, a new major version of
+Telepathy. It is not usable yet - we're releasing this snapshot so we
+have a reference point for converting everything else.
 
-Once again, this release in the stable series includes some minor API
-additions.
+The aims of Telepathy 1 include:
 
-Enhancements:
+• Don't have many deprecated ways to do the same thing
+• Reduce complexity
+• Increase agility by making it less painful to add D-Bus API
+• Increase agility by making it less painful to break D-Bus API -
+  it shouldn't take 8 years to get from Telepathy 1 to Telepathy 2
 
-• Channel.Interface.SMS now includes some sample contact capabilities.
-  (Danni)
+We're not there yet, but we're getting there.
 
-• Connection.Interface.Balance now has a ManageCreditURI property.
-  (fd.o#36254, Danni)
+Major changes:
 
-• Connection.Interface.SimplePresence now has a
-  MaximumStatusMessageLength property. (fd.o#33054, André)
+• The top-level namespace org.freedesktop.Telepathy is now the much
+  shorter im.telepathy1
 
-• SimplePresence defines two new well-known status identifiers: "pstn"
-  and "chat". (fd.o#36159, Danni vs. Will)
+• A few interfaces are considered to be "core". After Telepathy
+  1 becomes stable, they will only break API in a new major version
+  (im.telepathy2):
 
-Fixes:
+  · Account, Connection, Channel and other "top-level" objects
+  · Channel.Type.Text
 
-• Protocol.Interface.Avatars properties are documented to be immutable.
-  (Guillaume)
+• The majority of interfaces are considered to be "extra". If we make
+  incompatible changes to them, we'll renumber them (e.g.
+  Channel.Type.Call1 might be replaced by Channel.Type.Call2 in future).
 
-• The tables in SimplePresence and Call's HTML documentation look nicer.
+• InspectHandles no longer exists, and anything that gives a handle should
+  also give an identifier.
 
-telepathy-spec 0.22.1 (2011-03-30)
-==================================
+• RequestHandles no longer exists, superseded by GetContactAttributes,
+  GetContactByID or by requesting a Room channel by its TargetID.
 
-The “we can change the things we know” release.
+• The Text and Messages interfaces have been turned into a unified
+  Text interface, whose API is basically the old Messages interface.
 
-Unconventionally, this release in the 0.22 stable series of the
-specification contains minor API additions. This is not intended to
-become a trend; once major changes land in the specification and a
-release is made in the 0.23.x unstable series, no new API will be added
-to the stable branch.
+Smaller changes:
 
-• A new error code, InsufficientBalance, has been added, along with a
-  balance-required key for the CallStateDetails dictionary. (Danni)
+• "valid Accounts" are now "usable Accounts" to avoid clashing with
+  the idea of proxy objects' validity, or weak pointers' validity
 
-• Media.StreamHandler has grown two new method/signal pairs, namely
-  SetRemoteFeedbackMessages/SupportedFeedbackMessages and
-  SetRemoteHeaderExtensions/SupportedHeaderExtensions, plus some related
-  types, for enabling exciting RTP header extensions and RTCP feedback
-  messages.
+• various data-types related to SimplePresence have dropped the "Simple"
+  prefix
 
-telepathy-spec 0.22.0 (2011-03-21)
-==================================
+• Protocol names and Service names may now contain underscores, but not
+  hyphen-minus (so telepathy-salut implements local_xmpp, not local-xmpp,
+  while telepathy-gabble now communicates with services that include
+  google_talk, lj_talk and windows_live)
 
-The “literate small talk” release.
+• There are no more 16-bit integers, even for port numbers. We use
+  32- or 64-bit integers throughout.
 
-This is a new stable version of telepathy-spec, intended to serve as a
-reference point for future work. There were no API changes since
-development release 0.21.13; significant additions and changes to
-non-DRAFT interfaces from the year-and-a-half of development since
-0.20.0 are summarized below.
+• ChannelDispatcher.CreateChannel, EnsureChannel are similar to the old
+  CreateChannelWithHints, EnsureChannelWithHints, but they also
+  return the ChannelRequest's immutable properties. The versions with
+  fewer arguments have been removed.
 
-The versions of libraries, connection managers and Mission Control
-recommended for use with GNOME 3.0 (such as the upcoming telepathy-glib
-0.14) can be expected to support most of the API from this spec release.
+• Group.MembersChanged now has the same arguments previously used by
+  MembersChangedDetailed, which has been deleted.
 
-Changes to existing API
------------------------
+• ChannelRequest.Succeeded has the extra arguments previously in
+  SucceededWithHints, which has been deleted.
 
-• Handles are no longer expected to be reference-counted - instead, they
-  persist as long as the Connection does. A new property,
-  HasImmortalHandles, indicates whether this is the case. Versions of
-  telepathy-glib since 0.13.8 implement these semantics, and set that
-  property, automatically for most connection managers.
+• Conn.I.ContactList.ContactsChanged has the extra arguments previously in
+  ContactsChangedWithID, which has been deleted.
 
-• message-token has been redefined from "globally unique"
-  to "whatever's in the underlying protocol", replacing the unimplemented
-  protocol-token. This makes it feasible to implement message-token again.
-  Note that connection managers implementing message-token should not be
-  backported to Maemo 5, since its event logger assumes that message-token
-  is guaranteed to be unique, which is usually unimplementable.
+• Client names may start with underscores
 
-• The Messages interface is now mandatory for Text channels.
+• Access_Control_Type_Group takes a string group name, not a handle.
 
-Enhancements to core API
-------------------------
+• AliasesChanged contains a map from contact handle to alias,
+  not an array of pairs.
 
-• The Connection has a pair of new methods, AddClientInterest and
-  RemoveClientInterest, to allow clients to subscribe to potentially
-  bandwidth-costly interfaces (such as MailNotification) in a generic
-  way.
+Deprecated things that were deleted include:
 
-• ChannelDispatcher and ChannelRequest now support "request hints"
-  (metadata passed through from the requester to the handler), and the
-  SucceededWithChannel signal.
+• "Telepathy Properties" (replaced by standard D-Bus properties)
 
-New optional interfaces
------------------------
+• Capabilities (replaced by ContactCapabilities)
 
-• The ContactList and ContactGroups interfaces for
-  connections are now considered stable, and a new ContactBlocking
-  interface has been added. Between them, these interfaces replace
-  ContactList channels.
+• Presence (replaced by SimplePresence)
 
-• The Connection.Interface.ClientTypes,
-  Connection.Interface.MailNotification,
-  Connection.Interface.Powersaving, and Protocol.Interface.Presence
-  interfaces are now considered stable.
+• StreamedMedia channels (replaced by Call channels)
 
-• Chan.T.ServerAuthentication and Chan.I.SASLAuthentication provide
-  interactive querying for credentials, allowing connection without
-  saving a password if there is a handler for these channels
+• ContactList channels (replaced by Conn.I.ContactList, Conn.I.ContactGroups)
+  and Handles of type LIST or GROUP
 
-• Chan.I.Securable indicates whether a channel is secure
+• Tubes channels (replaced by StreamTube, DBusTube channels)
 
-• Account.Interface.Addressing stores user preferences for use of
-  accounts for non-primary protocols, such as using SIP for telephony.
+• Many methods of the form GetFoo() (replaced by corresponding properties,
+  or by GetContactAttributes)
 
-Enhancements to optional interfaces
------------------------------------
+• ChannelHandler
 
-• Add a FileTransfer.URI property which can be used to tell other
-  Telepathy clients about the location of the transferred
-  file.
+• HoldHandles, ReleaseHandles
 
-Changes since 0.21.13
----------------------
+• ListChannels, NewChannel, RequestChannel (replaced by Conn.I.Requests)
 
-• A server-message key for the Details dictionary in the ConnectionError
-  signal has been defined. (wjt)
+• Various interfaces that never got beyond draft status
diff --git a/NEWS-0.x b/NEWS-0.x
new file mode 100644
index 00000000..7bccd4ee
--- /dev/null
+++ b/NEWS-0.x
@@ -0,0 +1,417 @@
+This file contains the same edited highlights as the announcement emails.
+For full details, see the ChangeLog in tarballs, or "git log" in Git
+checkouts.
+
+telepathy-spec 0.27.2 (2013-09-24)
+==================================
+
+API additions and clarifications:
+
+• The Connection.SelfID property has been added containing the identifier of
+  the user on the connection.
+
+• The Connection.SelfHandleChanged signal has been deprecated and replaced
+  by the new Connection.SelfContactChanged signal.
+
+telepathy-spec 0.27.1 (2013-09-16)
+==================================
+
+The “substitute burger buns” release.
+
+Changes:
+
+• The handle-name property in room lists' room details is now mandatory
+  (Xavier)
+
+New stable API:
+
+• Account.Interface.Addressing has change-notification via the standard
+  D-Bus Properties.PropertiesChanged signal (fd.o #40393, Guillaume)
+
+Clarifications:
+
+• More Tubes properties are marked up as immutable (Will)
+
+telepathy-spec 0.27.0 (2012-05-09)
+==================================
+
+This is the first release in the 0.27 development branch.
+
+Changes since 0.26.0:
+
+• Mark ConnectionManager's Protocols and Protocol.I.Presence's Statuses
+  properties immutable (Andre Moreira Magalhae)
+
+• Add GetContactByID to get contact attributes for a single contact identifier
+  (Xavier Claessens)
+
+telepathy-spec 0.26.0 (2012-04-02)
+==================================
+
+This is the start of a new stable branch of the Telepathy
+specification.
+
+Changes since 0.25.2:
+
+• Small miscellaneous fixes to Call-related interfaces.
+
+Other notable changes since the 0.24 stable branch:
+
+• The Call1 family of interfaces is now considered stable after
+  substantial from previous drafts.
+
+• A Metadata file transfer interface has been added to transfer extra
+  data about a transfer in the channel.
+
+• A Picture channel interface has been added to retrieve and set
+  pictures for text channels and calls.
+
+telepathy-spec 0.25.2 (2012-02-20)
+==================================
+
+The "you know what they said? Well, some of it was true" release.
+
+New stable API:
+
+• The Call1 family of interfaces (except for the Mute interface) is now
+  considered stable, with significant changes since 0.25.1:
+
+  · Content.Removed signal removed, use Call1.ContentRemoved instead
+  · Content.I.DTMF added; this supersedes everything in Channel.I.DTMF
+    except the InitialTones property
+  · Various redundant contact handles removed from Content.I.Media
+  · MediaDescription.Reject has an "in" argument, not a nonsensical "out"
+    argument
+  · Stream.I.Media no longer has Pending_Pause or Paused states
+  · The Ringing state has been renamed to Initialising to avoid confusion
+    with the Ringing flag
+  · Call1.AddContent takes an initial direction as its new last parameter
+  · Call_Flag_Locally_Muted has been removed and the other Call_Flags
+    have been renumbered
+  · Call_Member_Flag_Ringing has been removed and the other Call_Member_Flags
+    have been renumbered
+  · The destination of a forwarded call is published in the CallStateDetails,
+    rather than abusing the Actor member of CallStateReason
+
+• Connection.I.Addressing1 is now stable, and identical to
+  Connection.I.Addressing.DRAFT in 0.25.1 except for its name
+
+• Account.Supersedes has been added
+
+• Connection.I.ContactList.DownloadAtConnection has been added, together with
+  the Download method
+
+• A serialization has been defined for arrays of object path in .manager
+  files (and by extension, anything sharing that format)
+
+Clarifications:
+
+• Account.Service should also be used for IRC networks
+
+• Channel.I.DTMF.InitialTones should only be used in conjunction with
+  InitialAudio=TRUE
+
+• The policy for versioned interfaces is now documented
+
+Changes to experimental API:
+
+• Channel.I.Addressing1 is the new name for Channel.I.Addressing.DRAFT,
+  but is still considered experimental
+
+telepathy-spec 0.25.1 (2011-11-23)
+==================================
+
+The “farewell whiskey chess” release.
+
+API additions and clarifications:
+
+• Call1.Content.Interface.AudioControl is a wonderful new interface to
+  allow the connection manager to recommend volume changes during calls.
+
+• The various values of Socket_Access_Control have enjoyed some
+  clarification of their meanings on different tube types.
+
+• Protocol.Interface.Addressing has been undrafted, with NormalizeURI
+  renamed to NormalizeContactURI.
+
+• Connection.Interface.Addressing is still a draft, but its methods have
+  been changed to split the return values into two mappings.
+
+telepathy-spec 0.25.0 (2011-11-10)
+==================================
+
+API additions and clarifications:
+
+• Channel.Interface.FileTransfer.Metadata has been added.
+
+• Channel.Interface.Picture has been added.
+
+• "windows-live" has been added as a known account service name.
+
+• Channel.Interface.Subject: clarify default values for properties in
+  the unknown case.
+
+• RoomConfig: add a PasswordHint property which does what you think it
+  does.
+
+• Room: add Creator, CreatorHandle and CreationTimestamp properties.
+
+• Channel.Type.ContactList has been deprecated.
+
+telepathy-spec 0.24.0 (2011-10-10)
+==================================
+
+The “underestimating the future” release.  This is the start of a new
+stable branch of the Telepathy specification.
+
+Changes since 0.23.4:
+
+• Channel.Interface.Room has been undrafted, with a few changes:
+  · The RoomID property has become RoomName;
+  · The Subject property has been split off onto a separate interface,
+    Channel.Interface.Subject (which is also undrafted).
+
+• Channel.Interface.RoomConfig has been defined to replace the remaining
+  klunky Telepathy.Properties on Channel.Type.Text.
+
+• As a result, the Telepathy.Properties interface has been deprecated,
+  since all interfaces which historically used it now have better
+  replacements.
+
+Other notable changes since the 0.22 stable branch:
+
+• Most interfaces now provide both handles and identifiers for contacts.
+  This makes life easier for telepathy-glib and telepathy-qt4 (and, by
+  extension, application authors).
+
+• A new revision of the Call family of interfaces has landed. It is
+  still marked experimental.
+
+• ChannelDispatcher has a pair of new methods, DelegateChannels() and
+  PresentChannel(), to aid user interfaces where channels can be shown
+  in a number of places (like Gnome 3).
+
+• FileTransfer now has a URI property to indicate the on-disk location
+  of the file being sent or received.
+
+telepathy-spec 0.23.4 (2011-09-29)
+==================================
+
+API additions and clarifications:
+
+• Always give contact identifiers together with handles in
+  Channel.Interface.Group. This helps clients to create contact objects without
+  extra async operations. Additions are:
+    • Channel.Interface.Group.MemberIdentifiers;
+    • Channel.Interface.Group.SelfContactChanged; and
+    • Channel.Interface.Group.HandleOwnersChangedDetailed.
+
+• AccountManager: remove note about service activation. Mission Control is
+  service-activatable and is probably the only implementation we'll ever have.
+
+• Clarify possible errors returned by AM.CreateAccount.
+
+Spec HTML improvements:
+
+• Now <tp:value-ref> is used to reference a value in a enumeration.
+
+Call DRAFT2 landed
+
+• Call interfaces are now versioned. For example
+  org.freedesktop.Telepathy.Channel.Type.Call.DRAFT is now renamed to
+  org.freedesktop.Telepathy.Channel.Type.Call1.
+
+telepathy-spec 0.23.3 (2011-07-14)
+==================================
+
+API additions and clarifications:
+
+• The semantics of the 'supersedes' header in Messages have been clarified, and
+  'original-message-sent' and 'original-message-received' headers have been
+  defined to make the timestamps used for message edits unambiguous.
+  (fd.o#37413, David)
+
+• A tonne of properties on FileTransfer have been marked as requestable and/or
+  immutable. Also, as a clarification, the spec now explicitly says that
+  approvers may set the URI property, and that handlers MUST obey this.
+  (Xavier)
+
+• A new ChannelRequest hint, DelegateToPreferredHandler, has been added.
+  (fd.o#38240, Danni)
+
+Spec HTML improvements:
+
+• Jumping to anchors within the spec HTML will no longer move the text you're
+  looking for underneath the title bar with Webkit. Yay! (Danni (my heroine))
+
+• The generated HTML spec now has a beautiful favicon. (fd.o#38594, Guillaume)
+
+And for spec developers:
+
+• `make upload-branch` now takes an optional UPLOAD_BRANCH_TO Makefile
+  variable, which allows you to override the default server, namely
+  “people.freedesktop.org” (João Paulo Rechi Vita)
+
+telepathy-spec 0.23.2 (2011-05-16)
+==================================
+
+Changes to existing API
+-----------------------
+
+• ChannelDispatcher.DelegateChannels() now calls HandleChannels once per
+  Channel. It also returns the list of Channels which have been delegated
+  and those which have not. (fdo #37109, Guillaume)
+
+telepathy-spec 0.23.1 (2011-05-09)
+==================================
+
+This first release in the 0.23 development branch contains all the fixes and
+additions from 0.22.3.
+
+Enhancements:
+
+• Channel.Interface.SMS.GetSMSLength() to allow SMS message chunking to be
+  shown to the user. (Danni)
+
+• ChannelDispatcher.DelegateChannels() to move channels between handlers.
+  (fdo #25293, Guillaume)
+
+• ChannelDispatcher.PresentChannel(): convenient API to re-ensure an existing
+  channel. (fdo #25293, Guillaume)
+
+
+telepathy-spec 0.22.3 (2011-05-09)
+==================================
+
+Fixes:
+
+• Correct DBus_Property-parameter boilerplate. (fdo #37005, Will)
+
+telepathy-spec 0.22.2 (2011-04-20)
+==================================
+
+The “every cell stayed the same” release.
+
+Once again, this release in the stable series includes some minor API
+additions.
+
+Enhancements:
+
+• Channel.Interface.SMS now includes some sample contact capabilities.
+  (Danni)
+
+• Connection.Interface.Balance now has a ManageCreditURI property.
+  (fd.o#36254, Danni)
+
+• Connection.Interface.SimplePresence now has a
+  MaximumStatusMessageLength property. (fd.o#33054, André)
+
+• SimplePresence defines two new well-known status identifiers: "pstn"
+  and "chat". (fd.o#36159, Danni vs. Will)
+
+Fixes:
+
+• Protocol.Interface.Avatars properties are documented to be immutable.
+  (Guillaume)
+
+• The tables in SimplePresence and Call's HTML documentation look nicer.
+
+telepathy-spec 0.22.1 (2011-03-30)
+==================================
+
+The “we can change the things we know” release.
+
+Unconventionally, this release in the 0.22 stable series of the
+specification contains minor API additions. This is not intended to
+become a trend; once major changes land in the specification and a
+release is made in the 0.23.x unstable series, no new API will be added
+to the stable branch.
+
+• A new error code, InsufficientBalance, has been added, along with a
+  balance-required key for the CallStateDetails dictionary. (Danni)
+
+• Media.StreamHandler has grown two new method/signal pairs, namely
+  SetRemoteFeedbackMessages/SupportedFeedbackMessages and
+  SetRemoteHeaderExtensions/SupportedHeaderExtensions, plus some related
+  types, for enabling exciting RTP header extensions and RTCP feedback
+  messages.
+
+telepathy-spec 0.22.0 (2011-03-21)
+==================================
+
+The “literate small talk” release.
+
+This is a new stable version of telepathy-spec, intended to serve as a
+reference point for future work. There were no API changes since
+development release 0.21.13; significant additions and changes to
+non-DRAFT interfaces from the year-and-a-half of development since
+0.20.0 are summarized below.
+
+The versions of libraries, connection managers and Mission Control
+recommended for use with GNOME 3.0 (such as the upcoming telepathy-glib
+0.14) can be expected to support most of the API from this spec release.
+
+Changes to existing API
+-----------------------
+
+• Handles are no longer expected to be reference-counted - instead, they
+  persist as long as the Connection does. A new property,
+  HasImmortalHandles, indicates whether this is the case. Versions of
+  telepathy-glib since 0.13.8 implement these semantics, and set that
+  property, automatically for most connection managers.
+
+• message-token has been redefined from "globally unique"
+  to "whatever's in the underlying protocol", replacing the unimplemented
+  protocol-token. This makes it feasible to implement message-token again.
+  Note that connection managers implementing message-token should not be
+  backported to Maemo 5, since its event logger assumes that message-token
+  is guaranteed to be unique, which is usually unimplementable.
+
+• The Messages interface is now mandatory for Text channels.
+
+Enhancements to core API
+------------------------
+
+• The Connection has a pair of new methods, AddClientInterest and
+  RemoveClientInterest, to allow clients to subscribe to potentially
+  bandwidth-costly interfaces (such as MailNotification) in a generic
+  way.
+
+• ChannelDispatcher and ChannelRequest now support "request hints"
+  (metadata passed through from the requester to the handler), and the
+  SucceededWithChannel signal.
+
+New optional interfaces
+-----------------------
+
+• The ContactList and ContactGroups interfaces for
+  connections are now considered stable, and a new ContactBlocking
+  interface has been added. Between them, these interfaces replace
+  ContactList channels.
+
+• The Connection.Interface.ClientTypes,
+  Connection.Interface.MailNotification,
+  Connection.Interface.Powersaving, and Protocol.Interface.Presence
+  interfaces are now considered stable.
+
+• Chan.T.ServerAuthentication and Chan.I.SASLAuthentication provide
+  interactive querying for credentials, allowing connection without
+  saving a password if there is a handler for these channels
+
+• Chan.I.Securable indicates whether a channel is secure
+
+• Account.Interface.Addressing stores user preferences for use of
+  accounts for non-primary protocols, such as using SIP for telephony.
+
+Enhancements to optional interfaces
+-----------------------------------
+
+• Add a FileTransfer.URI property which can be used to tell other
+  Telepathy clients about the location of the transferred
+  file.
+
+Changes since 0.21.13
+---------------------
+
+• A server-message key for the Details dictionary in the ConnectionError
+  signal has been defined. (wjt)
diff --git a/README b/README
index a3d5dfbc..f44a0191 100644
--- a/README
+++ b/README
@@ -28,18 +28,11 @@ Report all errata, feature requests and "to-do" items here:
 API stability policy
 ====================
 
-We use an "odd/even" versioning scheme where the minor version (the y in
-x.y.z) determines stability - stable branches have y even, development
-branches have y odd.
+[Telepathy 1.0 has not yet been released, so this policy does not apply yet.]
 
-The following interfaces can change at any time, so please do not include them
-in libraries:
-
-* interfaces whose names end with .DRAFT or .FUTURE
-* interfaces with the tp:causes-havoc attribute
-
-Otherwise, we will not make the following changes in a stable branch, and we
-avoid them where possible even in development branches:
+The following changes are considered to be an API break, and will not be made
+in released interfaces unless the interface's name is also changed, usually by
+incrementing the version number at the end.
 
 * Removing or renaming methods, signals or properties
 * Changing the D-Bus type signature of a method or signal's arguments
@@ -47,10 +40,12 @@ avoid them where possible even in development branches:
   of a property
 * Removing or renaming types (tp:struct etc.)
 * Changing the D-Bus type signature of a type (tp:struct etc.)
+* Changing the name attribute of the <node> XML element
 
 We do *not* consider the following changes to be an API break, and reserve the
-right to make them at any time. Telepathy libraries/bindings should be done in
-a way that will not break if we do these:
+right to make them at any time, without changing the interface name.
+Telepathy libraries/bindings should be done in a way that will not break
+if we do these.
 
 * Adding new methods or properties
 * Adding new signals, if that does not make old connection managers (that will
@@ -67,46 +62,19 @@ a way that will not break if we do these:
 If any changes not mentioned here would break your library's API and you want
 us to avoid them, please ask for clarification on the mailing list.
 
-Policy on versioned interfaces
-==============================
-
-Some newer Telepathy interfaces have a version number, e.g. Subject2.
-These interfaces follow the following rules:
-
-If the interface has the tp:causes-havoc attribute, it is considered to be
-a draft. Incompatible changes will cause the version number to be
-incremented, but will not change the "node name" (the name attribute on the
-node XML element, used to name generated code) or the filename (which should
-always correspond to the node name). For instance, if Foo1 was never
-considered stable, then Foo1 and Foo2 would both have node name /Foo.
-Stable libraries should not expose these interfaces as API.
-
-If an interface with the tp:causes-havoc attribute is considered to be
-stable without further incompatible changes, that attribute will be removed,
-at which point that interface may be included in stable libraries as described
-below. Implementations of the last draft version and the final version will
-interoperate, since the interface name is the same; this is the
-version-numbering scheme's major advantage over the older convention of
-a .DRAFT suffix, in which case the last draft version could never interoperate
-with the final version despite being identical.
-
-If the interface does not have the tp:causes-havoc attribute, it is
-considered to be stable. Incompatible changes will not be made, and such
-interfaces can be included in a stable library, using the node name as
-the basis for code generation. For instance, Chan.I.Subject2 has node name
-/Channel_Interface_Subject, and generates code like
-TpSvcChannelInterfaceSubject in telepathy-glib.
-
-If a stable interface is found to require incompatible changes, it will be
-deprecated instead, and the incompatible changes will be made in a new copy
-of that interface with a higher version number. This time, the node name
-does have to include the version number, so that stable libraries which
-already committed to generating code for the old version can continue to
-do so, while also generating code for the new version. For instance,
-now that Chan.I.Subject2 is considered stable, if we make incompatible
-changes (leading to Chan.I.Subject3), the new version will have node name
-/Channel_Interface_Subject3, and hence generate code like
-TpSvcChannelInterfaceSubject3 in telepathy-glib.
+Core interfaces such as Channel, Connection and Account do not have a version
+number at the end. Incompatible changes to these interfaces will only be made
+in a new major version of telepathy-spec (which would rename all interfaces
+by replacing im.telepathy1 with im.telepathy2 throughout).
+
+The "node name" (name attribute of the <node> XML element) reflects the name
+and version of the interface, and the intended naming for generated code:
+for instance, <node name="/Channel_Interface_Subject1"> can generate
+functions, constants etc. whose names contain channel_interface_subject1,
+ChannelInterfaceSubject1, channelInterfaceSubject1 or
+CHANNEL_INTERFACE_SUBJECT1, as appropriate for the relevant language's naming
+conventions. The "node name" should always correspond to the filename of the
+XML.
 
 Contact info
 ============
diff --git a/doc/templates/interface.html b/doc/templates/interface.html
index 63a24bdf..a716d63b 100644
--- a/doc/templates/interface.html
+++ b/doc/templates/interface.html
@@ -19,14 +19,13 @@
    #if $interface.methods: | <a href="#methods">Methods</a>
    #if $interface.signals: | <a href="#signals">Signals</a>
    #if $interface.properties: | <a href="#properties">Properties</a>
-   #if $interface.tpproperties: | <a href="#tpproperties">Telepathy Properties</a>
    #if $interface.contact_attributes: | <a href="#contact-attributes">Contact Attributes</a>
    #if $interface.handler_capability_tokens: | <a href="#handler-capability-tokens">Handler Capability Tokens</a>
    #if $interface.types: | <a href="#types">Types</a>
   </div>
   <div class="main">
 
-    #if $interface.methods or $interface.signals or $interface.properties or $interface.types or $interface.tpproperties
+    #if $interface.methods or $interface.signals or $interface.properties or $interface.types
     <div class="summary">
      <a name="summary"></a>
      #if $interface.client_interests
@@ -101,21 +100,6 @@
     </table>
     #end if
 
-     #if $interface.tpproperties
-     <h3>Telepathy Properties</h3>
-     <table class="summary">
-      #for $property in $interface.tpproperties
-       <tr class="deprecated">
-       <td><a href="$property.get_url()">$property.short_name</a></td>
-       <td>
-        $property.dbus_type
-        #if $property.type: (<a href="$property.get_type_url()" title="$property.get_type_title()">$property.get_type().short_name</a>)
-       </td>
-      </tr>
-      #end for
-    </table>
-    #end if
-
      #if $interface.contact_attributes
      <h3>Contact Attributes</h3>
      <table class="summary">
@@ -210,8 +194,8 @@
     <h1>Client Interests</h1>
     <div>
      Set using the
-     <a href="Connection.html#org.freedesktop.Telepathy.Connection.AddClientInterest">AddClientInterest</a> and
-     <a href="Connection.html#org.freedesktop.Telepathy.Connection.RemoveClientInterest">RemoveClientInterest</a> methods.
+     <a href="Connection.html#im.telepathy1.Connection.AddClientInterest">AddClientInterest</a> and
+     <a href="Connection.html#im.telepathy1.Connection.RemoveClientInterest">RemoveClientInterest</a> methods.
     </div>
     #for $interest in $interface.client_interests
     <div class="inset client-interest">
@@ -364,7 +348,7 @@
        #if $interface.is_channel_related:
        change once the channel has been created. Immutable properties SHOULD
        appear in the channel detail list
-       of <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.NewChannels">NewChannels</a>
+       of <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.NewChannels">NewChannels</a>
        signals.
        #else
        change.
@@ -376,7 +360,7 @@
        #if $interface.is_channel_related:
        change once the channel has been created. Immutable properties SHOULD
        appear in the channel detail list
-       of <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.NewChannels">NewChannels</a>
+       of <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.NewChannels">NewChannels</a>
        signals.
        #else
        change.
@@ -388,29 +372,29 @@
      <div class="annotation requestable">Depending on the protocol, this
        property may be <strong>requestable</strong>, which means that it may be
        allowed in the properties hash of a channel request such as in the
-       <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.CreateChannel">CreateChannel</a>
+       <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.CreateChannel">CreateChannel</a>
        and
-       <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.EnsureChannel">EnsureChannel</a>
+       <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.EnsureChannel">EnsureChannel</a>
        methods
        on <a href="Connection_Interface_Requests.html">Requests</a>
        and <a href="Channel_Dispatcher.html">ChannelDispatcher</a>.
        If supported on this protocol, the property should appear in either the
        Fixed_Properties or Allowed_Properties of
-       a <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.RequestableChannelClasses">RequestableChannelClass</a>
+       a <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.RequestableChannelClasses">RequestableChannelClass</a>
        advertised by the CM.</div>
      #elif $property.requestable:
      <div class="annotation requestable">This property
        is <strong>requestable</strong>, which means that it is allowed
        in the properties hash of a channel request such as in the
-       <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.CreateChannel">CreateChannel</a>
+       <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.CreateChannel">CreateChannel</a>
        and 
-       <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.EnsureChannel">EnsureChannel</a>
+       <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.EnsureChannel">EnsureChannel</a>
        methods
        on <a href="Connection_Interface_Requests.html">Requests</a>
        and <a href="Channel_Dispatcher.html">ChannelDispatcher</a>.
        The property should also appear in either the Fixed_Properties
        or Allowed_Properties of
-       a <a href="Connection_Interface_Requests.html#org.freedesktop.Telepathy.Connection.Interface.Requests.RequestableChannelClasses">RequestableChannelClass</a>
+       a <a href="Connection_Interface_Requests.html#im.telepathy1.Connection.Interface.Requests.RequestableChannelClasses">RequestableChannelClass</a>
        advertised by the CM.</div>
      #end if
 
@@ -447,10 +431,10 @@
           href="Connection_Manager.html#Conn_Mgr_Param_Flags">DBus_Property</a>
           flag. Clients SHOULD update this property by
           calling <a
-            href="Account.html#org.freedesktop.Telepathy.Account.UpdateParameters">UpdateParameters</a>
+            href="Account.html#im.telepathy1.Account.UpdateParameters">UpdateParameters</a>
           on the relevant <a href="Account.html">Account</a> rather than
           setting the property directly; change notification is via <a
-            href="Account.html#org.freedesktop.Telepathy.Account.AccountPropertyChanged">AccountPropertyChanged</a>.
+            href="Account.html#im.telepathy1.Account.AccountPropertyChanged">AccountPropertyChanged</a>.
           </p>
       </div>
       #end if
@@ -461,39 +445,13 @@
    </div>
    #end if
 
-   #if $interface.tpproperties
-   <div class="outset tpproperties tpproperty">
-    <a name="tpproperties"></a>
-    <h1>Telepathy Properties</h1>
-    <div>
-     Accessed using the <a
-       href="Properties_Interface.html">org.freedesktop.Telepathy.Properties</a>
-     interface.
-    </div>
-    #for $property in $interface.tpproperties
-    <div class="inset tpproperty">
-     <a name="$property.get_anchor()"></a>
-     <span class="permalink">(<a href="$property.get_url()">Permalink</a>)</span>
-     <h2>
-      $property.short_name &mdash; $property.dbus_type
-      #if $property.type: (<a href="$property.get_type_url()" title="$property.get_type_title()">$property.get_type().short_name</a>)
-     </h2>
-     $property.get_added()
-     $property.get_changed()
-     $property.get_deprecated()
-     $property.get_docstring()
-    </div>
-    #end for
-   </div>
-   #end if
-
    #if $interface.contact_attributes
    <div class="outset contact-attributes">
     <a name="contact-attributes"></a>
     <h1>Contact Attributes</h1>
     <div>
       Attributes that a contact can have, accessed with the
-      org.freedesktop.Telepathy.Connection.Interface.Contacts interface.
+      im.telepathy1.Connection.Interface.Contacts interface.
     </div>
     #for $token in $interface.contact_attributes
     <div class="inset contact-attribute">
diff --git a/doc/templates/style.css b/doc/templates/style.css
index 45ce833f..c22cc51a 100644
--- a/doc/templates/style.css
+++ b/doc/templates/style.css
@@ -95,10 +95,6 @@ div.property {
 	border: 1px solid #75507b;
 }
 
-div.tpproperties {
-	background-color: #999999;
-}
-
 div.tpproperty {
 	border: 1px solid #333333;
 }
diff --git a/spec/Account.xml b/spec/Account.xml
index fff0232d..0df5b0b6 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -19,25 +19,25 @@ 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 name="im.telepathy1.Account">
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An Account object encapsulates the necessary details to make a
         Telepathy connection.</p>
 
       <p>Accounts are uniquely identified by object path. The object path
         of an Account MUST take the form
-        <code>/org/freedesktop/Telepathy/Account/<em>cm</em>/<em>proto</em>/<em>acct</em></code>, where:</p>
+        <code>/im/telepathy1/Account/<em>cm</em>/<em>proto</em>/<em>acct</em></code>, where:</p>
 
       <ul>
         <li><em>cm</em> is the same <tp:type>Connection_Manager_Name</tp:type>
           that appears in the connection manager's well-known bus name and
           object path</li>
-        <li><em>proto</em> is the <tp:type>Protocol</tp:type> name as seen in
+        <li><em>proto</em> is the <tp:type>Protocol_Name</tp:type> as seen in
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ConnectionManager.ListProtocols</tp:dbus-ref>,
+          namespace="im.telepathy1">ConnectionManager.Protocols</tp:dbus-ref>,
           but with "-" replaced with "_"
           (i.e. the same as in the object-path of a <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>)</li>
+          namespace="im.telepathy1">Connection</tp:dbus-ref>)</li>
         <li><em>acct</em> is an arbitrary string of ASCII letters, digits
           and underscores, starting with a letter or underscore, which
           uniquely identifies this account</li>
@@ -117,7 +117,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <method name="Remove" tp:name-for-bindings="Remove">
       <tp:docstring>Delete the account.</tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
@@ -127,7 +127,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <tp:rationale>
           This is redundant with <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.AccountManager">AccountRemoved</tp:dbus-ref>,
+          namespace="im.telepathy1.AccountManager">AccountRemoved</tp:dbus-ref>,
           but it's still worth having,
           to avoid having to bind to AccountManager.AccountRemoved to tell
           you whether your Account is valid — ideally, an account-editing UI
@@ -175,7 +175,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
-    <property name="Valid" tp:name-for-bindings="Valid"
+    <property name="Usable" tp:name-for-bindings="Usable"
       type="b" access="read">
       <tp:docstring>
         If true, this account is considered by the account manager to be
@@ -235,7 +235,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         The nickname to set on this account for display to other contacts,
         as set by the user. When the account becomes connected, the
         account manager SHOULD set this as the user's alias using <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing">SetAliases</tp:dbus-ref>
+        namespace="im.telepathy1.Connection.Interface.Aliasing1">SetAliases</tp:dbus-ref>
         if appropriate.
 
         <tp:rationale>
@@ -256,23 +256,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           user-recognised brands, such as <i>Google Talk</i> and <i>Ovi by
           Nokia</i>. On accounts for such services, this property SHOULD be
           set to a string describing the service, which MUST consist only of
-          ASCII letters, numbers and hyphen/minus signs, and start with a
-          letter (matching the requirements for <tp:type>Protocol</tp:type>).
+          ASCII letters, numbers and underscores, and start with a
+          letter (matching the requirements for
+          <tp:type>Protocol_Name</tp:type>).
           For the <tt>jabber</tt> protocol, one of the following service names
           should be used if possible:</p>
 
         <ul>
-          <li><tt>google-talk</tt> (for <a
+          <li><tt>google_talk</tt> (for <a
             href="http://www.google.com/talk/">Google's IM service</a>)</li>
-          <li><tt>ovi-chat</tt> (for <a href="http://www.ovi.com/">Ovi</a>'s IM
+          <li><tt>ovi_chat</tt> (for <a href="http://www.ovi.com/">Ovi</a>'s IM
             service)</li>
           <li><tt>facebook</tt> (for <a
             href="http://www.facebook.com/sitetour/chat.php">Facebook's IM
             service</a>)</li>
-          <li><tt>lj-talk</tt> (for <a
+          <li><tt>lj_talk</tt> (for <a
             href="http://www.livejournal.com/chat/">LiveJournal's IM
             service</a>)</li>
-          <li><tt>windows-live</tt> (for <a
+          <li><tt>windows_live</tt> (for <a
             href="http://live.com">Windows Live Messenger IM service</a>)</li>
 
         </ul>
@@ -291,10 +292,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <p>This property MAY be set, if appropriate, when calling
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.AccountManager"
+            namespace="im.telepathy1.AccountManager"
             >CreateAccount</tp:dbus-ref>. Updating this property will fail on
           externally-stored accounts whose <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account.Interface.Storage"
+            namespace="im.telepathy1.Account.Interface.Storage1"
             >StorageRestrictions</tp:dbus-ref> include
           <code>Cannot_Set_Service</code>.</p>
       </tp:docstring>
@@ -305,7 +306,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A map from connection manager parameter names (as in the
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ConnectionManager</tp:dbus-ref>
+          namespace="im.telepathy1">ConnectionManager</tp:dbus-ref>
           interface) to their values. This property includes
           only those parameters that are stored for this account, and SHOULD
           only include those parameters that the user has explicitly set.
@@ -379,7 +380,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             the empty list, signifying that no reconnection is required for the
             new parameters to take effect. For example, if the only parameter
             updated is <tt>...Cellular.<tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Cellular">MessageValidityPeriod</tp:dbus-ref></tt>,
+              namespace="im.telepathy1.Connection.Interface.Cellular1">MessageValidityPeriod</tp:dbus-ref></tt>,
             the new value can be applied immediately to the connection.</p>
 
           <p>Otherwise, a list of the names of parameters with changes that
@@ -388,7 +389,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             <tp:member-ref>Reconnect</tp:member-ref> in response to receiving a
             non-empty list. For example, if the caller updates both
             <tt>...Anonymity.<tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Anonymity">AnonymityMandatory</tp:dbus-ref></tt>
+              namespace="im.telepathy1.Connection.Interface.Anonymity1">AnonymityMandatory</tp:dbus-ref></tt>
             and <tt>require-encryption</tt>, the former can be applied to the
             current connection, but the latter needs a reconnect to take
             effect, so this method should return
@@ -397,13 +398,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
 
     <property name="AutomaticPresence" type="(uss)" access="readwrite"
-      tp:type="Simple_Presence" tp:name-for-bindings="Automatic_Presence">
+      tp:type="Presence" tp:name-for-bindings="Automatic_Presence">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The presence status that this account should have if it is brought
           online.</p>
@@ -449,7 +450,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       type="o" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Either the object path of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref> to
+          namespace="im.telepathy1">Connection</tp:dbus-ref> to
         this account, or the special value <code>'/'</code> if there is no
         connection.</p>
 
@@ -506,9 +507,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>If the last connection to this account failed with an error,
           the D-Bus error name of that error; otherwise, the empty string.
           The account manager is expected to set this by observing the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Connection.ConnectionError</tp:dbus-ref> and
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Connection.StatusChanged</tp:dbus-ref>
           signals.</p>
 
@@ -537,7 +538,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           a mapping representing 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="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Connection.ConnectionError</tp:dbus-ref>.</p>
 
         <p>Whenever the Connection connects successfully, this property should
@@ -552,13 +553,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </property>
 
     <property name="CurrentPresence" type="(uss)" access="read"
-      tp:type="Simple_Presence" tp:name-for-bindings="Current_Presence">
+      tp:type="Presence" tp:name-for-bindings="Current_Presence">
       <tp:docstring>
         The actual presence. If the connection is not online, the
         <tp:type>Connection_Presence_Type</tp:type> SHOULD be
         Connection_Presence_Type_Offline.
         If the connection is online but does not support the <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
+        namespace="im.telepathy1.Connection.Interface">Presence1</tp:dbus-ref>
         interface, the type SHOULD be Connection_Presence_Type_Unset.
         The account manager is expected to set this by observing signals
         from the Connection.
@@ -566,7 +567,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </property>
 
     <property name="RequestedPresence" type="(uss)" access="readwrite"
-      tp:type="Simple_Presence" tp:name-for-bindings="Requested_Presence">
+      tp:type="Presence" tp:name-for-bindings="Requested_Presence">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The requested presence for this account. When this is changed, the
         account manager should attempt to manipulate the connection manager to
@@ -599,7 +600,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         non-offline <tp:member-ref>RequestedPresence</tp:member-ref> becomes
         able to go online (for instance because
         <tp:member-ref>Enabled</tp:member-ref> or
-        <tp:member-ref>Valid</tp:member-ref> changes to True),
+        <tp:member-ref>Usable</tp:member-ref> changes to True),
         ChangingPresence MUST change to True, and the two property changes MUST
         be emitted in the same
         <tp:member-ref>AccountPropertyChanged</tp:member-ref> signal, before the
@@ -632,7 +633,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>Re-connect this account. If the account is currently disconnected
           and the requested presence is offline, or if the account
           is not <tp:member-ref>Enabled</tp:member-ref> or not
-          <tp:member-ref>Valid</tp:member-ref>, this does nothing.</p>
+          <tp:member-ref>Usable</tp:member-ref>, this does nothing.</p>
 
         <p>If the account is disconnected and the requested presence is not
           offline, this forces an attempt to connect with the requested
@@ -666,12 +667,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       tp:name-for-bindings="Normalized_Name">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The normalized user ID of the local user on this account (i.e. the
-          string returned when the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>
-          method is called on the
-          result of <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection">GetSelfHandle</tp:dbus-ref>
-          for an active connection).</p>
+          value of the <tp:dbus-ref
+          namespace="im.telepathy1.Connection">SelfID</tp:dbus-ref>
+          property for an active connection).</p>
 
         <p>It is unspecified whether this user ID is globally unique.</p>
 
@@ -735,7 +733,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           automatically, it SHOULD set this property. If a client performs
           an account migration, it SHOULD set this property via
           via the Properties argument of <tp:dbus-ref
-            namespace="ofdT.AccountManager">CreateAccount</tp:dbus-ref>
+            namespace="imt1.AccountManager">CreateAccount</tp:dbus-ref>
           when creating the migrated account. In either case, the value
           SHOULD include the old account's path, and every path from
           the old account's Supersedes property.</p>
diff --git a/spec/Account_Interface_Addressing.xml b/spec/Account_Interface_Addressing1.xml
index 1692ba78..a0894ab6 100644
--- a/spec/Account_Interface_Addressing.xml
+++ b/spec/Account_Interface_Addressing1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Interface_Addressing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Account_Interface_Addressing1" 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
@@ -16,8 +16,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Account.Interface.Addressing">
-    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+  <interface name="im.telepathy1.Account.Interface.Addressing1">
+    <tp:requires interface="im.telepathy1.Account"/>
     <tp:added version="0.21.5">(as stable API)</tp:added>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
                 value="true"/>
diff --git a/spec/Account_Interface_Avatar.xml b/spec/Account_Interface_Avatar1.xml
index a6c51672..db77838e 100644
--- a/spec/Account_Interface_Avatar.xml
+++ b/spec/Account_Interface_Avatar1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Interface_Avatar"
+<node name="/Account_Interface_Avatar1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
@@ -19,8 +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.Account.Interface.Avatar">
-    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+  <interface name="im.telepathy1.Account.Interface.Avatar1">
+    <tp:requires interface="im.telepathy1.Account"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface extends the core Account interface to provide a
diff --git a/spec/Account_Interface_External_Password_Storage.xml b/spec/Account_Interface_External_Password_Storage1.xml
index 5bd1bfce..cfa07fa4 100644
--- a/spec/Account_Interface_External_Password_Storage.xml
+++ b/spec/Account_Interface_External_Password_Storage1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Interface_External_Password_Storage"
+<node name="/Account_Interface_External_Password_Storage1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2011 Collabora Ltd.</tp:copyright>
@@ -20,21 +20,21 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Account.Interface.ExternalPasswordStorage.DRAFT"
+  <interface name="im.telepathy1.Account.Interface.ExternalPasswordStorage1"
     tp:causes-havoc="experimental">
     <tp:added version="0.21.10">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+    <tp:requires interface="im.telepathy1.Account"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for Accounts whose passwords are stored externally and
         SHOULD NOT be stored by either the
-        <tp:dbus-ref namespace="ofdT">AccountManager</tp:dbus-ref> nor any
-        <tp:dbus-ref namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1">AccountManager</tp:dbus-ref> nor any
+        <tp:dbus-ref namespace="imt1.Channel.Type">ServerAuthentication1</tp:dbus-ref>
         handler.</p>
 
       <p>This interface SHOULD only appear on accounts for which the
         related Connection Manager implements
-        <tp:dbus-ref namespace="ofdT">ConnectionManager.Interface.AccountStorage.DRAFT</tp:dbus-ref>.</p>
+        <tp:dbus-ref namespace="imt1">ConnectionManager.Interface.AccountStorage1</tp:dbus-ref>.</p>
     </tp:docstring>
 
     <method name="ForgetPassword" tp:name-for-bindings="Forget_Password">
diff --git a/spec/Account_Interface_Hidden.xml b/spec/Account_Interface_Hidden1.xml
index cb001917..a7863605 100644
--- a/spec/Account_Interface_Hidden.xml
+++ b/spec/Account_Interface_Hidden1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Interface_Hidden"
+<node name="/Account_Interface_Hidden1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Account.Interface.Hidden.DRAFT1"
+  <interface name="im.telepathy1.Account.Interface.Hidden1"
     tp:causes-havoc="outrageous">
     <tp:added version="0.21.10">(draft 1)</tp:added>
 
@@ -30,7 +30,7 @@
         Accounts whose <tp:member-ref>Hidden</tp:member-ref> property is
         <code>True</code> are intended for non-interactive use (by
         non-user-visible services), and appear on the <tp:dbus-ref
-          namespace='ofdT'>AccountManager.Interface.Hidden.DRAFT1</tp:dbus-ref>
+          namespace='imt1'>AccountManager.Interface.Hidden1</tp:dbus-ref>
         interface; in all other respects, they behave like any other
         account.</p>
 
@@ -54,9 +54,9 @@
         <p>If <code>True</code>, this account is intended for non-interactive
           use, and thus should not be presented to the user. It will not appear
           in properties and signals on the main <tp:dbus-ref
-            namespace='ofdT'>AccountManager</tp:dbus-ref> interface; instead, it
+            namespace='imt1'>AccountManager</tp:dbus-ref> interface; instead, it
           will show up on <tp:dbus-ref
-            namespace='ofdT'>AccountManager.Interface.Hidden.DRAFT1</tp:dbus-ref>.</p>
+            namespace='imt1'>AccountManager.Interface.Hidden1</tp:dbus-ref>.</p>
       </tp:docstring>
     </property>
 
diff --git a/spec/Account_Interface_Storage.xml b/spec/Account_Interface_Storage1.xml
index 4e3ba5dc..8a4809e7 100644
--- a/spec/Account_Interface_Storage.xml
+++ b/spec/Account_Interface_Storage1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Interface_Storage"
+<node name="/Account_Interface_Storage1"
   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">
@@ -18,8 +18,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.Account.Interface.Storage">
-    <tp:requires interface="org.freedesktop.Telepathy.Account"/>
+  <interface name="im.telepathy1.Account.Interface.Storage1">
+    <tp:requires interface="im.telepathy1.Account"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>
@@ -130,9 +130,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Cannot_Set_Parameters" value="1">
         <tp:docstring>
           The account's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account"
+            namespace="im.telepathy1.Account"
             >Parameters</tp:dbus-ref> property can't be changed by calling
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Account"
+          <tp:dbus-ref namespace="im.telepathy1.Account"
             >UpdateParameters</tp:dbus-ref>.
         </tp:docstring>
       </tp:flag>
@@ -140,7 +140,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Cannot_Set_Enabled" value="2">
         <tp:docstring>
           The account can't be enabled/disabled by setting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account"
+            namespace="im.telepathy1.Account"
             >Enabled</tp:dbus-ref> property.
         </tp:docstring>
       </tp:flag>
@@ -148,9 +148,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Cannot_Set_Presence" value="4">
         <tp:docstring>
           The account's presence can't be changed by setting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account"
+            namespace="im.telepathy1.Account"
             >RequestedPresence</tp:dbus-ref> and <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account"
+            namespace="im.telepathy1.Account"
             >AutomaticPresence</tp:dbus-ref> properties.
         </tp:docstring>
       </tp:flag>
@@ -158,7 +158,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Cannot_Set_Service" value="8">
         <tp:docstring>
           The account's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account">Service</tp:dbus-ref>
+            namespace="im.telepathy1.Account">Service</tp:dbus-ref>
           property cannot be changed.
         </tp:docstring>
       </tp:flag>
diff --git a/spec/Account_Manager.xml b/spec/Account_Manager.xml
index defa074f..7a281951 100644
--- a/spec/Account_Manager.xml
+++ b/spec/Account_Manager.xml
@@ -19,15 +19,15 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 </p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.AccountManager">
+  <interface name="im.telepathy1.AccountManager">
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>The account manager is a central service used to store account
         details.</p>
 
       <p>The current account manager is defined to be the process that owns
-        the well-known bus name <tt>org.freedesktop.Telepathy.AccountManager</tt> on
+        the well-known bus name <tt>im.telepathy1.AccountManager</tt> on
         the session bus. This process must export an
-        <tt>/org/freedesktop/Telepathy/AccountManager</tt> object with the
+        <tt>/im/telepathy1/AccountManager</tt> object with the
         AccountManager interface.</p>
     </tp:docstring>
     <tp:added version="0.17.2"/>
@@ -50,13 +50,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
-    <property name="ValidAccounts" type="ao" access="read"
-      tp:name-for-bindings="Valid_Accounts">
+    <property name="UsableAccounts" type="ao" access="read"
+      tp:name-for-bindings="Usable_Accounts">
       <tp:docstring>
         A list of the valid (complete, usable) <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>s. Change
+          namespace="im.telepathy1">Account</tp:dbus-ref>s. Change
         notification is via
-        <tp:member-ref>AccountValidityChanged</tp:member-ref>.
+        <tp:member-ref>AccountUsabilityChanged</tp:member-ref>.
 
         <tp:rationale>
           This split between valid and invalid accounts makes it easy to
@@ -67,13 +67,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
-    <property name="InvalidAccounts" type="ao" access="read"
-      tp:name-for-bindings="Invalid_Accounts">
+    <property name="UnusableAccounts" type="ao" access="read"
+      tp:name-for-bindings="Unusable_Accounts">
       <tp:docstring>
         A list of incomplete or otherwise unusable <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>s. Change
+          namespace="im.telepathy1">Account</tp:dbus-ref>s. Change
         notification is via
-        <tp:member-ref>AccountValidityChanged</tp:member-ref>.
+        <tp:member-ref>AccountUsabilityChanged</tp:member-ref>.
       </tp:docstring>
     </property>
 
@@ -95,8 +95,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
     </signal>
 
-    <signal name="AccountValidityChanged"
-      tp:name-for-bindings="Account_Validity_Changed">
+    <signal name="AccountUsabilityChanged"
+      tp:name-for-bindings="Account_Usability_Changed">
       <tp:docstring>
         The validity of the given account has changed. New accounts are
         also indicated by this signal, as an account validity change
@@ -111,11 +111,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <arg name="Account" type="o">
         <tp:docstring>
           An <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>.
+            namespace="im.telepathy1">Account</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
-      <arg name="Valid" type="b">
+      <arg name="Usable" type="b">
         <tp:docstring>
           True if the account is now valid.
         </tp:docstring>
@@ -135,45 +135,45 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:rationale>
           <p>Examples of good properties to support here include
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Icon</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">Icon</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Enabled</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">Enabled</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Nickname</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">Nickname</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">AutomaticPresence</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">AutomaticPresence</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">ConnectAutomatically</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">ConnectAutomatically</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="ofdT.Account">Supersedes</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">RequestedPresence</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">RequestedPresence</tp:dbus-ref>
+              namespace="imt1.Account">Supersedes</tp:dbus-ref>
             and
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account.Interface.Avatar">Avatar</tp:dbus-ref>.
+              namespace="im.telepathy1.Account.Interface.Avatar1">Avatar</tp:dbus-ref>.
             </p>
 
           <p>Examples of properties that would make no sense here include
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Valid</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">Usable</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Connection</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">Connection</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">ConnectionStatus</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">ConnectionStatus</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">ConnectionStatusReason</tp:dbus-ref>,
+              namespace="im.telepathy1.Account">ConnectionStatusReason</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">CurrentPresence</tp:dbus-ref>
+              namespace="im.telepathy1.Account">CurrentPresence</tp:dbus-ref>
             and
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">NormalizedName</tp:dbus-ref>.
+              namespace="im.telepathy1.Account">NormalizedName</tp:dbus-ref>.
           </p>
         </tp:rationale>
 
         <p>This property MUST NOT include include the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account">DisplayName</tp:dbus-ref>
+            namespace="im.telepathy1.Account">DisplayName</tp:dbus-ref>
           and <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account">Parameters</tp:dbus-ref>
+            namespace="im.telepathy1.Account">Parameters</tp:dbus-ref>
           properties, which are set using separate arguments.</p>
 
         <p>This property MAY include the names of properties that, after
@@ -183,7 +183,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:rationale>
           <p>For example, an account manager might support migration tools that
             use this to preserve the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">HasBeenOnline</tp:dbus-ref>
+              namespace="im.telepathy1.Account">HasBeenOnline</tp:dbus-ref>
             property, even though that property is usually read-only.</p>
         </tp:rationale>
       </tp:docstring>
@@ -192,7 +192,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <method name="CreateAccount" tp:name-for-bindings="Create_Account">
       <tp:docstring>
         Request the creation of a new <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>. The
+          namespace="im.telepathy1">Account</tp:dbus-ref>. The
         account manager SHOULD NOT allow invalid accounts to be created.
       </tp:docstring>
       <tp:changed version="0.17.24">added the Properties argument</tp:changed>
@@ -205,13 +205,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
 
       <arg name="Protocol" direction="in" type="s"
-        tp:type="Protocol">
+        tp:type="Protocol_Name">
         <tp:docstring>The protocol, e.g. "local-xmpp".</tp:docstring>
       </arg>
 
       <arg name="Display_Name" direction="in" type="s">
         <tp:docstring>The initial value of the new account's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account">DisplayName</tp:dbus-ref>
+            namespace="im.telepathy1.Account">DisplayName</tp:dbus-ref>
           property. The account manager SHOULD modify this to make it unique if
           an Account already exists with the same display name, for instance by
           appending a number or the 'account' parameter. Account manager
@@ -237,7 +237,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <arg name="Parameters" direction="in" type="a{sv}">
         <tp:docstring>Initial parameter values, as would be passed to
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ConnectionManager">RequestConnection</tp:dbus-ref>.</tp:docstring>
+            namespace="im.telepathy1.ConnectionManager">RequestConnection</tp:dbus-ref>.</tp:docstring>
       </arg>
 
       <arg name="Properties" direction="in" type="a{sv}"
@@ -249,9 +249,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <p>Only the properties mentioned in
             <tp:member-ref>SupportedAccountProperties</tp:member-ref> are
             acceptable here. In particular, the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">DisplayName</tp:dbus-ref>
+              namespace="im.telepathy1.Account">DisplayName</tp:dbus-ref>
             and <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Parameters</tp:dbus-ref>
+              namespace="im.telepathy1.Account">Parameters</tp:dbus-ref>
             properties are never allowed here, since they are set using the other
             arguments to this method.</p>
 
@@ -262,17 +262,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <arg name="Account" direction="out" type="o">
         <tp:docstring>The new <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>.</tp:docstring>
+          namespace="im.telepathy1">Account</tp:dbus-ref>.</tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             <p>The <var>Connection_Manager</var> is not installed or does not
               implement the given <var>Protocol</var>.</p>
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             <p>The <var>Parameters</var> provided were unacceptable: they might
               omit a
diff --git a/spec/Account_Manager_Interface_Hidden.xml b/spec/Account_Manager_Interface_Hidden1.xml
index 284eb642..2a4d32e8 100644
--- a/spec/Account_Manager_Interface_Hidden.xml
+++ b/spec/Account_Manager_Interface_Hidden1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Account_Manager_Interface_Hidden"
+<node name="/Account_Manager_Interface_Hidden1"
   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>
@@ -20,36 +20,36 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 </p>
   </tp:license>
   <interface
-      name="org.freedesktop.Telepathy.AccountManager.Interface.Hidden.DRAFT1"
+      name="im.telepathy1.AccountManager.Interface.Hidden1"
       tp:causes-havoc='kind of sketchy'>
-    <tp:requires interface='org.freedesktop.Telepathy.AccountManager'/>
+    <tp:requires interface='im.telepathy1.AccountManager'/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface lists accounts whose <tp:dbus-ref
-        namespace='ofdT.Account.Interface.Hidden.DRAFT1'>Hidden</tp:dbus-ref>
+        namespace='imt1.Account.Interface.Hidden1'>Hidden</tp:dbus-ref>
         property is <code>True</code>.</p>
     </tp:docstring>
     <tp:added version="0.21.10">first draft</tp:added>
 
-    <property name="ValidHiddenAccounts" type="ao" access="read"
-      tp:name-for-bindings="Valid_Hidden_Accounts">
+    <property name="UsableHiddenAccounts" type="ao" access="read"
+      tp:name-for-bindings="Usable_Hidden_Accounts">
       <tp:docstring>
         A list of valid (complete, usable) <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>s intended
+          namespace="im.telepathy1">Account</tp:dbus-ref>s intended
         exclusively for noninteractive applications. These accounts are not
         included in <tp:dbus-ref
-          namespace='ofdT'>AccountManager.ValidAccounts</tp:dbus-ref>.  Change
+          namespace='imt1'>AccountManager.UsableAccounts</tp:dbus-ref>.  Change
           notification is via
-        <tp:member-ref>HiddenAccountValidityChanged</tp:member-ref>.
+        <tp:member-ref>HiddenAccountUsabilityChanged</tp:member-ref>.
       </tp:docstring>
     </property>
 
-    <property name="InvalidHiddenAccounts" type="ao" access="read"
-      tp:name-for-bindings="Invalid_Hidden_Accounts">
+    <property name="UnusableHiddenAccounts" type="ao" access="read"
+      tp:name-for-bindings="Unusable_Hidden_Accounts">
       <tp:docstring>
         A list of incomplete or otherwise unusable <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>s intended
+          namespace="im.telepathy1">Account</tp:dbus-ref>s intended
         exclusively for noninteractive applications. Change notification is via
-        <tp:member-ref>HiddenAccountValidityChanged</tp:member-ref>.
+        <tp:member-ref>HiddenAccountUsabilityChanged</tp:member-ref>.
       </tp:docstring>
     </property>
 
@@ -57,8 +57,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       tp:name-for-bindings="Hidden_Account_Removed">
       <tp:docstring>
         The given account has been removed from
-        <tp:member-ref>ValidHiddenAccounts</tp:member-ref> or
-        <tp:member-ref>InvalidHiddenAccounts</tp:member-ref>.
+        <tp:member-ref>UsableHiddenAccounts</tp:member-ref> or
+        <tp:member-ref>UnusableHiddenAccounts</tp:member-ref>.
       </tp:docstring>
 
       <arg name="Account" type="o">
@@ -68,8 +68,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
     </signal>
 
-    <signal name="HiddenAccountValidityChanged"
-      tp:name-for-bindings="Hidden_Account_Validity_Changed">
+    <signal name="HiddenAccountUsabilityChanged"
+      tp:name-for-bindings="Hidden_Account_Usability_Changed">
       <tp:docstring>
         The validity of the given account has changed. New magic
         accounts are also indicated by this signal, as an account validity
@@ -84,11 +84,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <arg name="Account" type="o">
         <tp:docstring>
           An <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>.
+            namespace="im.telepathy1">Account</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
-      <arg name="Valid" type="b">
+      <arg name="Usable" type="b">
         <tp:docstring>
           True if the account is now valid.
         </tp:docstring>
diff --git a/spec/Authentication_TLS_Certificate.xml b/spec/Authentication_TLS_Certificate.xml
index db1d76fd..79098f93 100644
--- a/spec/Authentication_TLS_Certificate.xml
+++ b/spec/Authentication_TLS_Certificate.xml
@@ -17,7 +17,7 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Authentication.TLSCertificate">
+  <interface name="im.telepathy1.Authentication.TLSCertificate">
     <tp:added version="0.19.13">(as stable API)</tp:added>
 
     <tp:docstring>
@@ -114,7 +114,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <tp:enum type="u" name="TLS_Certificate_State">
       <tp:docstring>
         The possible states for a <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
+        namespace="im.telepathy1.Authentication">TLSCertificate</tp:dbus-ref>
         object.
       </tp:docstring>
 
@@ -291,7 +291,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             Raised when the method is called on an object whose <tp:member-ref>State</tp:member-ref>
             is not <code>Pending</code>, or when the provided rejection list is empty.
diff --git a/spec/Call_Content.xml b/spec/Call1_Content.xml
index be3376fe..1926e491 100644
--- a/spec/Call_Content.xml
+++ b/spec/Call1_Content.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content"
+<node name="/Call1_Content"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,15 +20,15 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content">
+  <interface name="im.telepathy1.Call1.Content">
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This object represents one Content inside a <tp:dbus-ref
-      namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>. For
+      namespace="imt1.Channel.Type">Call1</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.Call1">Stream</tp:dbus-ref> objects which
+      namespace="imt1.Call1">Stream</tp:dbus-ref> objects which
       represent the actual transport to one or more remote contacts.</p>
       <tp:rationale>
         There are two cases where multiple streams may happen:
@@ -43,7 +43,7 @@
       </tp:rationale>
       <p>For protocols that support muting all streams of a given content
       separately, this object MAY also implement the <tp:dbus-ref
-      namespace="ofdT.Call1.Interface">Mute</tp:dbus-ref> interface</p>
+      namespace="imt1.Call1.Interface">Mute</tp:dbus-ref> interface</p>
     </tp:docstring>
 
     <method name="Remove" tp:name-for-bindings="Remove">
@@ -51,14 +51,14 @@
         arguments</tp:changed>
       <tp:docstring>
         Remove the content from the call. This will cause
-        <tp:dbus-ref namespace="ofdT.Channel.Type">Call1.ContentRemoved</tp:dbus-ref>((self_handle,
+        <tp:dbus-ref namespace="imt1.Channel.Type">Call1.ContentRemoved</tp:dbus-ref>((self_handle,
         <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>, "", "")) to be
         emitted.
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised when a Call doesn't support removing contents
             (e.g. a Google Talk video call).
@@ -72,9 +72,9 @@
       <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.Call1">Content.Interface.Media</tp:dbus-ref>,
-          <tp:dbus-ref namespace="ofdT.Channel">Interface.Hold</tp:dbus-ref> or
-          <tp:dbus-ref namespace="ofdT.Call1">Interface.Mute</tp:dbus-ref>.
+          namespace="imt1.Call1">Content.Interface.Media</tp:dbus-ref>,
+          <tp:dbus-ref namespace="imt1.Channel">Interface.Hold1</tp:dbus-ref> or
+          <tp:dbus-ref namespace="imt1.Call1">Interface.Mute</tp:dbus-ref>.
           This SHOULD NOT include the Content interface itself, and cannot
           change once the content has been created.</p>
       </tp:docstring>
@@ -107,7 +107,7 @@
         The disposition of this content, which defines whether to
         automatically start sending data on the streams when
         <tp:dbus-ref
-        namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref> is
+        namespace="imt1.Channel.Type.Call1">Accept</tp:dbus-ref> is
         called on the channel.
       </tp:docstring>
 
@@ -121,14 +121,14 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The content was initially part of the call. When
           <tp:dbus-ref
-          namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref>
+          namespace="imt1.Channel.Type.Call1">Accept</tp:dbus-ref>
           is called on the channel, all streams of this content with
           <tp:dbus-ref
-          namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
+          namespace="imt1.Call1.Stream">LocalSendingState</tp:dbus-ref>
           set to <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
           moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
           <tp:dbus-ref
-          namespace="ofdT.Call1.Stream">SetSending</tp:dbus-ref>
+          namespace="imt1.Call1.Stream">SetSending</tp:dbus-ref>
           (True) had been called.</p>
         </tp:docstring>
       </tp:enumvalue>
@@ -151,7 +151,7 @@
       <arg name="Streams" type="ao">
          <tp:docstring>
            The <tp:dbus-ref
-           namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
+           namespace="imt1.Call1">Stream</tp:dbus-ref>s which were
            added.
          </tp:docstring>
        </arg>
@@ -166,7 +166,7 @@
       <arg name="Streams" type="ao">
         <tp:docstring>
           The <tp:dbus-ref
-          namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
+          namespace="imt1.Call1">Stream</tp:dbus-ref>s which were
           removed.
         </tp:docstring>
       </arg>
@@ -180,7 +180,7 @@
     <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="ofdT.Call1"
+        <p>The list of <tp:dbus-ref namespace="imt1.Call1"
           >Stream</tp:dbus-ref> objects that exist in this
           content.</p>
 
diff --git a/spec/Call_Content_Interface_Audio_Control.xml b/spec/Call1_Content_Interface_Audio_Control1.xml
index 0efb488c..c7f441cf 100644
--- a/spec/Call_Content_Interface_Audio_Control.xml
+++ b/spec/Call1_Content_Interface_Audio_Control1.xml
@@ -1,5 +1,5 @@
 <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
-<node name="/Call_Content_Interface_Audio_Control"
+<node name="/Call1_Content_Interface_Audio_Control1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2011 Collabora Ltd.</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -19,9 +19,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content.Interface.AudioControl">
+  <interface name="im.telepathy1.Call1.Content.Interface.AudioControl1">
     <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.Interface.Media"/>
+    <tp:requires interface="im.telepathy1.Call1.Content.Interface.Media"/>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal" value="true"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Call_Content_Interface_DTMF.xml b/spec/Call1_Content_Interface_DTMF1.xml
index f6e9bda0..594ecf31 100644
--- a/spec/Call_Content_Interface_DTMF.xml
+++ b/spec/Call1_Content_Interface_DTMF1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content_Interface_DTMF" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Call1_Content_Interface_DTMF1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>
   <tp:copyright>Copyright © 2006 INdT</tp:copyright>
@@ -18,8 +18,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Call1.Content.Interface.DTMF">
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
+  <interface name="im.telepathy1.Call1.Content.Interface.DTMF1">
+    <tp:requires interface="im.telepathy1.Call1.Content"/>
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -52,13 +52,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           be called if no DTMF tones are already being played.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
 	    The event id was invalid.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy">
+        <tp:error name="im.telepathy1.Error.ServiceBusy">
           <tp:docstring>
             DTMF tones are already being played.
           </tp:docstring>
@@ -81,8 +81,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             Continuous tones are not supported by this stream. Deprecated,
             since stream IDs are ignored.
@@ -137,13 +137,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           be called if no DTMF tones are already being played.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The supplied Tones string was invalid.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy">
+        <tp:error name="im.telepathy1.Error.ServiceBusy">
           <tp:docstring>
             DTMF tones are already being played.
           </tp:docstring>
diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call1_Content_Interface_Media.xml
index 3f04df9b..4b2f30ae 100644
--- a/spec/Call_Content_Interface_Media.xml
+++ b/spec/Call1_Content_Interface_Media.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content_Interface_Media"
+<node name="/Call1_Content_Interface_Media"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,16 +20,15 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface
-      name="org.freedesktop.Telepathy.Call1.Content.Interface.Media">
+  <interface name="im.telepathy1.Call1.Content.Interface.Media">
     <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
+    <tp:requires interface="im.telepathy1.Call1.Content"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <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.Call1">Content</tp:dbus-ref> interface is
+        namespace="imt1.Call1">Content</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
@@ -39,41 +38,41 @@
       <h4>Codec Negotiation</h4>
 
       <p>When a new <tp:dbus-ref
-        namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channel
+        namespace="imt1.Channel.Type">Call1</tp:dbus-ref> channel
         appears (whether it was requested or not) a <tp:dbus-ref
-        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
         object will either be waiting in the
         <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property, or will
         appear at some point via the
         <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> signal.</p>
 
       <p>If nothing is known about the remote side's Media capabilities
-        (e.g. outgoing SIP/XMPP call), this <tp:dbus-ref namespace="ofdT.Call1.Content"
+        (e.g. outgoing SIP/XMPP call), this <tp:dbus-ref namespace="imt1.Call1.Content"
         >MediaDescription</tp:dbus-ref> will pop up with {<tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >HasRemoteInformation</tp:dbus-ref> = false, <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >FurtherNegotiationRequired</tp:dbus-ref> = true}, and the local
         user's streaming implementation SHOULD call 
-        <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+        <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
         >Accept</tp:dbus-ref>,
         with a description of all supported codecs and other features.
         The CM will then send this information to the remote side (and
         <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> will fire
         with details of the description passed into <tp:dbus-ref
-          namespace="ofdT.Call1.Content.MediaDescription"
+          namespace="imt1.Call1.Content.MediaDescription"
           >Accept</tp:dbus-ref> for debugging purposes).
       </p>
       <p>When the remote codecs and other content information are available
         (e.g. Remote user replies to initial offer, or sends a new offer of
-        their own, a new <tp:dbus-ref namespace="ofdT.Call1.Content"
+        their own, a new <tp:dbus-ref namespace="imt1.Call1.Content"
          >MediaDescription</tp:dbus-ref> will appear, with {<tp:dbus-ref
-         namespace="ofdT.Call1.Content.MediaDescription"
+         namespace="imt1.Call1.Content.MediaDescription"
          >HasRemoteInformation</tp:dbus-ref> = true, <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >FurtherNegotiationRequired</tp:dbus-ref> = false},
         and the <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >Codecs</tp:dbus-ref>
         property on the description offer set to the codecs which are
         supported by the remote contact. The local user's streaming
@@ -83,9 +82,9 @@
          <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> and
          <tp:member-ref>RemoteMediaDescriptionsChanged</tp:member-ref>
         will fire to signal their respective changes, to aid with debugging.
-        Note that if <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+        Note that if <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
         >Accept</tp:dbus-ref> is called, with <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >FurtherNegotiationRequired</tp:dbus-ref> set to false,
         the CM should be able to rely on the fact that the
         description passed into Accept is compatible with the one in the
@@ -105,7 +104,7 @@
       </p>
       <p> If parameters requiring negotiation are changed, then the
         <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >FurtherNegotiationRequired</tp:dbus-ref> property should be set to
         TRUE, and the new media description should
         only be used once they come in a new MediaDescriptionOffer
@@ -113,7 +112,7 @@
 
       <p>If the other side decides to update his or her codec list
         during a call, a new <tp:dbus-ref
-        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
         object will appear through
         <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> which should be
         acted on as documented above.</p>
@@ -121,12 +120,12 @@
       <h4>Protocols without negotiation</h4>
 
       <p>For protocols where the codecs are not negotiable, the initial content's <tp:dbus-ref
-        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+        namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
         object will appear with <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >HasRemoteInformation</tp:dbus-ref>,
         set to true and the known supported codec values in <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription"
+        namespace="imt1.Call1.Content.MediaDescription"
           >Codecs</tp:dbus-ref>.
       </p>
     </tp:docstring>
@@ -159,7 +158,7 @@
       <tp:member name="Updated" type="b">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           This should be set to true in calls to <tp:dbus-ref
-              namespace="ofdT.Call1.Content.MediaDescription"
+              namespace="imt1.Call1.Content.MediaDescription"
           >Accept</tp:dbus-ref> and
           <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> if this
           codec has changed in a way that needs to be signalled over the
@@ -200,9 +199,9 @@
       <tp:member name="Remote_Contact" type="u" tp:type="Handle">
         <tp:docstring>
           The remote contact this description refers to or 0. This matches the
-          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
             >RemoteContact</tp:dbus-ref> property on
-          <tp:dbus-ref namespace="ofdT.Call1.Content"
+          <tp:dbus-ref namespace="imt1.Call1.Content"
                     >MediaDescription</tp:dbus-ref>
         </tp:docstring>
       </tp:member>
@@ -220,7 +219,7 @@
       </tp:docstring>
       <tp:member name="Media_Description" type="o">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          The object path to the <tp:dbus-ref namespace="ofdT.Call1.Content"
+          The object path to the <tp:dbus-ref namespace="imt1.Call1.Content"
           >MediaDescription</tp:dbus-ref>
         </tp:docstring>
       </tp:member>
@@ -257,12 +256,12 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The protocol does not support changing the codecs mid-call.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The description given is invalid in some way.
           </tp:docstring>
@@ -279,8 +278,8 @@
           contact.</p>
 
         <p>Keys of this map will appear in at most one <tp:dbus-ref
-          namespace="ofdT.Call1.Stream">RemoteMembers</tp:dbus-ref>.
-          See <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          namespace="imt1.Call1.Stream">RemoteMembers</tp:dbus-ref>.
+          See <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
           >RemoteContact</tp:dbus-ref> for more details on how to map between
           MediaDescriptions and Streams.</p>
       </tp:docstring>
@@ -298,12 +297,12 @@
     <signal name="NewMediaDescriptionOffer"
         tp:name-for-bindings="New_Media_Description_Offer">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call1.Content"
+        <p>Emitted when a new <tp:dbus-ref namespace="imt1.Call1.Content"
           >MediaDescription</tp:dbus-ref> appears. The streaming
           >implementation MUST respond by calling the
-          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
           >Accept</tp:dbus-ref> or <tp:dbus-ref
-          namespace="ofdT.Call1.Content.MediaDescription"
+          namespace="imt1.Call1.Content.MediaDescription"
           >Reject</tp:dbus-ref> method on the description object appeared.</p>
 
         <p>Emission of this signal indicates that the
@@ -312,10 +311,10 @@
             <code>(Description, Contact, MediaDescriptionProperties)</code>.</p>
 
         <p>When the MediaDescriptionOffer has been dealt with then
-          <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+          <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
             >MediaDescriptionOfferDone</tp:dbus-ref> must be emitted
           before <tp:dbus-ref
-            namespace="ofdT.Call1.Content.Interface.Media"
+            namespace="imt1.Call1.Content.Interface.Media"
               >NewMediaDescriptionOffer</tp:dbus-ref> is emitted again.
         </p>
 
@@ -343,7 +342,7 @@
     <signal name="MediaDescriptionOfferDone"
         tp:name-for-bindings="Media_Description_Offer_Done">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call1.Content"
+        <p>Emitted when a <tp:dbus-ref namespace="imt1.Call1.Content"
           >MediaDescription</tp:dbus-ref> has been handled. </p>
         <p>Emission of this signal indicates that the
           <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
@@ -358,7 +357,7 @@
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Change notification for
-            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
               >LocalMediaDescriptions</tp:dbus-ref>
         </p>
       </tp:docstring>
@@ -376,7 +375,7 @@
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Change notification for
-            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
               >RemoteMediaDescriptions</tp:dbus-ref>
         </p>
       </tp:docstring>
@@ -394,10 +393,10 @@
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Removal notification for
-            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
               >RemoteMediaDescriptions</tp:dbus-ref>
             and
-            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+            <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
               >LocalMediaDescriptions</tp:dbus-ref>
         </p>
       </tp:docstring>
@@ -416,9 +415,9 @@
       type="(oa{sv})" tp:type="Media_Description_Offer" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The object path to the current
-          <tp:dbus-ref namespace="ofdT.Call1.Content"
+          <tp:dbus-ref namespace="imt1.Call1.Content"
            >MediaDescription</tp:dbus-ref> object, its
-            <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+            <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
             >RemoteContact</tp:dbus-ref> and
             a mapping of the MediaDescriptions properties.
             If the object path is "/" then there isn't an outstanding
@@ -426,7 +425,7 @@
 
         <tp:rationale>
           Having all <tp:dbus-ref
-          namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+          namespace="imt1.Call1.Content">MediaDescription</tp:dbus-ref>
           properties here saves a D-Bus round-trip - it shouldn't be
           necessary to get these properties from the Content MediaDescription
           object, in practice.
@@ -479,7 +478,7 @@
       tp:name-for-bindings="DTMF_Change_Requested">
       <tp:docstring>
         Used by the CM to relay instructions from <tp:dbus-ref
-        namespace="ofdT">Channel.Interface.DTMF</tp:dbus-ref> to the streaming
+        namespace="imt1">Channel.Interface.DTMF1</tp:dbus-ref> to the streaming
         implementation. If any contact in this call supports the
         telephone-event codec in their MediaDescription, this event should be
         sent as outlined in RFC 4733. Otherwise, it should be sent as an
diff --git a/spec/Call_Content_Interface_Video_Control.xml b/spec/Call1_Content_Interface_Video_Control1.xml
index 5a11dcba..130ec829 100644
--- a/spec/Call_Content_Interface_Video_Control.xml
+++ b/spec/Call1_Content_Interface_Video_Control1.xml
@@ -1,5 +1,5 @@
 <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
-<node name="/Call_Content_Interface_Video_Control"
+<node name="/Call1_Content_Interface_Video_Control1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2011 Collabora Ltd.</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -19,9 +19,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content.Interface.VideoControl">
+  <interface name="im.telepathy1.Call1.Content.Interface.VideoControl1">
     <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.Interface.Media"/>
+    <tp:requires interface="im.telepathy1.Call1.Content.Interface.Media"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface that allows the connection manager to control the video
diff --git a/spec/Call_Content_Media_Description.xml b/spec/Call1_Content_Media_Description.xml
index 88791a25..ae6e9d50 100644
--- a/spec/Call_Content_Media_Description.xml
+++ b/spec/Call1_Content_Media_Description.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content_Media_Description"
+<node name="/Call1_Content_Media_Description"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription">
+  <interface name="im.telepathy1.Call1.Content.MediaDescription">
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -28,7 +28,7 @@
       streaming implementation should reply with its local Description.
 
       This is intended as a temporary transactional object for use with <tp:dbus-ref
-          namespace="ofdT.Call1">Content.Interface.Media</tp:dbus-ref>.
+          namespace="imt1.Call1">Content.Interface.Media</tp:dbus-ref>.
       There will always be 0 or 1 MediaDescription object per Content.
       In most cases, this object will stay alive until you call either
       <tp:member-ref>Accept</tp:member-ref> or
@@ -44,7 +44,7 @@
         <tp:docstring>
           The local description to send to the remote contacts and
           to use in the <tp:dbus-ref
-          namespace="ofdT.Call1">Content</tp:dbus-ref>.
+          namespace="imt1.Call1">Content</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <tp:docstring>
@@ -55,7 +55,7 @@
         FurtherNegotiationRequired set to False).
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The description given is invalid in some way.
           </tp:docstring>
@@ -134,7 +134,7 @@
         The contact handle that this description applies to.
 
         This property can be used as an opaque identifier, and searched for in
-        <tp:dbus-ref namespace="ofdT.Call1.Stream"
+        <tp:dbus-ref namespace="imt1.Call1.Stream"
         >RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
         determine which Stream this MediaDescription applies to. If multiple
         MediaDescriptions apply to the same Stream, the
@@ -178,7 +178,7 @@
         list containing a single SSRC (which does not collide with these,
         or any previously seen SSRCs). If a new MediaDescription offer
         appears with an SSRC the same as one in <tp:dbus-ref
-        namespace="ofdT.Call1.Content.Interface.Media"
+        namespace="imt1.Call1.Content.Interface.Media"
         >LocalMediaDescriptions</tp:dbus-ref>, then the streaming
         implementation should pick a new SSRC to resolve the collision.</p>
 
@@ -204,15 +204,15 @@
         <p>
           A mapping containing all properties that define the information from a
           <tp:dbus-ref
-            namespace="ofdT.Call1.Content"
+            namespace="imt1.Call1.Content"
             >MediaDescription</tp:dbus-ref> and its interfaces.
         </p>
 
         <p>
-          If <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          If <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
             >HasRemoteInformation</tp:dbus-ref> is True, then this mapping
           will always contains at least
-          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          <tp:dbus-ref namespace="imt1.Call1.Content.MediaDescription"
             >Codecs</tp:dbus-ref>
         </p>
       </tp:docstring>
diff --git a/spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml b/spec/Call1_Content_Media_Description_Interface_RTCP_Extended_Reports1.xml
index eb5fbdb6..bd6c7f15 100644
--- a/spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml
+++ b/spec/Call1_Content_Media_Description_Interface_RTCP_Extended_Reports1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content_Media_Description_Interface_RTCP_Extended_Reports" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Call1_Content_Media_Description_Interface_RTCP_Extended_Reports1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -18,10 +18,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.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTCPExtendedReports">
+  <interface name="im.telepathy1.Call1.Content.MediaDescription.Interface.RTCPExtendedReports1">
     <tp:added version="0.25.2">(as stable API)</tp:added>
     <tp:requires
-    interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
+    interface="im.telepathy1.Call1.Content.MediaDescription"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This codec offer interface provides a method of signalling for
diff --git a/spec/Call1_Content_Media_Description_Interface_RTCP_Feedback1.xml b/spec/Call1_Content_Media_Description_Interface_RTCP_Feedback1.xml
new file mode 100644
index 00000000..e9dbf226
--- /dev/null
+++ b/spec/Call1_Content_Media_Description_Interface_RTCP_Feedback1.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0" ?>
+<node name="/Call1_Content_Media_Description_Interface_RTCP_Feedback1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
+  <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+  </tp:license>
+
+  <interface name="im.telepathy1.Call1.Content.MediaDescription.Interface.RTCPFeedback1">
+    <tp:added version="0.25.2">(as stable API)</tp:added>
+    <tp:requires interface="im.telepathy1.Call1.Content.MediaDescription"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This codec offer interface provides a method of signalling
+        support for RTCP feedback, documented by <em>Extended RTP
+        Profile for Real-time Transport Control Protocol (RTCP)-Based
+        Feedback (RTP/AVPF)</em> (RFC 4585).</p>
+
+      <p>The codec identifiers used in the description of the Feedback Messages
+      sent in the <tp:dbus-ref
+        namespace="imt1.Call1.Content.MediaDescription">Accept</tp:dbus-ref>'s
+      should match those used for the RemoteCodecs in the same Accept call.
+      </p>
+
+      <p>For more details on what RTCP Feedback can do and how to use
+        it, one should refer to
+        <a href="http://www.faqs.org/rfcs/rfc4585.html">RFC 4585</a>.</p>
+
+    </tp:docstring>
+
+    <tp:struct name="RTCP_Feedback_Message_Properties">
+      <tp:added version="0.22.1"/>
+      <tp:changed version="0.23.4">This struct is also used by Call, but
+        in call, the CM should know about RTP profiles, and never use MAXUINT
+        as a default value, because it complicates things unnecessarily.
+      </tp:changed>
+      <tp:member type="u" name="RTCPMinimumInterval">
+        <tp:docstring>
+          The minimum interval between two regular RTCP packets in
+          milliseconds for this content. If no special value is
+          required, 5000 (5 seconds) should be used in RTP/AVP, and a
+          lower value in RTP/AVPF (by default, 0).
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="a(sss)" tp:type="RTCP_Feedback_Message[]"
+                 name="Messages">
+        <tp:docstring>
+          The RTCP feedback messages for this codec.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:struct name="RTCP_Feedback_Message"
+               array-name="RTCP_Feedback_Message_List">
+      <tp:added version="0.22.1"/>
+      <tp:docstring>
+        A struct defining an RTCP feedback message.
+      </tp:docstring>
+      <tp:member type="s" name="Type">
+        <tp:docstring>
+          Feedback type, for example "ack", "nack", or "ccm".
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Subtype">
+        <tp:docstring>
+          Feedback subtype, according to the Type, can be an empty string (""),
+          if there is no subtype.
+          For example, generic nack is Type="nack" Subtype="".
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Parameters">
+        <tp:docstring>
+          Feedback parameters as a string. Format is defined in the relevant RFC
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:mapping name="RTCP_Feedback_Message_Map">
+      <tp:added version="0.22.1"/>
+      <tp:docstring>
+        A map of codec and its feedback properties.
+      </tp:docstring>
+      <tp:member type="u" name="Codec_Identifier">
+        <tp:docstring>
+          Numeric identifier for the codec. This will be used as the
+          PT in the SDP or content description.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="(ua(sss))" tp:type="RTCP_Feedback_Message_Properties"
+                 name="Properties">
+        <tp:docstring>
+          The RTCP feedback properties for this codec.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <property name="FeedbackMessages" type="a{u(ua(sss))}"
+      tp:type="RTCP_Feedback_Message_Map"
+      access="read" tp:name-for-bindings="Feedback_Messages">
+      <tp:docstring>
+        A map of remote feedback codec properties that are supported.
+      </tp:docstring>
+    </property>
+
+    <property name="DoesAVPF" type="b"
+      access="read" tp:name-for-bindings="Does_AVPF">
+      <tp:docstring>
+        True if the remote contact supports Audio-Visual Profile
+        Feedback (AVPF), otherwise False.
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml b/spec/Call1_Content_Media_Description_Interface_RTP_Header_Extensions1.xml
index 25a77e02..4f50eb7a 100644
--- a/spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml
+++ b/spec/Call1_Content_Media_Description_Interface_RTP_Header_Extensions1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Content_Media_Description_Interface_RTP_Header_Extensions" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Call1_Content_Media_Description_Interface_RTP_Header_Extensions1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -18,9 +18,9 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTPHeaderExtensions">
+  <interface name="im.telepathy1.Call1.Content.MediaDescription.Interface.RTPHeaderExtensions1">
     <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
+    <tp:requires interface="im.telepathy1.Call1.Content.MediaDescription"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This media description interface provides a method of signalling
@@ -33,6 +33,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     </tp:docstring>
 
+    <tp:enum name="Media_Stream_Direction" type="u">
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring>Media are not being sent or received</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Send" value="1">
+        <tp:docstring>Media are being sent, but not received</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Receive" value="2">
+        <tp:docstring>Media are being received, but not sent</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Bidirectional" value="3">
+        <tp:docstring>Media are being sent and received</tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
     <tp:struct name="RTP_Header_Extension"
       array-name="RTP_Header_Extensions_List">
       <tp:docstring>
diff --git a/spec/Call_Interface_Mute.xml b/spec/Call1_Interface_Mute.xml
index 573efcc8..d1a7766d 100644
--- a/spec/Call_Interface_Mute.xml
+++ b/spec/Call1_Interface_Mute.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Interface_Mute" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Call1_Interface_Mute" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -18,12 +18,12 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Interface.Mute" tp:causes-havoc="experimental">
+  <interface name="im.telepathy1.Call1.Interface.Mute" tp:causes-havoc="experimental">
     <tp:added version="0.25.2">(as stable API)</tp:added>
     <tp:xor-requires>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
+      <tp:requires interface="im.telepathy1.Channel.Type.Call1"/>
+      <tp:requires interface="im.telepathy1.Call1.Content"/>
+      <tp:requires interface="im.telepathy1.Call1.Stream"/>
     </tp:xor-requires>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -114,12 +114,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       access="read" tp:name-for-bindings="Local_Mute_State">
       <tp:docstring>
         The current mute state of this part of the call. New
-        <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>s should
+        <tp:dbus-ref namespace="imt1.Call1">Content</tp:dbus-ref>s should
         inherit the value of this property from the parent
-        <tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>.
-        Similarly, <tp:dbus-ref namespace="ofdT.Call1">Stream</tp:dbus-ref>s
+        <tp:dbus-ref namespace="imt1.Channel.Type">Call1</tp:dbus-ref>.
+        Similarly, <tp:dbus-ref namespace="imt1.Call1">Stream</tp:dbus-ref>s
         should inherit it from the parent <tp:dbus-ref
-        namespace="ofdT.Call1">Content</tp:dbus-ref>.
+        namespace="imt1.Call1">Content</tp:dbus-ref>.
       </tp:docstring>
     </property>
 
diff --git a/spec/Call_Stream.xml b/spec/Call1_Stream.xml
index 729dc7ea..7751c7b8 100644
--- a/spec/Call_Stream.xml
+++ b/spec/Call1_Stream.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Stream"
+<node name="/Call1_Stream"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,18 +20,18 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Stream">
+  <interface name="im.telepathy1.Call1.Stream">
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>One stream inside a <tp:dbus-ref
-      namespace="ofdT.Call1">Content</tp:dbus-ref>.  A stream is
+      namespace="imt1.Call1">Content</tp:dbus-ref>.  A stream is
       a single flow of packets to and from a single remote endpoint.
       If your call connects to multiple people, you could have
       multiple streams.</p>
       <p>For protocols that support muting streams separately, this object MAY
       also implement the <tp:dbus-ref
-      namespace="ofdT.Call1.Interface">Mute</tp:dbus-ref> interface</p>
+      namespace="imt1.Call1.Interface">Mute</tp:dbus-ref> interface</p>
     </tp:docstring>
 
     <method name="SetSending" tp:name-for-bindings="Set_Sending">
@@ -55,8 +55,8 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented" />
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+        <tp:error name="im.telepathy1.Error.NotImplemented" />
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring>If the call has not been accepted yet, calling
             SetSending(True) is an error. See
             <tp:member-ref>LocalSendingState</tp:member-ref> for details.
@@ -89,14 +89,14 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.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:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The protocol does not allow the local user to request the
             other side starts sending on this stream.
@@ -211,7 +211,7 @@
       <tp:added version="0.19.11"/>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Extra interfaces provided by this stream, such as <tp:dbus-ref
-            namespace="ofdT.Call1">Stream.Interface.Media</tp:dbus-ref>.
+            namespace="imt1.Call1">Stream.Interface.Media</tp:dbus-ref>.
           This SHOULD NOT include the Stream interface itself, and cannot
           change once the stream has been created.</p>
       </tp:docstring>
@@ -225,7 +225,7 @@
 
         <p>Media sent to this stream will be sent to all members listed here.
           All members listed here will also appear in <tp:dbus-ref
-          namespace="ofdT.Channel.Type.Call1">CallMembers</tp:dbus-ref>,
+          namespace="imt1.Channel.Type.Call1">CallMembers</tp:dbus-ref>,
           and each CallMembers member will be listed in at most one Stream per
           Content. Therefore, to hide things from a member of the
           call, UIs only need to mute one Stream per Content.</p>
@@ -237,10 +237,10 @@
           >LocalSendingState</tp:member-ref>.</p>
 
         <p>This mapping is also used by the streaming implementation to map
-          from <tp:dbus-ref namespace="ofdT.Call1.Content"
+          from <tp:dbus-ref namespace="imt1.Call1.Content"
           >MediaDescription</tp:dbus-ref>s to Streams. In this use-case,
           all of the senders in this stream will be represented in
-          <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+          <tp:dbus-ref namespace="imt1.Call1.Content.Interface.Media"
           >RemoteMediaDescriptions</tp:dbus-ref>. This use-case should not
           affect anything that does not handle media streaming.</p>
       </tp:docstring>
@@ -279,13 +279,13 @@
           this property indicates that the other side requested the
           local user start sending media (which can be done by calling either
           <tp:member-ref>SetSending</tp:member-ref> or <tp:dbus-ref
-          namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref>).</p>
+          namespace="imt1.Channel.Type.Call1">Accept</tp:dbus-ref>).</p>
 
         <p>When <tp:dbus-ref
-          namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref> is
+          namespace="imt1.Channel.Type.Call1">Accept</tp:dbus-ref> is
           called, all streams with a local sending state of
           <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> and the associated
-          <tp:dbus-ref namespace="ofdT.Call1.Content"
+          <tp:dbus-ref namespace="imt1.Call1.Content"
           >Disposition</tp:dbus-ref> set to
           <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref> are
           automatically set to sending.</p>
diff --git a/spec/Call_Stream_Endpoint.xml b/spec/Call1_Stream_Endpoint.xml
index cf2397b4..8c705b8f 100644
--- a/spec/Call_Stream_Endpoint.xml
+++ b/spec/Call1_Stream_Endpoint.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Stream_Endpoint"
+<node name="/Call1_Stream_Endpoint"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Stream.Endpoint">
+  <interface name="im.telepathy1.Call1.Stream.Endpoint">
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -148,7 +148,7 @@
 
         <p>Also note that some or all of the local candidates in this list may
         represent a peer-reflexive candidate that do not appear in
-        <tp:dbus-ref namespace="ofdT.Call1.Stream.Interface.Media"
+        <tp:dbus-ref namespace="imt1.Call1.Stream.Interface.Media"
         >LocalCandidates</tp:dbus-ref>.</p>
 
         <p>See <a href='http://tools.ietf.org/html/rfc5245#appendix-B.6'>RFC
@@ -187,7 +187,7 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
 
@@ -283,8 +283,8 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
       </tp:possible-errors>
     </method>
 
@@ -308,7 +308,7 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
 
@@ -332,7 +332,7 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Call_Stream_Interface_Media.xml b/spec/Call1_Stream_Interface_Media.xml
index 1356faa1..d8500d73 100644
--- a/spec/Call_Stream_Interface_Media.xml
+++ b/spec/Call1_Stream_Interface_Media.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Call_Stream_Interface_Media"
+<node name="/Call1_Stream_Interface_Media"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
@@ -20,9 +20,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call1.Stream.Interface.Media">
+  <interface name="im.telepathy1.Call1.Stream.Interface.Media">
     <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
+    <tp:requires interface="im.telepathy1.Call1.Stream"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface deals with how to connect a stream to an
@@ -32,7 +32,7 @@
       endpoints at the same time. This is called forking in the SIP
       jargon.  Informations related to the connections are on the
       <tp:dbus-ref
-      namespace="ofdT.Call1.Stream">Endpoint</tp:dbus-ref>
+      namespace="imt1.Call1.Stream">Endpoint</tp:dbus-ref>
       objects. Once the call is established, there MUST be a single
       endpoint left.</p>
 
@@ -126,7 +126,7 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The state change made no sense, and was ignored by the CM. The
             most likely cause for this is a race-condition between the CM
@@ -187,7 +187,7 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The state change made no sense, and was ignored by the CM. The
             most likely cause for this is a race-condition between the CM
@@ -277,6 +277,14 @@
       </tp:enumvalue>
     </tp:enum>
 
+    <tp:enum name="Media_Stream_Base_Proto" type="u">
+      <tp:enumvalue suffix="UDP" value="0">
+        <tp:docstring>UDP (User Datagram Protocol)</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="TCP" value="1">
+        <tp:docstring>TCP (Transmission Control Protocol)</tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
 
     <tp:mapping name="Candidate_Info">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -408,7 +416,7 @@
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The minimal required candidates have not been set. For
             example, for an RTP protocol, at least one candidate on the
@@ -433,7 +441,7 @@
         <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="ofdT.Channel.Type"
+          it in the <tp:dbus-ref namespace="imt1.Channel.Type"
           >Call1</tp:dbus-ref> interface.
           [This corresponds to "none" or "stun" in the old Media.StreamHandler
           interface.]
@@ -561,11 +569,11 @@
         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[]" />
+      <arg name="Servers" type="a(su)" 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">
+      type="a(su)" tp:type="Socket_Address_IP[]" access="read">
       <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
@@ -720,7 +728,7 @@
     <property name="Endpoints" tp:name-for-bindings="Endpoints"
       type="ao" access="read">
       <tp:docstring>
-        <p>The list of <tp:dbus-ref namespace="ofdT.Call1.Stream"
+        <p>The list of <tp:dbus-ref namespace="imt1.Call1.Stream"
           >Endpoint</tp:dbus-ref> objects that exist for this
           stream.</p>
 
diff --git a/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml b/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml
deleted file mode 100644
index 7a558cc3..00000000
--- a/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Call_Content_Media_Description_Interface_RTCP_Feedback" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
-  <tp:license xmlns="http://www.w3.org/1999/xhtml">
-This library is free software; you can redistribute it and/or
-modify it under the terms of the GNU Lesser General Public
-License as published by the Free Software Foundation; either
-version 2.1 of the License, or (at your option) any later version.
-
-This library is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-Lesser General Public License for more details.
-
-You should have received a copy of the GNU Lesser General Public
-License along with this library; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-  </tp:license>
-
-  <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription.Interface.RTCPFeedback">
-    <tp:added version="0.25.2">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>This codec offer interface provides a method of signalling
-        support for RTCP feedback, documented by <em>Extended RTP
-        Profile for Real-time Transport Control Protocol (RTCP)-Based
-        Feedback (RTP/AVPF)</em> (RFC 4585).</p>
-
-      <p>The codec identifiers used in the description of the Feedback Messages
-      sent in the <tp:dbus-ref
-        namespace="ofdT.Call1.Content.MediaDescription">Accept</tp:dbus-ref>'s
-      should match those used for the RemoteCodecs in the same Accept call.
-      </p>
-
-      <p>For more details on what RTCP Feedback can do and how to use
-        it, one should refer to
-        <a href="http://www.faqs.org/rfcs/rfc4585.html">RFC 4585</a>.</p>
-
-    </tp:docstring>
-
-    <property name="FeedbackMessages" type="a{u(ua(sss))}"
-      tp:type="RTCP_Feedback_Message_Map"
-      access="read" tp:name-for-bindings="Feedback_Messages">
-      <tp:docstring>
-        A map of remote feedback codec properties that are supported.
-      </tp:docstring>
-    </property>
-
-    <property name="DoesAVPF" type="b"
-      access="read" tp:name-for-bindings="Does_AVPF">
-      <tp:docstring>
-        True if the remote contact supports Audio-Visual Profile
-        Feedback (AVPF), otherwise False.
-      </tp:docstring>
-    </property>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel.xml b/spec/Channel.xml
index 12a486e4..ef5bf5e8 100644
--- a/spec/Channel.xml
+++ b/spec/Channel.xml
@@ -18,7 +18,7 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel">
+  <interface name="im.telepathy1.Channel">
 
     <property name="ChannelType" type="s" tp:type="DBus_Interface"
       access="read" tp:name-for-bindings="Channel_Type">
@@ -27,11 +27,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>The channel's type. This cannot change once the channel has
           been created.</p>
 
-        <p>For compatibility between older connection managers and newer
-          clients, if this is unavailable or is an empty string,
-          clients MUST use the result of calling
-          <tp:member-ref>GetChannelType</tp:member-ref>.</p>
-
         <tp:rationale>
           The GetAll method lets clients retrieve all properties in one
           round-trip, which is desirable.
@@ -55,21 +50,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           the channel type and the Channel interface itself, and cannot
           change once the channel has been created.</p>
 
-        <p>For compatibility between older connection managers and newer
-          clients, if this is unavailable, or if this is an empty list and
-          <tp:member-ref>ChannelType</tp:member-ref> is an empty string,
-          clients MUST use the result of calling
-          <tp:member-ref>GetInterfaces</tp:member-ref> instead. If this is an
-          empty list but ChannelType is non-empty, clients SHOULD NOT call
-          GetInterfaces; this implies that connection managers that implement
-          the ChannelType property MUST also implement the Interfaces property
-          correctly.</p>
-
-        <tp:rationale>
-          The GetAll method lets clients retrieve all properties in one
-          round-trip, which is desirable.
-        </tp:rationale>
-
         <p>When requesting a channel with a particular value for this
           property, the request must fail without side-effects unless the
           connection manager expects to be able to provide a channel whose
@@ -102,7 +82,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           MUST be present and not Handle_Type_None, and
           <tp:member-ref>TargetID</tp:member-ref> MUST NOT be
           present. Properties from
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Addressing1</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface">Addressing1</tp:dbus-ref>
           MUST NOT be present.</p>
 
         <p>The channel that satisfies the request MUST either:</p>
@@ -129,40 +109,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           room, etc. with which this channel communicates), or the empty
           string if the TargetHandle is 0.</p>
 
-        <tp:rationale>
-          <p>The presence of this property avoids the following race
-            condition:</p>
-
-          <ul>
-            <li>New channel C is signalled with target handle T</li>
-            <li>Client calls <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>(CONTACT,
-              [T])</li>
-            <li>Channel C closes, removing the last reference to handle T</li>
-            <li><tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>(CONTACT,
-              [T]) returns an error</li>
-          </ul>
-        </tp:rationale>
-
         <p>If this is present in a channel request,
           <tp:member-ref>TargetHandleType</tp:member-ref>
           MUST be present and not Handle_Type_None, and
           <tp:member-ref>TargetHandle</tp:member-ref> MUST NOT be
           present. Properties from
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Addressing1</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface">Addressing1</tp:dbus-ref>
           MUST NOT be present.The request MUST fail with error InvalidHandle,
-          without side-effects, if the requested TargetID would not be
-          accepted by
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">RequestHandles</tp:dbus-ref>.</p>
+          without side-effects, if the requested TargetID is invalid.</p>
 
         <p>The returned channel must be related to the handle corresponding
           to the given identifier, in the same way as if TargetHandle
           had been part of the request instead.</p>
 
         <tp:rationale>
-          <p>Requesting channels with a string identifier saves a round-trip
-            (the call to RequestHandles). It also allows the channel
+          <p>Requesting channels with a string identifier allows the channel
             dispatcher to accept a channel request for an account that is not
             yet connected (and thus has no valid handles), bring the account
             online, and pass on the same parameters to the new connection's
@@ -197,14 +158,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         such as contact list channels may not be closed.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             This channel may never be closed, e.g. a contact list
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             This channel is not currently in a state where it can be closed,
             e.g. a non-empty user-defined contact group
@@ -222,84 +183,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
-    <method name="GetChannelType" tp:name-for-bindings="Get_Channel_Type">
-      <tp:deprecated version="0.17.7">Use the ChannelType
-        property if possible.</tp:deprecated>
-      <arg direction="out" type="s" tp:type="DBus_Interface"
-        name="Channel_Type">
-        <tp:docstring>The interface name</tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns the interface name for the type of this channel.  Clients
-        SHOULD use the <tp:member-ref>ChannelType</tp:member-ref> property
-        instead, falling back to this method only if necessary.
-
-        <tp:rationale>
-          The GetAll method lets clients retrieve all properties in one
-          round-trip.
-        </tp:rationale>
-      </tp:docstring>
-    </method>
-
-    <method name="GetHandle" tp:name-for-bindings="Get_Handle">
-      <tp:deprecated version="0.17.7">Use the TargetHandleType
-        and TargetHandle properties if possible.</tp:deprecated>
-      <arg direction="out" type="u" tp:type="Handle_Type"
-        name="Target_Handle_Type">
-        <tp:docstring>
-          The same as TargetHandleType.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="u" tp:type="Handle" name="Target_Handle">
-        <tp:docstring>
-          The same as TargetHandle.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns the handle type and number if this channel represents a
-        communication with a particular contact, room or server-stored list, or
-        zero if it is transient and defined only by its contents. Clients
-        SHOULD use the <tp:member-ref>TargetHandle</tp:member-ref> and
-        <tp:member-ref>TargetHandleType</tp:member-ref> properties instead,
-        falling back to this method only if necessary.
-
-        <tp:rationale>
-          The GetAll method lets clients retrieve all properties in one
-          round-trip.
-        </tp:rationale>
-      </tp:docstring>
-    </method>
-
-    <method name="GetInterfaces" tp:name-for-bindings="Get_Interfaces">
-      <tp:deprecated version="0.17.7">Use the Interfaces
-        property if possible.</tp:deprecated>
-      <arg direction="out" type="as" tp:type="DBus_Interface[]"
-        name="Interfaces">
-        <tp:docstring>
-          An array of the D-Bus interface names
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get the optional interfaces implemented by the channel.
-        Clients SHOULD use the <tp:member-ref>Interfaces</tp:member-ref>
-        property instead, falling back to this method only if necessary.
-
-        <tp:rationale>
-          The GetAll method lets clients retrieve all properties in one
-          round-trip.
-        </tp:rationale>
-      </tp:docstring>
-    </method>
-
     <property name="Requested" tp:name-for-bindings="Requested"
       type="b" access="read">
       <tp:added version="0.17.13">(as stable API)</tp:added>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>True if this channel was created in response to a local request,
           such as a call to
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.RequestChannel</tp:dbus-ref>
-          or
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>.</p>
+          <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>.</p>
 
         <tp:rationale>
           <p>The idea of this property is to distinguish between "incoming"
@@ -320,34 +210,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           e.g. because joining a Tube in a MUC context on XMPP implies
           joining that MUC), then this property is false.</p>
 
-        <p>For compatibility with older connection managers, clients SHOULD
-          assume that this property is true if they see a channel announced
-          by the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.NewChannel</tp:dbus-ref>
-          signal with the suppress_handler parameter set to true.</p>
-
-        <tp:rationale>
-          <p>In a correct connection manager, the only way to get such a
-            channel is to request it.</p>
-        </tp:rationale>
-
-        <p>Clients MAY additionally assume that this property is false
-          if they see a channel announced by the NewChannel signal with the
-          suppress_handler parameter set to false.</p>
-
-        <tp:rationale>
-          <p>This is more controversial, since it's possible to get that
-            parameter set to false by requesting a channel. However, there's
-            no good reason to do so, and we've deprecated this practice.</p>
-
-          <p>In the particular case of the channel dispatcher, the only
-            side-effect of wrongly thinking a channel is unrequested
-            is likely to be that the user has to confirm that they want to
-            use it, so it seems fairly harmless to assume in the channel
-            dispatcher that channels with suppress_handler false are
-            indeed unrequested.</p>
-        </tp:rationale>
-
         <p>It does not make sense for this property to be in channel
           requests—it will always be true for channels returned by
           CreateChannel, and callers of EnsureChannel cannot control whether an
@@ -383,14 +245,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>For channels requested by the
           local user, this MUST be the value of
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.SelfHandle</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Connection.SelfHandle</tp:dbus-ref>
           at the time the channel was created (i.e. not a channel-specific
           handle).</p>
 
         <tp:rationale>
           <p>On some protocols, the SelfHandle may change (as signalled by
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Connection.SelfContactChanged</tp:dbus-ref>),
+              namespace="im.telepathy1">Connection.SelfContactChanged</tp:dbus-ref>),
             but this property is immutable. Hence, locally-requested channels'
             InitiatorHandle and InitiatorID may not match the current
             SelfHandle; <tp:member-ref>Requested</tp:member-ref> can be used to
@@ -404,7 +266,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           anonymous).</p>
 
         <p>For channels with the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Group</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Interface">Group1</tp:dbus-ref>
           interface, this SHOULD be the same
           contact who is signalled as the "Actor" causing the self-handle
           to be placed in the local-pending set.</p>
@@ -425,25 +287,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>InitiatorHandle</tp:member-ref>
           property (i.e. the initiator's identifier in the IM protocol).</p>
 
-        <tp:rationale>
-          <p>The presence of this property avoids the following race
-            condition:</p>
-
-          <ul>
-            <li>New StreamedMedia channel C is signalled with initiator
-              handle I</li>
-            <li>Client calls <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>(CONTACT,
-              [I])</li>
-            <li>Channel C closes, removing the last reference to handle I</li>
-            <li><tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>(CONTACT,
-              [I]) returns an error</li>
-            <li>Client can indicate that a call was missed, but not who
-              called!</li>
-          </ul>
-        </tp:rationale>
-
         <p>It does not make sense for this property to be in channel
           requests - the initiator will always be the local user - so it
           MUST NOT be accepted.</p>
@@ -451,18 +294,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-    <p>All communication in the Telepathy framework is carried out via channel
-    objects which are created and managed by connections. This interface must
-    be implemented by all channel objects, along with one single channel type,
-    such as <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy">Channel.Type.ContactList</tp:dbus-ref>
-    which represents a list of people (such as a buddy list) or <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy">Channel.Type.Text</tp:dbus-ref> which
-    represents a channel over which textual messages are sent and received.</p>
+    <p>
+      All communication in the Telepathy framework is carried out via
+      channel objects which are created and managed by
+      connections. This interface must be implemented by all channel
+      objects, along with one single channel type, such as
+      <tp:dbus-ref
+      namespace="im.telepathy1">Channel.Type.Text</tp:dbus-ref> which
+      represents a channel over which textual messages are sent and
+      received.</p>
 
     <p>Each Channel's object path MUST start with the object path of
       its associated <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>, followed
+      namespace="im.telepathy1">Connection</tp:dbus-ref>, followed
       by '/'. There MAY be any number of additional object-path components,
       which clients MUST NOT attempt to parse.</p>
 
@@ -479,11 +323,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <p>Each channel has a number of immutable properties (which cannot vary
       after the channel has been announced with <tp:dbus-ref
-        namespace='ofdT.Connection.Interface.Requests'>NewChannels</tp:dbus-ref>),
+        namespace='imt1.Connection.Interface.Requests'>NewChannels</tp:dbus-ref>),
       provided to clients in the
-      <tp:dbus-ref namespace='ofdT.Client.Observer'>ObserveChannels</tp:dbus-ref>,
-      <tp:dbus-ref namespace='ofdT.Client.Approver'>AddDispatchOperation</tp:dbus-ref> and
-      <tp:dbus-ref namespace='ofdT.Client.Handler'>HandleChannels</tp:dbus-ref>
+      <tp:dbus-ref namespace='imt1.Client.Observer'>ObserveChannels</tp:dbus-ref>,
+      <tp:dbus-ref namespace='imt1.Client.Approver'>AddDispatchOperation</tp:dbus-ref> and
+      <tp:dbus-ref namespace='imt1.Client.Handler'>HandleChannels</tp:dbus-ref>
       methods to permit immediate identification of the channel. This interface
       contains immutable properties common to all channels. In brief:</p>
 
@@ -507,12 +351,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <p>Other optional <tp:member-ref>Interfaces</tp:member-ref> can be
       implemented to indicate other available
       functionality, such as <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Channel.Interface.Group</tp:dbus-ref>
+        namespace="im.telepathy1">Channel.Interface.Group1</tp:dbus-ref>
       if the channel contains a number of contacts, <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Channel.Interface.Password</tp:dbus-ref>
+        namespace="im.telepathy1">Channel.Interface.Password1</tp:dbus-ref>
       to indicate that a channel may have a password set to require entry, and
       <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Channel.Interface.ChatState</tp:dbus-ref>
+        namespace="im.telepathy1">Channel.Interface.ChatState1</tp:dbus-ref>
       for typing notifications. The interfaces implemented may not vary after
       the channel has been created. These other interfaces (along with the
       interface named by <tp:member-ref>ChannelType</tp:member-ref>) may
@@ -524,11 +368,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       which indicates that the channel is defined by some other properties. For
       instance, transient ad-hoc chat rooms may be defined only by their members (as visible
       through the <tp:dbus-ref
-        namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        namespace="imt1.Channel.Interface">Group1</tp:dbus-ref>
       interface), and <tp:dbus-ref
-        namespace='ofdT.Channel.Type'>ContactSearch</tp:dbus-ref>
+        namespace='imt1.Channel.Type'>ContactSearch1</tp:dbus-ref>
       channels represent a single search attempt for a particular <tp:dbus-ref
-        namespace='ofdT.Channel.Type.ContactSearch'>Server</tp:dbus-ref>.</p>
+        namespace='imt1.Channel.Type.ContactSearch1'>Server</tp:dbus-ref>.</p>
 
     <p>Specific connection manager implementations may implement channel types and
     interfaces which are not contained within this specification in order to
@@ -552,6 +396,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       guarantee that Channels' object paths had the Connection's object path
       as a prefix.
     </tp:changed>
+
+    <tp:changed version="0.99.1">Deprecated methods
+      (GetChannelType, GetHandle, and GetInterfaces) have been removed
+      from this interface.</tp:changed>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Bundle.xml b/spec/Channel_Bundle.xml
deleted file mode 100644
index d211525a..00000000
--- a/spec/Channel_Bundle.xml
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Bundle"
-  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright (C) 2008 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.ChannelBundle.DRAFT"
-    tp:causes-havoc="experimental">
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A group of related channels, which should all be dispatched to the
-        same handler if possible.</p>
-
-      <p>Bundles currently have no functionality of their own, so clients
-        SHOULD NOT examine this interface, but should instead treat the
-        bundle object-path as an opaque identifier. If more functionality is
-        added to bundles in future, this interface will be used for capability
-        discovery.</p>
-
-      <p>The lifetime of a bundle is defined by its component channels -
-        as long as one or more channels whose Bundle property is <em>B</em>
-        exist, the bundle <em>B</em> will also exist.</p>
-    </tp:docstring>
-
-    <property name="Interfaces" tp:name-for-bindings="Interfaces"
-      type="as" access="read" tp:type="DBus_Interface[]">
-      <tp:docstring>
-        A list of the extra interfaces provided by this channel bundle.
-      </tp:docstring>
-    </property>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Dispatch_Operation.xml b/spec/Channel_Dispatch_Operation.xml
index 6ec69a67..2b4756a9 100644
--- a/spec/Channel_Dispatch_Operation.xml
+++ b/spec/Channel_Dispatch_Operation.xml
@@ -21,29 +21,26 @@
       MA 02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.ChannelDispatchOperation">
+  <interface name="im.telepathy1.ChannelDispatchOperation">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel dispatch operation is an object in the ChannelDispatcher
         representing a batch of unrequested channels being announced to
         client
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Client">Approver</tp:dbus-ref>
         processes.</p>
 
       <p>These objects can result from new incoming channels or channels
         which are automatically created for some reason, but cannot result
         from outgoing requests for channels.</p>
 
-      <p>More specifically, whenever the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.NewChannels</tp:dbus-ref>
-        signal contains channels whose
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
-        property is false, or whenever the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.NewChannel</tp:dbus-ref>
-        signal contains a channel with suppress_handler false,
-        one or more ChannelDispatchOperation objects are created for those
-        channels.</p>
+      <p>More specifically, whenever the <tp:dbus-ref
+        namespace="im.telepathy1">Connection.Interface.Requests.NewChannels</tp:dbus-ref>
+        signal contains channels whose <tp:dbus-ref
+        namespace="im.telepathy1.Channel">Requested</tp:dbus-ref>
+        property is false, one or more ChannelDispatchOperation
+        objects are created for those channels.</p>
 
       <p>(If some channels in a NewChannels signal are in different bundles,
         this is an error. The channel dispatcher SHOULD recover by treating
@@ -52,9 +49,9 @@
 
       <p>First, the channel dispatcher SHOULD construct a list of all the
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
+          namespace="im.telepathy1.Client">Handler</tp:dbus-ref>s
         that could handle all the channels (based on their <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+          namespace="im.telepathy1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
         property), ordered by
         priority in some implementation-dependent way. If there are handlers
         which could handle all the channels, one channel dispatch operation
@@ -66,30 +63,20 @@
         SHOULD terminate that channel instead of creating a channel dispatcher
         for it. It is RECOMMENDED that the channel dispatcher closes
         the channels using <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref>
+          namespace="im.telepathy1">Channel.Interface.Destroyable1.Destroy</tp:dbus-ref>
         if supported, or <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>
-        otherwise. As a special case, the channel dispatcher SHOULD NOT close
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">ContactList</tp:dbus-ref>
-        channels, and if Close fails, the channel dispatcher SHOULD ignore
-        that channel.</p>
-
-      <tp:rationale>
-        <p>ContactList channels are strange. We hope to replace them with
-          something better, such as an interface on the Connection, in a
-          future version of this specification.</p>
-      </tp:rationale>
+          namespace="im.telepathy1">Channel.Close</tp:dbus-ref>
+        otherwise.</p>
 
       <p>When listing channel handlers, priority SHOULD be given to
         channel handlers that are already handling channels from the same
         bundle.</p>
 
       <p>If a handler with <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Handler">BypassApproval</tp:dbus-ref>
+          namespace="im.telepathy1.Client.Handler">BypassApproval</tp:dbus-ref>
         <code>= True</code> could handle all of the channels in the dispatch
         operation, then the channel dispatcher SHOULD call <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+          namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
         on that handler, and (assuming the call succeeds) emit
         <tp:member-ref>Finished</tp:member-ref> and stop processing those
         channels without involving any approvers.</p>
@@ -97,12 +84,12 @@
       <tp:rationale>
         <p>Some channel types can be picked up "quietly" by an existing
           channel handler. If a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>
           channel is added to an existing bundle containing a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">Call1</tp:dbus-ref>
           channel, there shouldn't be
           any approvers, flashing icons or notification bubbles, if the
-          the UI for the StreamedMedia channel can just add a text box
+          the UI for the Call channel can just add a text box
           and display the message.</p>
       </tp:rationale>
 
@@ -111,7 +98,7 @@
         approver to claim the channels or request that they are handled.
         See
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
+          namespace="im.telepathy1.Client.Approver">AddDispatchOperation</tp:dbus-ref>
         for more details on this.</p>
 
       <p>Finally, if the approver requested it, the channel dispatcher SHOULD
@@ -130,7 +117,7 @@
       type="o" access="read">
       <tp:docstring>
         The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+          namespace="im.telepathy1">Connection</tp:dbus-ref>
         with which the <tp:member-ref>Channels</tp:member-ref> are
         associated. The well-known bus name to use can be derived from
         this object path by removing the leading '/' and replacing all
@@ -142,7 +129,7 @@
       type="o" access="read">
       <tp:docstring>
         The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          namespace="im.telepathy1">Account</tp:dbus-ref>
         with which the <tp:member-ref>Connection</tp:member-ref>
         and <tp:member-ref>Channels</tp:member-ref> are
         associated. This property cannot change.
@@ -153,7 +140,7 @@
       type="a(oa{sv})" access="read" tp:type="Channel_Details[]">
       <tp:docstring>
         The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s
+          namespace="im.telepathy1">Channel</tp:dbus-ref>s
         to be dispatched, and their properties. Change notification is via
         the <tp:member-ref>ChannelLost</tp:member-ref> signal (channels
         cannot be added to this property, only removed).
@@ -170,7 +157,7 @@
         <p>This signal MUST NOT be emitted until all Approvers that were
           invoked have returned (successfully or with an error) from
           their <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Approver">AddDispatchOperation</tp:dbus-ref>
           method.</p>
 
         <tp:rationale>
@@ -189,7 +176,7 @@
       <arg name="Channel" type="o">
         <tp:docstring>
           The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>
+            namespace="im.telepathy1">Channel</tp:dbus-ref>
           that closed.
         </tp:docstring>
       </arg>
@@ -198,7 +185,7 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The name of a D-Bus error indicating why the channel closed. If
             no better reason can be found,
-            <code>org.freedesktop.Telepathy.Error.NotAvailable</code> MAY
+            <code>im.telepathy1.Error.NotAvailable</code> MAY
             be used as a fallback; this means that this error SHOULD NOT be
             given any more specific meaning.</p>
         </tp:docstring>
@@ -215,9 +202,9 @@
       type="as" access="read" tp:type="DBus_Well_Known_Name[]">
       <tp:docstring>
         <p>The well known bus names (starting with
-          <code>org.freedesktop.Telepathy.Client.</code>) of the possible
+          <code>im.telepathy1.Client.</code>) of the possible
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
+            namespace="im.telepathy1.Client">Handler</tp:dbus-ref>s
           for these channels. The channel dispatcher MUST place the most
           preferred handlers first, according to some reasonable heuristic.
           As a result, approvers SHOULD use the first handler by default.</p>
@@ -257,7 +244,7 @@
         <p>(FIXME: list some possible errors)</p>
 
         <p>If the channel handler raises an error from <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>,
+            namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>,
           this method
           MAY respond by raising that same error, even if it is not
           specifically documented here.</p>
@@ -266,27 +253,27 @@
       <arg direction="in" type="s" tp:type="DBus_Bus_Name" name="Handler">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The well-known bus name (starting with
-            <code>org.freedesktop.Telepathy.Client.</code>) of the channel
+            <code>im.telepathy1.Client.</code>) of the channel
             handler that should handle the channel, or the empty string
             if the client has no preferred channel handler.</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             The selected handler is non-empty, but is not a syntactically
             correct <tp:type>DBus_Bus_Name</tp:type> or does not start with
-            "<code>org.freedesktop.Telepathy.Client.</code>".
+            "<code>im.telepathy1.Client.</code>".
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The selected handler is temporarily unable to handle these
             channels.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The selected handler is syntactically correct, but will never
             be able to handle these channels (for instance because the channels
@@ -294,7 +281,7 @@
             raised NotImplemented).
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYours">
+        <tp:error name="im.telepathy1.Error.NotYours">
           <tp:docstring>
             At the time that HandleWith was called, this dispatch operation was
             processing an earlier call to HandleWith. The earlier call has
@@ -315,18 +302,18 @@
           internally. If this method is called successfully, the process
           calling this method becomes the handler for the channel, but
           <em>does not</em> have the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
           method called on it.</p>
 
         <p>Clients that call Claim on channels but do not immediately
           close them SHOULD implement the Handler interface and its
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandledChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Handler">HandledChannels</tp:dbus-ref>
           property.</p>
 
         <p>Approvers wishing to reject channels MUST call this method to
           claim ownership of them, and MUST NOT call
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
           on the channels unless/until this method returns successfully.</p>
 
         <tp:rationale>
@@ -336,13 +323,15 @@
             to acknowledge any messages that have already been displayed to
             the user first - ideally, the approver would display and then
             acknowledge the messages - or to call <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref>
+              namespace="im.telepathy1">Channel.Interface.Destroyable1.Destroy</tp:dbus-ref>
             if the destructive behaviour of that method is desired.</p>
 
-          <p>Similarly, an Approver for StreamedMedia channels can close the
-            channel with a reason (e.g. "busy") if desired. The channel
-            dispatcher, which is designed to have no specific knowledge
-            of particular channel types, can't do that.</p>
+          <p>Similarly, an Approver for <tp:dbus-ref
+            namespace="imt1.Channel.Type">Call1</tp:dbus-ref> channels
+            can close the channel with a reason (e.g. "busy") if
+            desired. The channel dispatcher, which is designed to have
+            no specific knowledge of particular channel types, can't
+            do that.</p>
         </tp:rationale>
 
         <p>If successful, this method will cause the ChannelDispatchOperation
@@ -359,7 +348,7 @@
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYours">
+        <tp:error name="im.telepathy1.Error.NotYours">
           <tp:docstring>
             At the time that Claim was called, this dispatch operation was
             processing a call to HandleWith which has now succeeded, so
@@ -380,14 +369,14 @@
         <p>A variant of <tp:member-ref>HandleWith</tp:member-ref> allowing the
           approver to pass an user action time. This timestamp will be passed
           to the Handler when <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+          namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
           is called.</p>
       </tp:docstring>
 
       <arg direction="in" type="s" tp:type="DBus_Bus_Name" name="Handler">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The well-known bus name (starting with
-            <code>org.freedesktop.Telepathy.Client.</code>) of the channel
+            <code>im.telepathy1.Client.</code>) of the channel
             handler that should handle the channel, or the empty string
             if the client has no preferred channel handler.</p>
         </tp:docstring>
@@ -400,20 +389,20 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             The selected handler is non-empty, but is not a syntactically
             correct <tp:type>DBus_Bus_Name</tp:type> or does not start with
-            "<code>org.freedesktop.Telepathy.Client.</code>".
+            "<code>im.telepathy1.Client.</code>".
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The selected handler is temporarily unable to handle these
             channels.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The selected handler is syntactically correct, but will never
             be able to handle these channels (for instance because the channels
@@ -421,7 +410,7 @@
             raised NotImplemented).
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYours">
+        <tp:error name="im.telepathy1.Error.NotYours">
           <tp:docstring>
             At the time that HandleWith was called, this dispatch operation was
             processing an earlier call to HandleWith. The earlier call has
@@ -461,7 +450,7 @@
         <p>This signal MUST NOT be emitted until all Approvers that were
           invoked have returned (successfully or with an error) from
           their <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Approver">AddDispatchOperation</tp:dbus-ref>
           method.</p>
 
         <tp:rationale>
diff --git a/spec/Channel_Dispatcher.xml b/spec/Channel_Dispatcher.xml
index 771d0608..e13467e1 100644
--- a/spec/Channel_Dispatcher.xml
+++ b/spec/Channel_Dispatcher.xml
@@ -21,7 +21,7 @@
       USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.ChannelDispatcher">
+  <interface name="im.telepathy1.ChannelDispatcher">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -32,9 +32,9 @@
 
       <p>If a channel dispatcher is running, it is responsible for dispatching
         new channels on all
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>s
+        <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>s
         created by the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>.
+        <tp:dbus-ref namespace="im.telepathy1">AccountManager</tp:dbus-ref>.
         Connections not created by the AccountManager are outside the scope
         of the channel dispatcher.</p>
 
@@ -48,10 +48,10 @@
 
       <p>The current channel dispatcher is defined to be the process that
         owns the well-known bus name
-        <code>org.freedesktop.Telepathy.ChannelDispatcher</code> on
+        <code>im.telepathy1.ChannelDispatcher</code> on
         the session bus. This process MUST export an object with this
         interface at the object path
-        <code>/org/freedesktop/Telepathy/ChannelDispatcher</code>.</p>
+        <code>/im/telepathy1/ChannelDispatcher</code>.</p>
 
       <p>Until a mechanism exists for making a reasonable automatic choice
         of ChannelDispatcher implementation, implementations SHOULD NOT
@@ -68,13 +68,13 @@
 
       <dl>
         <dt><tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Observer</tp:dbus-ref></dt>
+            namespace="im.telepathy1.Client">Observer</tp:dbus-ref></dt>
         <dd><p>Observers monitor the creation of new channels. This
             functionality can be used for things like message logging.
             All observers are notified simultaneously.</p></dd>
 
         <dt><tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref></dt>
+            namespace="im.telepathy1.Client">Approver</tp:dbus-ref></dt>
         <dd>
           <p>Approvers notify the user that new channels have been created,
             and also select which channel handler will be used for the channel,
@@ -83,7 +83,7 @@
         </dd>
 
         <dt><tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref></dt>
+            namespace="im.telepathy1.Client">Handler</tp:dbus-ref></dt>
         <dd>
           <p>Each new channel or set of channels is passed to exactly one
             handler as its final destination. A typical channel handler is a
@@ -99,169 +99,12 @@
       </tp:docstring>
     </property>
 
-    <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 <var>Preferred_Handler</var> is syntactically invalid or does
-            not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the <var>Account</var> does not exist, or one of the
-            <var>Requested_Properties</var> 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 <var>Preferred_Handler</var> is syntactically invalid or does
-            not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the <var>Account</var> does not exist, or one of the
-            <var>Requested_Properties</var> 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>
+    <method name="CreateChannel"
+            tp:name-for-bindings="Create_Channel">
+      <tp:added version="0.21.5"/>
       <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>
+          <tp:dbus-ref namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
           object, which can be used to continue the request and track its
           success or failure.</p>
 
@@ -281,10 +124,10 @@
         <p>If this method is called for an Account that is disabled, invalid
           or otherwise unusable, no error is signalled until
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest.Proceed</tp:dbus-ref>
           is called, at which point
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest.Failed</tp:dbus-ref>
           is emitted with an appropriate error.</p>
 
         <tp:rationale>
@@ -300,7 +143,7 @@
       <arg direction="in" name="Account" type="o">
         <tp:docstring>
           The
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1">Account</tp:dbus-ref>
           for which the new channel is to be created.
         </tp:docstring>
       </arg>
@@ -310,14 +153,14 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary containing desirable properties. This has the same
             semantics as the corresponding parameter to
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>.
+            <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>.
           </p>
 
           <p>Certain properties will not necessarily make sense in this
             dictionary: for instance,
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
             can only be given if the requester is able to interact with a
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>
             to the desired account.</p>
         </tp:docstring>
       </arg>
@@ -328,10 +171,10 @@
           <p>The time at which user action occurred, or 0 if this channel
             request is for some reason not involving user action.
             The <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelRequest">UserActionTime</tp:dbus-ref>
             property will be set to this value, and it will eventually be
             passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>.</p>
+              namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -339,13 +182,13 @@
         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>)
+            <code>im.telepathy1.Client.</code>)
             of the preferred handler for this
             channel, or an empty string to indicate that any handler would be
             acceptable. The channel dispatcher SHOULD dispatch as many as
             possible of the resulting channels (ideally, all of them)
             to that handler—irrespective of whether that handler's <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+              namespace="im.telepathy1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
             matches the channel—and SHOULD remember the preferred handler
             so it can try to dispatch subsequent channels in the same bundle
             to the same handler.</p>
@@ -357,7 +200,7 @@
 
             <p>This is partly so the channel dispatcher can call
               <tp:dbus-ref
-                namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+                namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
               on it, and partly so the channel dispatcher
               can recover state if it crashes and is restarted.</p>
 
@@ -372,7 +215,7 @@
           <p>If this is a well-known bus name and the handler has the
             Requests interface, the channel dispatcher SHOULD
             call <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref>
+              namespace="im.telepathy1.Client.Interface.Requests">AddRequest</tp:dbus-ref>
             on that Handler after this method has returned.</p>
 
           <tp:rationale>
@@ -383,7 +226,7 @@
 
           <p>This is copied to the ChannelRequest that is returned,
             as the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelRequest">PreferredHandler</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelRequest">PreferredHandler</tp:dbus-ref>
             property.</p>
         </tp:docstring>
 
@@ -398,11 +241,13 @@
         <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>
+              namespace="imt1.ChannelRequest">Hints</tp:dbus-ref>
             property.</p>
 
           <tp:rationale>
-            <p>See the Hints property's documentation for rationale.</p>
+            <p>See the <tp:dbus-ref
+              namespace="imt1.ChannelRequest">Hints</tp:dbus-ref>
+              property's documentation for rationale.</p>
           </tp:rationale>
         </tp:docstring>
       </arg>
@@ -410,16 +255,23 @@
       <arg direction="out" name="Request" type="o">
         <tp:docstring>
           A
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
           object.
         </tp:docstring>
       </arg>
 
+      <arg name="Properties" direction="out" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Immutable properties of the channel request object.</p>
+        </tp:docstring>
+      </arg>
+
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The <var>Preferred_Handler</var> is syntactically invalid or does
-            not start with <code>org.freedesktop.Telepathy.Client.</code>,
+            not start with <code>im.telepathy1.Client.</code>,
             the <var>Account</var> does not exist, or one of the
             <var>Requested_Properties</var> is invalid
           </tp:docstring>
@@ -428,41 +280,35 @@
 
     </method>
 
-    <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>
+    <method name="EnsureChannel"
+            tp:name-for-bindings="Ensure_Channel">
+      <tp:added version="0.21.5"/>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Start a request to ensure that a channel exists, creating it if
           necessary.  This initially just creates a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
           object, which can be used to continue the request and track its
           success or failure.</p>
 
         <p>If this method is called for an Account that is disabled, invalid
           or otherwise unusable, no error is signalled until
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest.Proceed</tp:dbus-ref>
           is called, at which point
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest.Failed</tp:dbus-ref>
           is emitted with an appropriate error.</p>
 
         <tp:rationale>
           <p>The rationale is as for <tp:dbus-ref
-              namespace='org.freedesktop.Telepathy.ChannelDispatcher'>CreateChannelWithHints</tp:dbus-ref>.</p>
+              namespace='im.telepathy1.ChannelDispatcher'>CreateChannel</tp:dbus-ref>.</p>
         </tp:rationale>
       </tp:docstring>
 
       <arg direction="in" name="Account" type="o">
         <tp:docstring>
           The
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1">Account</tp:dbus-ref>
           for which the new channel is to be created.
         </tp:docstring>
       </arg>
@@ -472,14 +318,14 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary containing desirable properties. This has the same
             semantics as the corresponding parameter to
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>.
+            <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>.
           </p>
 
           <p>Certain properties will not necessarily make sense in this
             dictionary: for instance,
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
             can only be given if the requester is able to interact with a
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>
             to the desired account.</p>
         </tp:docstring>
       </arg>
@@ -492,7 +338,7 @@
 
           <p>This parameter is used in the same way as the corresponding
             parameter to
-            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+            <tp:member-ref>CreateChannel</tp:member-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -500,12 +346,12 @@
         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>)
+            <code>im.telepathy1.Client.</code>)
             of the preferred handler for this
             channel, or an empty string to indicate that any handler would be
             acceptable. The behaviour and rationale are the same as for the
             corresponding parameter to
-            <tp:member-ref>CreateChannelWithHints</tp:member-ref>, except
+            <tp:member-ref>CreateChannel</tp:member-ref>, except
             as noted here.</p>
 
           <p>If any new channels are created in response to this
@@ -515,7 +361,7 @@
             so it can try to dispatch subsequent channels in the same bundle
             to the same handler. If the requested channel already exists (that
             is, <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>
+              namespace="im.telepathy1">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>
             returns <code>Yours=False</code>) then the channel dispatcher
             SHOULD re-dispatch the channel to its existing handler, and MUST
             NOT dispatch it to this client (unless it is the existing handler);
@@ -523,11 +369,11 @@
 
           <tp:rationale>
             <p>An address book application, for example, might call <tp:dbus-ref
-                namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
+                namespace='im.telepathy1.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
               to ensure that a text channel with a particular contact is
               displayed to the user; it does not care whether a new channel was
               made. An IM client might call <tp:dbus-ref
-                namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
+                namespace='im.telepathy1.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
               in response to the user double-clicking an entry in the contact
               list, with itself as the <code>Preferred_Handler</code>; if the
               user already has a conversation with that contact in another
@@ -544,23 +390,30 @@
         <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>
+          namespace="imt1.ChannelRequest">Hints</tp:dbus-ref>
           property.</tp:docstring>
       </arg>
 
       <arg direction="out" name="Request" type="o">
         <tp:docstring>
           A
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
           object.
         </tp:docstring>
       </arg>
 
+      <arg name="Properties" direction="out" type="a{sv}"
+        tp:type="Qualified_Property_Value_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Immutable properties of the channel request object.</p>
+        </tp:docstring>
+      </arg>
+
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The <var>Preferred_Handler</var> is syntactically invalid or does
-            not start with <code>org.freedesktop.Telepathy.Client.</code>,
+            not start with <code>im.telepathy1.Client.</code>,
             the <var>Account</var> does not exist, or one of the
             <var>Requested_Properties</var> is invalid
           </tp:docstring>
@@ -576,27 +429,27 @@
       </tp:added>
       <tp:changed version="0.23.2">This method now returns
         <var>Delegated</var> and <var>Not_Delegated</var> instead of nothing.
-        <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Client.Handler">HandleChannels</tp:dbus-ref>
         is now called once per <var>Channel</var> in <var>Channels</var>.
       </tp:changed>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Called by a
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
           to redispatch a bunch of channels it is currently handling.</p>
 
         <p>For each <var>Channel</var> in <var>Channels</var>, if another
-          <tp:dbus-ref namespace="ofdT.Client">Handler</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Client">Handler</tp:dbus-ref>
           can be found,
-          <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Client.Handler">HandleChannels</tp:dbus-ref>
           will be called on it until a
-          <tp:dbus-ref namespace="ofdT.Client">Handler</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Client">Handler</tp:dbus-ref>
           accepts it.</p>
 
         <p>This method returns once all the <var>Channels</var> have either
           been accepted or rejected by Handlers.</p>
 
         <p>If this method fails, the original
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
           is still handling the channels.</p>
 
       </tp:docstring>
@@ -604,7 +457,7 @@
       <arg direction="in" name="Channels" type="ao">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The list of channels to redispatch. The caller has to be the current
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
             of all of these channels
           </p>
         </tp:docstring>
@@ -618,7 +471,7 @@
 
           <p>This parameter is used in the same way as the corresponding
             parameter to
-            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+            <tp:member-ref>CreateChannel</tp:member-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -626,12 +479,12 @@
         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>)
+            <code>im.telepathy1.Client.</code>)
             of the preferred new handler for these
             channels, or an empty string to indicate that any handler would be
             acceptable. The behaviour and rationale are the same as for the
             corresponding parameter to
-            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+            <tp:member-ref>CreateChannel</tp:member-ref>.</p>
 
         </tp:docstring>
       </arg>
@@ -642,7 +495,7 @@
           longer handling these channels.</p>
 
           <p>The client should remove these channels from its
-          <tp:dbus-ref namespace="ofdT.Client.Handler">HandledChannels</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Client.Handler">HandledChannels</tp:dbus-ref>
           property.</p>
         </tp:docstring>
       </arg>
@@ -656,14 +509,14 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The Preferred_Handler is syntactically invalid or does
-            not start with <code>org.freedesktop.Telepathy.Client.</code>.
+            not start with <code>im.telepathy1.Client.</code>.
           </tp:docstring>
         </tp:error>
 
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYours">
+        <tp:error name="im.telepathy1.Error.NotYours">
           <tp:docstring>
             At least one <var>Channel</var> in <var>Channels</var> is not
             currently handled by the caller. No <var>Channel</var> has been
@@ -711,7 +564,7 @@
       </tp:added>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Equivalent of calling
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
         with a <var>Requested_Properties</var> which would result in ensuring
         <var>Channel</var>.</p>
 
@@ -733,12 +586,12 @@
 
           <p>This parameter is used in the same way as the corresponding
             parameter to
-            <tp:member-ref>EnsureChannelWithHints</tp:member-ref>.</p>
+            <tp:member-ref>EnsureChannel</tp:member-ref>.</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The Account does not exist, the Channel does not exist or it
             does not belong to the Account.
@@ -748,27 +601,6 @@
       </tp:possible-errors>
     </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/spec/Channel_Dispatcher_Interface_Messages1.xml b/spec/Channel_Dispatcher_Interface_Messages1.xml
index e768b554..4c0bd0cd 100644
--- a/spec/Channel_Dispatcher_Interface_Messages1.xml
+++ b/spec/Channel_Dispatcher_Interface_Messages1.xml
@@ -22,8 +22,8 @@
   </tp:license>
 
   <interface
-    name="org.freedesktop.Telepathy.ChannelDispatcher.Interface.Messages1">
-    <tp:requires interface="org.freedesktop.Telepathy.ChannelDispatcher"/>
+    name="im.telepathy1.ChannelDispatcher.Interface.Messages1">
+    <tp:requires interface="im.telepathy1.ChannelDispatcher"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>
@@ -44,7 +44,7 @@
     <method name="SendMessage" tp:name-for-bindings="Send_Message">
       <arg direction="in"  name="Account"  type="o">
         <tp:docstring>
-          The <tp:dbus-ref namespace="ofdT">Account</tp:dbus-ref>
+          The <tp:dbus-ref namespace="imt1">Account</tp:dbus-ref>
           through which to communicate.
         </tp:docstring>
       </arg>
@@ -57,24 +57,24 @@
            tp:type="Message_Part[]">
         <tp:docstring>
           The parts of the message, the same as for <tp:dbus-ref
-            namespace="ofdT.Channel.Interface">Messages.SendMessage</tp:dbus-ref>.
+            namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <arg direction="in"  name="Flags"    type="u">
         <tp:docstring>
           Flags influencing how to send the message, the same as for <tp:dbus-ref
-            namespace="ofdT.Channel.Interface">Messages.SendMessage</tp:dbus-ref>.
+            namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <arg direction="out" name="Token"    type="s">
         <tp:docstring>
           An opaque token equivalent to the one returned by <tp:dbus-ref
-            namespace="ofdT.Channel.Interface">Messages.SendMessage</tp:dbus-ref>.
+            namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Submit a message to the server for sending, like the
-          <tp:dbus-ref namespace="ofdT.Channel.Interface">Messages.SendMessage</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref>
           method.</p>
 
         <p>If the <var>Account</var> is connected and a Text channel to the
@@ -84,7 +84,7 @@
         <p>Otherwise, this method creates a channel (connecting the
           Account if appropriate), sends the desired message, and
           closes the channel as if via <tp:dbus-ref
-            namespace="ofdT">Channel.Close</tp:dbus-ref>, without
+            namespace="imt1">Channel.Close</tp:dbus-ref>, without
           acknowledging any messages received on that channel
           during that time.</p>
 
@@ -92,7 +92,7 @@
           closed, a correct connection manager implementation will reopen
           the channel when it is closed, resulting in those "rescued" messages
           being processed by the system's normal <tp:dbus-ref
-            namespace="ofdT.Client">Handler</tp:dbus-ref> for text
+            namespace="imt1.Client">Handler</tp:dbus-ref> for text
           channels. In particular, this deals with the situation where
           a successful or failed delivery report is received
           before the channel is closed.</p>
@@ -111,11 +111,11 @@
           form:</p>
 
         <pre>  {
-    …<tp:dbus-ref namespace="ofdT">Channel.ChannelType</tp:dbus-ref>:
-        …<tp:dbus-ref namespace="ofdT">Channel.Type.Text</tp:dbus-ref>,
-    …<tp:dbus-ref namespace="ofdT">Channel.TargetHandleType</tp:dbus-ref>:
+    …<tp:dbus-ref namespace="imt1">Channel.ChannelType</tp:dbus-ref>:
+        …<tp:dbus-ref namespace="imt1">Channel.Type.Text</tp:dbus-ref>,
+    …<tp:dbus-ref namespace="imt1">Channel.TargetHandleType</tp:dbus-ref>:
         <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,
-    …<tp:dbus-ref namespace="ofdT">Channel.TargetID</tp:dbus-ref>:
+    …<tp:dbus-ref namespace="imt1">Channel.TargetID</tp:dbus-ref>:
     <var>Target_ID</var>
   }</pre>
 
@@ -126,47 +126,47 @@
 
         <p>This method may raise any error that would be raised by the
           <tp:dbus-ref
-            namespace="ofdT.Connection.Interface">Requests.EnsureChannel</tp:dbus-ref>
+            namespace="imt1.Connection.Interface">Requests.EnsureChannel</tp:dbus-ref>
           or <tp:dbus-ref
-            namespace="ofdT.Channel.Interface">Messages.SendMessage</tp:dbus-ref>
+            namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref>
           methods, or signalled by the <tp:dbus-ref
-            namespace="ofdT.ChannelRequest">Failed</tp:dbus-ref>
+            namespace="imt1.ChannelRequest">Failed</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The connection manager does not implement Text channels
             that communicate with a named contact.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
+        <tp:error name="im.telepathy1.Error.InvalidHandle">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             The <var>Target_ID</var> was not syntactically valid for the
             <var>Account</var>'s protocol.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
+        <tp:error name="im.telepathy1.Error.InvalidHandle">
           <tp:docstring>
             The requested message is malformed and cannot be sent.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Offline">
+        <tp:error name="im.telepathy1.Error.Offline">
           <tp:docstring>
             The requested channel cannot be created because the target is
             offline.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The requested channel cannot be created, but in
             principle, a similar request might succeed in future.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Channel_Dispatcher_Interface_Operation_List.xml b/spec/Channel_Dispatcher_Interface_Operation_List1.xml
index be06f5ca..f2d365a7 100644
--- a/spec/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/spec/Channel_Dispatcher_Interface_Operation_List1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Dispatcher_Interface_Operation_List"
+<node name="/Channel_Dispatcher_Interface_Operation_List1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2008-2009 Collabora Ltd.</tp:copyright>
@@ -21,10 +21,10 @@
       USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList">
+  <interface name="im.telepathy1.ChannelDispatcher.Interface.OperationList1">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.ChannelDispatcher"/>
+    <tp:requires interface="im.telepathy1.ChannelDispatcher"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface allows users of the ChannelDispatcher to enumerate
@@ -51,7 +51,7 @@
         <tp:docstring>
           The object path of the
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>.
+            namespace="im.telepathy1">ChannelDispatchOperation</tp:dbus-ref>.
         </tp:docstring>
       </tp:member>
 
@@ -71,10 +71,10 @@
 
           <p>Each dictionary MUST contain at least the following keys:</p>
           <ul>
-            <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Interfaces</tp:dbus-ref></li>
-            <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Connection</tp:dbus-ref></li>
-            <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Account</tp:dbus-ref></li>
-            <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.PossibleHandlers</tp:dbus-ref></li>
+            <li><tp:dbus-ref>im.telepathy1.ChannelDispatchOperation.Interfaces</tp:dbus-ref></li>
+            <li><tp:dbus-ref>im.telepathy1.ChannelDispatchOperation.Connection</tp:dbus-ref></li>
+            <li><tp:dbus-ref>im.telepathy1.ChannelDispatchOperation.Account</tp:dbus-ref></li>
+            <li><tp:dbus-ref>im.telepathy1.ChannelDispatchOperation.PossibleHandlers</tp:dbus-ref></li>
           </ul>
         </tp:docstring>
       </tp:member>
@@ -118,7 +118,7 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         Emitted when a dispatch operation finishes (i.e. exactly once per
         emission of <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Finished</tp:dbus-ref>).
+          namespace="im.telepathy1">ChannelDispatchOperation.Finished</tp:dbus-ref>).
 
         <tp:rationale>
           Strictly speaking this is redundant with
diff --git a/spec/Channel_Future.xml b/spec/Channel_Future.xml
deleted file mode 100644
index 5bbca17b..00000000
--- a/spec/Channel_Future.xml
+++ /dev/null
@@ -1,68 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Future"
-  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright (C) 2008 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.FUTURE"
-    tp:causes-havoc="a staging area for future Channel functionality">
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>This interface contains functionality which we intend to incorporate
-        into the <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref> interface
-        in future. It should be considered to
-        be conceptually part of the core Channel interface, but without
-        API or ABI guarantees.</p>
-
-      <tp:rationale>
-        <p>If we add new functionality to the Channel interface, libraries
-          that use generated code (notably telepathy-glib) will have it as
-          part of their ABI forever, meaning we can't make incompatible
-          changes. By using this interface as a staging area for future
-          Channel functionality, we can try out new properties, signals
-          and methods as application-specific extensions, then merge them
-          into the core Channel interface when we have enough implementation
-          experience to declare them to be stable.</p>
-
-        <p>The name is by analogy to Python's <code>__future__</code>
-          pseudo-module.</p>
-      </tp:rationale>
-    </tp:docstring>
-
-    <property name="Bundle" tp:name-for-bindings="Bundle"
-      type="o" access="read">
-      <tp:added version="0.17.9">(in Channel.FUTURE
-        pseudo-interface)</tp:added>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle.DRAFT</tp:dbus-ref>
-          to which this channel belongs.</p>
-
-        <p>A channel's Bundle property can never change.</p>
-
-        <p>Older connection managers might not have this property. Clients
-          (particularly the channel dispatcher) SHOULD recover by considering
-          each channel to be in a bundle containing only that channel,
-          distinct from all other bundles, which has no additional
-          interfaces.</p>
-      </tp:docstring>
-    </property>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Handler.xml b/spec/Channel_Handler.xml
deleted file mode 100644
index edf975e4..00000000
--- a/spec/Channel_Handler.xml
+++ /dev/null
@@ -1,78 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Handler" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright (C) 2007-2008 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.ChannelHandler">
-    <tp:deprecated version="0.17.23">
-      Clients should implement <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>
-      instead.
-    </tp:deprecated>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>An interface exported by Mission Control 4 client applications which
-        are able to handle incoming channels.</p>
-    </tp:docstring>
-    <tp:added version="0.17.0"/>
-
-    <method name="HandleChannel" tp:name-for-bindings="Handle_Channel">
-      <tp:docstring>
-        Called when a channel handler should handle a new channel.
-      </tp:docstring>
-      <tp:added version="0.17.0"/>
-
-      <arg direction="in" type="s" name="Bus_Name" tp:type="DBus_Bus_Name">
-        <tp:docstring>
-          The bus name of the connection and channel
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" type="o" name="Connection">
-        <tp:docstring>
-          The object-path of the connection that owns the channel
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" type="s" tp:type="DBus_Interface" name="Channel_Type">
-        <tp:docstring>
-          The channel type
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" type="o" name="Channel">
-        <tp:docstring>
-          The object-path of the channel
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" type="u" tp:type="Handle_Type" name="Handle_Type">
-        <tp:docstring>The type of the handle that the channel communicates
-          with, or 0 if there is no associated handle</tp:docstring>
-      </arg>
-
-      <arg direction="in" type="u" tp:type="Handle" name="Handle">
-        <tp:docstring>The handle that the channel communicates with,
-          or 0 if there is no associated handle</tp:docstring>
-      </arg>
-
-      <!-- FIXME: possible errors? -->
-    </method>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
-
diff --git a/spec/Channel_Interface_Addressing.xml b/spec/Channel_Interface_Addressing1.xml
index 2524ac7f..9daada9c 100644
--- a/spec/Channel_Interface_Addressing.xml
+++ b/spec/Channel_Interface_Addressing1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Addressing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Addressing1" 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
@@ -16,7 +16,7 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Addressing1"
+  <interface name="im.telepathy1.Channel.Interface.Addressing1"
              tp:causes-havoc="experimental">
     <tp:added version="0.19.12">(as draft)</tp:added>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -54,7 +54,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:rationale>
           <p>While this seems redundant, since the scheme is included in
             <tp:member-ref>TargetURI</tp:member-ref>, it exists for constructing
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+            <tp:dbus-ref namespace="im.telepathy1.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
             that support a limited set of URI schemes.</p>
         </tp:rationale>
 
@@ -72,10 +72,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>If this is present in a channel request,
           <tp:member-ref>TargetVCardField</tp:member-ref>
           MUST be present, and
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>,
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>,
           and <tp:member-ref>TargetURI</tp:member-ref> MUST NOT be present.
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           must either not be present or set to Handle_Type_Contact.
           The request MUST fail with error InvalidHandle, without
           side-effects, if the requested vCard address cannot be found.</p>
@@ -92,11 +92,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>If this is present in a channel request,
           <tp:member-ref>TargetVCardField</tp:member-ref>
           MUST be present, and
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>,
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>,
           and <tp:member-ref>TargetVCardAddress</tp:member-ref> MUST NOT be
           present.
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           must either not be present or set to Handle_Type_Contact.
           The request MUST fail with error InvalidHandle, without
           side-effects, if the requested vCard address cannot be found.</p>
diff --git a/spec/Channel_Interface_Anonymity.xml b/spec/Channel_Interface_Anonymity1.xml
index ef3a3b85..f98311fd 100644
--- a/spec/Channel_Interface_Anonymity.xml
+++ b/spec/Channel_Interface_Anonymity1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Anonymity"
+<node name="/Channel_Interface_Anonymity1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2008-2010 Nokia Corporation</tp:copyright>
@@ -21,13 +21,13 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Anonymity">
+  <interface name="im.telepathy1.Channel.Interface.Anonymity1">
     <tp:added version="0.19.7">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Interface for requesting the anonymity modes of a channel
-        (as defined in <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Anonymity</tp:dbus-ref>).</p>
+        (as defined in <tp:dbus-ref namespace="im.telepathy1"
+          >Connection.Interface.Anonymity1</tp:dbus-ref>).</p>
     </tp:docstring>
 
     <property name="AnonymityModes" type="u" tp:type="Anonymity_Mode_Flags"
diff --git a/spec/Channel_Interface_Call_State.xml b/spec/Channel_Interface_Call_State.xml
deleted file mode 100644
index b0aea591..00000000
--- a/spec/Channel_Interface_Call_State.xml
+++ /dev/null
@@ -1,147 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Call_State" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2008 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2008 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.CallState">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>An interface for streamed media channels that can indicate call
-        progress or call states. The presence of this interface is no guarantee
-        that call states will actually be signalled (for instance, SIP
-        implementations are not guaranteed to generate status 180 Ringing, so a
-        call can be accepted without the Ringing flag ever having been set;
-        similarly, Jingle implementations are not guaranteed to send
-        <code>&lt;ringing/&gt;</code>).</p>
-
-      <p>To notify the other participant in the call that they are on hold,
-        see <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Hold</tp:dbus-ref>.</p>
-    </tp:docstring>
-    <tp:added version="0.17.2"/>
-
-    <method name="GetCallStates" tp:name-for-bindings="Get_Call_States">
-      <tp:docstring>
-        Get the current call states for all contacts involved in this call.
-      </tp:docstring>
-
-      <arg tp:type="Channel_Call_State_Map" name="States" direction="out"
-        type="a{uu}">
-        <tp:docstring>
-          The current call states. Participants where the call state flags
-          would be 0 (all unset) may be omitted from this mapping.
-        </tp:docstring>
-      </arg>
-    </method>
-
-    <signal name="CallStateChanged" tp:name-for-bindings="Call_State_Changed">
-      <tp:docstring>
-        Emitted when the state of a member of the channel has changed.
-      </tp:docstring>
-
-      <arg name="Contact" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          An integer handle for the contact.
-        </tp:docstring>
-      </arg>
-
-      <arg name="State" type="u" tp:type="Channel_Call_State_Flags">
-        <tp:docstring>
-          The new state for this contact.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <tp:mapping name="Channel_Call_State_Map">
-      <tp:docstring>
-        A map from contacts to call states.
-      </tp:docstring>
-
-      <tp:member name="Contact" type="u" tp:type="Contact_Handle">
-        <tp:docstring>A contact involved in this call.</tp:docstring>
-      </tp:member>
-
-      <tp:member name="State" type="u" tp:type="Channel_Call_State_Flags">
-        <tp:docstring>State flags for the given contact.</tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <tp:flags name="Channel_Call_State_Flags" value-prefix="Channel_Call_State" type="u">
-      <tp:docstring>
-        A set of flags representing call states.
-      </tp:docstring>
-
-      <tp:flag suffix="Ringing" value="1">
-        <tp:docstring>
-          The contact has been alerted about the call but has not responded
-          (e.g. 180 Ringing in SIP).
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Queued" value="2">
-        <tp:docstring>
-          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).
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Held" value="4">
-        <tp:docstring>
-          The contact has placed the call on hold, and will not receive
-          media from the local user or any other participants until they
-          unhold the call again.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Forwarded" value="8">
-        <tp:docstring>
-          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.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="In_Progress" value="16">
-        <tp:docstring>
-          Progress has been made in placing the outgoing call, but the
-          destination contact may not have been made aware of the call yet
-          (so the Ringing state is not appropriate). This corresponds to SIP's
-          status code 183 Session Progress, and could be used when the
-          outgoing call has reached a gateway, for instance.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Conference_Host" value="32">
-        <tp:added version='0.19.11'/>
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          This contact has merged this call into a conference. Note that GSM
-          provides a notification when the remote party merges a call into a
-          conference, but not when it is split out again; thus, this flag can
-          only indicate that the call has been part of a conference at some
-          point. If a GSM connection manager receives a notification that a
-          call has been merged into a conference a second time, it SHOULD
-          represent this by clearing and immediately re-setting this flag on
-          the remote contact.
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Captcha_Authentication.xml b/spec/Channel_Interface_Captcha_Authentication1.xml
index 27b1e0cf..bba0cb2c 100644
--- a/spec/Channel_Interface_Captcha_Authentication.xml
+++ b/spec/Channel_Interface_Captcha_Authentication1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Captcha_Authentication"
+<node name="/Channel_Interface_Captcha_Authentication1"
       xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2010-2012 Collabora Limited </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,20 +17,20 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.CaptchaAuthentication1">
+  <interface name="im.telepathy1.Channel.Interface.CaptchaAuthentication1">
     <tp:added version="0.25.2">(version 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
       value="true"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel interface for captcha authentication.
         When this interface appears on a <tp:dbus-ref
-          namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+          namespace="imt1.Channel.Type">ServerAuthentication1</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
+        this interface does not REQUIRE <tp:dbus-ref namespace="imt1.Channel.Type"
+        >ServerAuthentication1</tp:dbus-ref> to allow for a potential future
         Channel.Type.PeerAuthentication interface.</p>
 
       <p>In any protocol that requires a captcha, the connection manager can
@@ -39,9 +39,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         interactively.</p>
 
       <p>For channels managed by a
-        <tp:dbus-ref namespace="ofdT">ChannelDispatcher</tp:dbus-ref>,
+        <tp:dbus-ref namespace="imt1">ChannelDispatcher</tp:dbus-ref>,
         only the channel's <tp:dbus-ref
-          namespace="ofdT.Client">Handler</tp:dbus-ref> may call the
+          namespace="imt1.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>
 
@@ -213,11 +213,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <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>
+            namespace="imt1.Channel.Type">ServerAuthentication1</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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </property>
@@ -231,14 +231,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>.</p>
 
         <p>If this interface appears on a <tp:dbus-ref
-            namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+            namespace="imt1.Channel.Type">ServerAuthentication1</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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </property>
@@ -288,14 +288,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             Either the state is not Local_Pending or Try_Again, or it has
             already been called and
             <tp:member-ref>CanRetryCaptcha</tp:member-ref> is False.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -335,13 +335,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The state is not in Local_Pending or
             <tp:member-ref>GetCaptchas</tp:member-ref> had never been called.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -359,12 +359,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The state is not in Local_Pending.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -383,7 +383,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           by the Handler. This message SHOULD NOT be sent to the remote
           server, but SHOULD be copied into the 'debug-message' field
           of the <tp:member-ref>CaptchaErrorDetails</tp:member-ref> and
-          <tp:dbus-ref namespace="ofdT.Connection">ConnectionError</tp:dbus-ref>.
+          <tp:dbus-ref namespace="imt1.Connection">ConnectionError</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -392,7 +392,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           to close the channel.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The current state is Failed.
           </tp:docstring>
@@ -431,12 +431,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           If this is used, the <tp:member-ref>CaptchaError</tp:member-ref>
           SHOULD be set to <tp:error-ref>CaptchaNotSupported</tp:error-ref>.
           This SHOULD also be used if
-          <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref> is called
+          <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref> is called
           before <tp:member-ref>CancelCaptcha</tp:member-ref>.
           <tp:rationale>
             If no Handler supports captcha channels,
             the ChannelDispatcher will just call
-            <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref>,
+            <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref>,
             because it has no knowledge of specific channel types.
           </tp:rationale>
         </tp:docstring>
@@ -458,7 +458,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           a local action. Call <tp:member-ref>AnswerCaptchas</tp:member-ref>
           to go to the Remote_Pending state, or call
           <tp:member-ref>CancelCaptcha</tp:member-ref> followed by 
-          <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref>
           to give up.
         </tp:docstring>
       </tp:enumvalue>
@@ -468,7 +468,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           a response from the server. Wait for a reply from the server,
           which will result in the Succeeded, Try_Again, or Failed state,
           or call <tp:member-ref>CancelCaptcha</tp:member-ref> followed by
-          <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref>
           to give up.
         </tp:docstring>
       </tp:enumvalue>
@@ -477,7 +477,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           Everyone is happy. Connection to the server will proceed as soon as
           this state is reached. There is nothing useful to do in this state
           except to call <tp:dbus-ref
-            namespace="ofdT.Channel">Close</tp:dbus-ref>
+            namespace="imt1.Channel">Close</tp:dbus-ref>
           to close the channel.
         </tp:docstring>
       </tp:enumvalue>
@@ -487,7 +487,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           Call <tp:member-ref>GetCaptchas</tp:member-ref> again to get
           a new captcha, or
           <tp:member-ref>CancelCaptcha</tp:member-ref> followed by
-          <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref>
+          <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref>
           to give up.
         </tp:docstring>
       </tp:enumvalue>
@@ -495,7 +495,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring>
           Authentication has failed in some way. There is nothing
           useful to do in this state except to close the channel with
-          <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref>.
+          <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref>.
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
diff --git a/spec/Channel_Interface_Chat_State.xml b/spec/Channel_Interface_Chat_State1.xml
index 27515d2e..f2f1dabe 100644
--- a/spec/Channel_Interface_Chat_State.xml
+++ b/spec/Channel_Interface_Chat_State1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Chat_State" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Chat_State1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2007 Collabora Limited </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
     <p>This library is free software; you can redistribute it and/or
@@ -16,8 +16,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.ChatState">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
+  <interface name="im.telepathy1.Channel.Interface.ChatState1">
+    <tp:requires interface="im.telepathy1.Channel.Type.Text"/>
 
     <tp:mapping name="Chat_State_Map">
       <tp:added version="0.19.7"/>
@@ -39,26 +39,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>Contacts in this channel, but who are not listed in this map,
           may be assumed to be in the Inactive state.</p>
-
-        <p>In implementations that do not have this property, its value may be
-          assumed to be empty until a
-          <tp:member-ref>ChatStateChanged</tp:member-ref> signal indicates
-          otherwise.</p>
-
-        <tp:rationale>
-          <p>This property was not present in older versions of telepathy-spec,
-            because chat states in XMPP are not state-recoverable (if you
-            miss the change notification signal, there's no way to know the
-            state). However, this property still allows clients to recover
-            state changes that were seen by the CM before the client started
-            to deal with the channel.</p>
-
-          <p>In CMs that follow older spec versions, assuming Inactive will
-            mean that initial chat states will always be assumed to be
-            Inactive, which is the best we can do. XEP 0085 specifies
-            Inactive as the "neutral" state to be assumed unless told
-            otherwise.</p>
-        </tp:rationale>
       </tp:docstring>
     </property>
 
@@ -73,9 +53,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         has changed.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
     <signal name="ChatStateChanged" tp:name-for-bindings="Chat_State_Changed">
diff --git a/spec/Channel_Interface_Conference.xml b/spec/Channel_Interface_Conference1.xml
index abda59ee..41a833c8 100644
--- a/spec/Channel_Interface_Conference.xml
+++ b/spec/Channel_Interface_Conference1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Conference"
+<node name="/Channel_Interface_Conference1"
   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>
@@ -20,11 +20,11 @@
       02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Conference">
+    name="im.telepathy1.Channel.Interface.Conference1">
     <tp:added version="0.19.13">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:requires
-      interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
+      interface="im.telepathy1.Channel.Interface.Group1"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can "continue
@@ -44,13 +44,13 @@
 
       <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>,
+        namespace="im.telepathy1.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>,
+          namespace="im.telepathy1.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
@@ -60,15 +60,15 @@
         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>
+        namespace='imt1.Channel.Interface'>MergeableConference1</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
+        namespace='imt1.Channel.Interface'>Splittable1</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
+          namespace="im.telepathy1.Channel.Interface"
+          >Group1</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>
@@ -114,8 +114,8 @@
         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,
+        <code><tp:dbus-ref namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+            ...<tp:dbus-ref namespace="im.telepathy1.Channel">ChannelType</tp:dbus-ref>: ...Call,
             ...<tp:member-ref>InitialChannels</tp:member-ref>: [C1, C2]
           })</code>
       </blockquote>
@@ -123,7 +123,7 @@
       <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>
+          namespace="imt1.Channel.Interface.Splittable1">Split</tp:dbus-ref>
         from the conference, or the conference ends.)</p>
 
       <p>An XMPP 1-1 conversation <var>C3</var> (with
@@ -153,10 +153,10 @@
         the room), call:</p>
 
       <blockquote>
-        <code><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>({
+        <code><tp:dbus-ref namespace="im.telepathy1.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:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>: ...Room,
+            ...<tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>: 'telepathy@conf.example.com',
             ...<tp:member-ref>InitialChannels</tp:member-ref>: [C3]
           })</code>
       </blockquote>
@@ -189,7 +189,7 @@
           (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
+          namespace="im.telepathy1.Channel">Close</tp:dbus-ref> the
           old 1-1 channel; it'll respawn if necessary.</p>
       </tp:rationale>
 
@@ -204,7 +204,7 @@
         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'
+      <h4>Sample <tp:dbus-ref namespace='imt1.Connection.Interface.Requests'
                              >RequestableChannelClasses</tp:dbus-ref></h4>
 
       <p>A GSM connection might advertise the following channel class for
@@ -213,11 +213,11 @@
       <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/>
+    ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='imt1.Channel.Type'>Call1</tp:dbus-ref><br/>
   },<br/>
   Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
-              <tp:dbus-ref namespace='ofdT.Channel.Type.StreamedMedia'
+              <tp:dbus-ref namespace='imt1.Channel.Type.Call1'
                           >InitialAudio</tp:dbus-ref>
             ]<br/>
 )
@@ -235,8 +235,8 @@
       <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/>
+    ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='imt1.Channel.Type'>Text</tp:dbus-ref><br/>
   },<br/>
   Allowed = [ <tp:member-ref>InitialChannels</tp:member-ref>,
               <tp:member-ref>InitialInviteeHandles</tp:member-ref>,
@@ -245,13 +245,13 @@
             ]<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>:
+    ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='imt1.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='imt1.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/>
+  Allowed = [ <tp:dbus-ref namespace='imt1.Channel'>TargetHandle</tp:dbus-ref>,
+              <tp:dbus-ref namespace='imt1.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>,
@@ -272,11 +272,11 @@
       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
+            namespace="im.telepathy1">Channel</tp:dbus-ref>s that
           are continued by this conference, which have the same <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
+              namespace="im.telepathy1.Channel"
               >ChannelType</tp:dbus-ref> as this one, but with <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
+              namespace="im.telepathy1.Channel"
               >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
 
         <p>This property MUST NOT be requestable; instead, the
@@ -288,7 +288,7 @@
             <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>
+            namespace="im.telepathy1.Channel.Interface">Group1.Members</tp:dbus-ref>
             and some hypothetical ID version of that property.</p>
        </tp:rationale>
 
@@ -311,12 +311,12 @@
 
       <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
+          namespace="imt1.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
+            namespace="imt1.Channel.Interface">Group1</tp:dbus-ref> interface
           of this channel.</tp:docstring>
       </arg>
 
@@ -331,11 +331,11 @@
         <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>
+            namespace="im.telepathy1.Channel.Interface"
+            >Splittable1.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
+          namespace='imt1.Channel'>Closed</tp:dbus-ref> should be emitted
           before this signal.</p>
       </tp:docstring>
 
@@ -348,8 +348,8 @@
         <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:dbus-ref namespace="imt1.Channel.Interface.Group1"
+            >MembersChanged</tp:dbus-ref>, with the same semantics.
         </tp:docstring>
       </arg>
     </signal>
@@ -366,7 +366,7 @@
           <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'
+            namespace='imt1.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>
@@ -385,8 +385,8 @@
           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>
+            namespace="im.telepathy1.Channel.Interface"
+            >MergeableConference1.Merge</tp:dbus-ref> on them.</p>
 
         <tp:rationale>
           <p>In Jingle, nothing special will happen to merged calls. UIs MAY
@@ -396,8 +396,8 @@
 
           <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>
+            call using <tp:dbus-ref namespace="im.telepathy1"
+              >Channel.Interface.Splittable1.Split</tp:dbus-ref>.</p>
         </tp:rationale>
 
         <p>Depending on the protocol, it might be signalled to remote users
@@ -428,7 +428,7 @@
           (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"
+            namespace="im.telepathy1.Connection.Interface.Requests"
             >RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property
           SHOULD NOT be requestable, and its value SHOULD always be the empty
           list.</p>
@@ -442,8 +442,8 @@
 
         <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:dbus-ref namespace="im.telepathy1.Channel.Interface"
+            >Group1.AddMembers</tp:dbus-ref>(InitialInviteeHandles,
           <tp:member-ref>InvitationMessage</tp:member-ref>) immediately after
           the channel was created.</p>
 
@@ -454,8 +454,8 @@
         </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
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface"
+            >Group1.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>
 
@@ -521,7 +521,7 @@
 
         <p>This property SHOULD be requestable, and appear in the allowed
           properties in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+            namespace="im.telepathy1.Connection.Interface.Requests"
             >RequestableChannelClasses</tp:dbus-ref>, in protocols where
           invitations can have an accompanying text message.</p>
 
@@ -546,9 +546,9 @@
           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>.
+          namespace='imt1.Channel.Interface'>Group1.GroupFlags</tp:dbus-ref>.
           The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Interface">Group1.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>
@@ -577,13 +577,13 @@
         <blockquote>
           <code>{<br/>
             ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>:
+              namespace="imt1.Channel.Interface">Group1.GroupFlags</tp:dbus-ref>:
                 Channel_Specific_Handles | (other flags),<br/>
             ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>:
+              namespace="imt1.Channel.Interface">Group1.Members</tp:dbus-ref>:
                 [self_handle, s, j],<br/>
             ...<tp:dbus-ref
-              namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>:
+              namespace="imt1.Channel.Interface">Group1.HandleOwners</tp:dbus-ref>:
                 { s: h, j: h },<br/>
             ...<tp:member-ref>InitialChannels</tp:member-ref>:
                 ['/call/to/simon', '/call/to/jonny'],<br/>
diff --git a/spec/Channel_Interface_Credentials_Storage.xml b/spec/Channel_Interface_Credentials_Storage1.xml
index e44b13e3..0f5226a1 100644
--- a/spec/Channel_Interface_Credentials_Storage.xml
+++ b/spec/Channel_Interface_Credentials_Storage1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Credentials_Storage"
+<node name="/Channel_Interface_Credentials_Storage1"
       xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2011 Collabora Limited </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,10 +17,10 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.CredentialsStorage.DRAFT"
+  <interface name="im.telepathy1.Channel.Interface.CredentialsStorage1"
     tp:causes-havoc="experimental">
     <tp:added version="0.21.10">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication"/>
+    <tp:requires interface="im.telepathy1.Channel.Interface.SASLAuthentication1"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel interface for SASL authentication channels that can save the
         credentials in the connection manager.</p>
@@ -31,10 +31,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
       <p>In practice, this interface should only be implemented by connection
         managers that implement the <tp:dbus-ref
-          namespace="ofdT">ConnectionManager.Interface.AccountStorage.DRAFT</tp:dbus-ref>
+          namespace="imt1">ConnectionManager.Interface.AccountStorage1</tp:dbus-ref>
         interface. To clear a password that has been saved in this manner, a
         client should call <tp:dbus-ref
-          namespace="ofdT.ConnectionManager.Interface">AccountStorage.DRAFT.ForgetCredentials</tp:dbus-ref>
+          namespace="imt1.ConnectionManager.Interface">AccountStorage1.ForgetCredentials</tp:dbus-ref>
         on the Account.</p>
     </tp:docstring>
 
@@ -51,7 +51,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>If credentials have been stored in this way, the client SHOULD NOT
           attempt to store the credentials locally in a keyring.</p>
         <p>This method MUST be called before <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication">AcceptSASL</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Interface.SASLAuthentication1">AcceptSASL</tp:dbus-ref>
           is called or it will have no effect.</p>
       </tp:docstring>
     </method>
diff --git a/spec/Channel_Interface_DTMF.xml b/spec/Channel_Interface_DTMF1.xml
index 00e3a549..0222dd7a 100644
--- a/spec/Channel_Interface_DTMF.xml
+++ b/spec/Channel_Interface_DTMF1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_DTMF" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_DTMF1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>
   <tp:copyright>Copyright © 2006 INdT</tp:copyright>
@@ -18,36 +18,35 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.DTMF">
-    <tp:xor-requires>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
-    </tp:xor-requires>
+  <interface name="im.telepathy1.Channel.Interface.DTMF1">
+    <tp:requires interface="im.telepathy1.Channel.Type.Call1"/>
 
     <tp:changed version="0.25.2">The only part of this spec that should
     be used with a Call1 channel is the "InitialTones" property.
     </tp:changed>
 
-    <tp:changed version="0.19.6">The <tp:type>Stream_ID</tp:type>s in this
+    <tp:changed version="0.19.6">The Stream_IDs in this
       interface can now be ignored by CMs.
     </tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      An interface that gives a Channel the ability to send DTMF events over
-      audio streams which have been established using the StreamedMedia channel
-      type. The event codes used are in common with those defined in <a
-      href="http://www.rfc-editor.org/rfc/rfc4733.txt">RFC4733</a>, and are
-      listed in the <tp:type>DTMF_Event</tp:type> enumeration.
+      An interface that gives a Channel the ability to send DTMF
+      events over audio streams which have been established using the
+      <tp:dbus-ref namespace="imt1.Channel.Type">Call1</tp:dbus-ref>
+      channel type. The event codes used are in common with those
+      defined in <a
+      href="http://www.rfc-editor.org/rfc/rfc4733.txt">RFC4733</a>,
+      and are listed in the <tp:type>DTMF_Event</tp:type> enumeration.
     </tp:docstring>
 
     <method name="StartTone" tp:name-for-bindings="Start_Tone">
       <tp:changed version="0.19.6">The <var>Stream_ID</var> parameter became
         vestigial.</tp:changed>
-      <arg direction="in" name="Stream_ID" type="u" tp:type="Stream_ID">
-        <tp:docstring>A stream ID as defined in the StreamedMedia channel
-        type. This argument is included for backwards compatibility and MUST
-        be ignored by the implementations - the tone SHOULD be sent to all
-        eligible streams in the channel.</tp:docstring>
+      <arg direction="in" name="Stream_ID" type="u">
+        <tp:docstring>This argument is included for backwards
+        compatibility and MUST be ignored by the implementations - the
+        tone SHOULD be sent to all eligible streams in the
+        channel.</tp:docstring>
       </arg>
       <arg direction="in" name="Event" type="y" tp:type="DTMF_Event">
         <tp:docstring>A numeric event code from the DTMF_Event enum.</tp:docstring>
@@ -70,19 +69,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           be called if no DTMF tones are already being played.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The given stream ID was invalid. Deprecated, since stream IDs
             are ignored.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             There are no eligible audio streams.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy">
+        <tp:error name="im.telepathy1.Error.ServiceBusy">
           <tp:docstring>
             DTMF tones are already being played.
           </tp:docstring>
@@ -93,11 +92,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <method name="StopTone" tp:name-for-bindings="Stop_Tone">
       <tp:changed version="0.19.6">The <var>Stream_ID</var> parameter became
         vestigial.</tp:changed>
-      <arg direction="in" name="Stream_ID" type="u" tp:type="Stream_ID">
-        <tp:docstring>A stream ID as defined in the StreamedMedia channel
-        type. This argument is included for backwards compatibility and MUST
-        be ignored by the implementations - the sending SHOULD be stoped in
-        all eligible streams in the channel.</tp:docstring>
+      <arg direction="in" name="Stream_ID" type="u">
+        <tp:docstring>This argument is included for backwards
+        compatibility and MUST be ignored by the implementations - the
+        sending SHOULD be stoped in all eligible streams in the
+        channel.</tp:docstring>
       </arg>
 
       <tp:docstring>
@@ -114,14 +113,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The given stream ID was invalid. Deprecated, since stream IDs
             are ignored.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             Continuous tones are not supported by this stream. Deprecated,
             since stream IDs are ignored.
@@ -179,18 +178,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           be called if no DTMF tones are already being played.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError" />
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The supplied Tones string was invalid.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             There are no eligible audio streams.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy">
+        <tp:error name="im.telepathy1.Error.ServiceBusy">
           <tp:docstring>
             DTMF tones are already being played.
           </tp:docstring>
diff --git a/spec/Channel_Interface_Destroyable.xml b/spec/Channel_Interface_Destroyable1.xml
index ce559232..e373bf5d 100644
--- a/spec/Channel_Interface_Destroyable.xml
+++ b/spec/Channel_Interface_Destroyable1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Destroyable"
+<node name="/Channel_Interface_Destroyable1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
@@ -22,17 +22,17 @@
   </tp:license>
 
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Destroyable">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    name="im.telepathy1.Channel.Interface.Destroyable1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.17.14">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface exists to support channels where
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>
+          namespace="im.telepathy1">Channel.Close</tp:dbus-ref>
         is insufficiently destructive. At the moment this means
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Channel.Type.Text</tp:dbus-ref>,
+          namespace="im.telepathy1">Channel.Type.Text</tp:dbus-ref>,
         but the existence of this interface means that unsupported channels
         can be terminated in a non-channel-type-specific way.</p>
     </tp:docstring>
@@ -55,12 +55,12 @@
 
         <p>Most clients SHOULD call
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>
+            namespace="im.telepathy1">Channel.Close</tp:dbus-ref>
           instead. However, if a client explicitly intends to destroy the
           channel with possible loss of data, it SHOULD call this method
           if this interface is supported (according to the
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.Interfaces</tp:dbus-ref>
+            namespace="im.telepathy1">Channel.Interfaces</tp:dbus-ref>
           property), falling back to Close if not.</p>
 
         <p>In particular, channel dispatchers SHOULD use this method if
diff --git a/spec/Channel_Interface_File_Transfer_Metadata.xml b/spec/Channel_Interface_File_Transfer_Metadata1.xml
index 4d2d728d..26d3374b 100644
--- a/spec/Channel_Interface_File_Transfer_Metadata.xml
+++ b/spec/Channel_Interface_File_Transfer_Metadata1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_File_Transfer_Metadata"
+<node name="/Channel_Interface_File_Transfer_Metadata1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2011 Collabora Ltd.</tp:copyright>
 
@@ -21,8 +21,8 @@
   </tp:license>
 
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.FileTransfer.Metadata">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.FileTransfer"/>
+    name="im.telepathy1.Channel.Interface.FileTransfer.Metadata1">
+    <tp:requires interface="im.telepathy1.Channel.Type.FileTransfer1"/>
     <tp:added version="0.25.0"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -48,9 +48,9 @@
         <p>A string representing the service name that will be used
           over the file transfer channel. This property is equivalent
           to the <tp:dbus-ref
-            namespace="ofdT">Channel.Type.DBusTube.ServiceName</tp:dbus-ref>
+            namespace="imt1">Channel.Type.DBusTube1.ServiceName</tp:dbus-ref>
           and <tp:dbus-ref
-            namespace="ofdT">Channel.Type.StreamTube.Service</tp:dbus-ref>
+            namespace="imt1">Channel.Type.StreamTube1.Service</tp:dbus-ref>
           properties. If no service name is given then this property
           will be the empty string.</p>
       </tp:docstring>
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group1.xml
index 890e84eb..ffe0af3e 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Group" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Group1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2005-2009 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright>
   <tp:copyright>Copyright © 2006 INdT</tp:copyright>
@@ -18,8 +18,10 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Group">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Interface.Group1">
+    <tp:requires interface="im.telepathy1.Channel"/>
+    <tp:changed version="0.99.1">Deprecated methods, signals, and
+      properties have all been removed.</tp:changed>
 
     <tp:struct name="Local_Pending_Info" array-name="Local_Pending_Info_List">
       <tp:docstring>A structure representing a contact whose attempt to
@@ -73,50 +75,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           connection managers must silently accept this, without error.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Full"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.InviteOnly"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Banned"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetAllMembers" tp:name-for-bindings="Get_All_Members">
-      <tp:deprecated version="0.17.6">Use GetAll on the D-Bus
-        Properties D-Bus interface to get properties including Members,
-        RemotePendingMembers and LocalPendingMembers instead, falling back to
-        this method and GetLocalPendingMembersWithInfo if necessary.
-      </tp:deprecated>
-
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Members">
-        <tp:docstring>
-          array of handles of current members
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Local_Pending">
-        <tp:docstring>
-          array of handles of local pending members
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Remote_Pending">
-        <tp:docstring>
-          array of handles of remote pending members
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns arrays of all current, local and remote pending channel
-        members.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.NotCapable"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Channel.Full"/>
+        <tp:error name="im.telepathy1.Error.Channel.InviteOnly"/>
+        <tp:error name="im.telepathy1.Error.Channel.Banned"/>
       </tp:possible-errors>
     </method>
 
@@ -180,13 +147,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:flag suffix="Channel_Specific_Handles" value="256">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>
-            The members of this group have handles which are specific to
-            this channel, and are not valid as general-purpose handles on
-            the connection. Depending on the channel, it may be possible to
-            check the <tp:member-ref>HandleOwners</tp:member-ref> property or
-            call <tp:member-ref>GetHandleOwners</tp:member-ref> to find the
-            owners of these handles, which should be done if you wish to (e.g.)
-            subscribe to the contact's presence.
+            The members of this group have handles which are specific
+            to this channel, and are not valid as general-purpose
+            handles on the connection. Depending on the channel, it
+            may be possible to check the
+            <tp:member-ref>HandleOwners</tp:member-ref> property to
+            find the owners of these handles, which should be done if
+            you wish to (e.g.)  subscribe to the contact's presence.
           </p>
 
           <p>
@@ -206,43 +173,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:flag>
       <tp:flag suffix="Handle_Owners_Not_Available" value="1024">
         <tp:docstring>
-          In rooms with channel specific handles (ie Channel_Specific_Handles
+          In rooms with channel specific handles (i.e. Channel_Specific_Handles
           flag is set), this flag indicates that no handle owners are
           available, apart from the owner of the
           <tp:member-ref>SelfHandle</tp:member-ref>.
 
           <tp:rationale>
-            This used to be an important optimization to avoid repeated
-            GetHandleOwners calls, before we introduced the
+            This used to be an important optimization to avoid
+            repeated calls to the now-removed GetHandleOwners method,
+            before we introduced the
             <tp:member-ref>HandleOwners</tp:member-ref> property and
-            <tp:member-ref>HandleOwnersChanged</tp:member-ref> signal.
-          </tp:rationale>
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Properties" value="2048">
-        <tp:docstring>
-          This flag indicates that all the properties introduced in
-          specification 0.17.6 are fully supported.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Members_Changed_Detailed" value="4096">
-        <tp:docstring>
-          Indicates that <tp:member-ref>MembersChangedDetailed</tp:member-ref>
-          will be emitted for changes to this group's members in addition to
-          <tp:member-ref>MembersChanged</tp:member-ref>.
-          Clients can then connect to the former and ignore emission of the
-          latter. This flag's state MUST NOT change over the lifetime of a
-          channel.
-
-          <tp:rationale>
-            If it were allowed to change, client bindings would have to always
-            connect to MembersChanged just in case the flag ever went away (and
-            generally be unnecessarily complicated), which would mostly negate
-            the point of having this flag in the first place.
+            <tp:member-ref>HandleOwnersChanged</tp:member-ref>
+            signal.
           </tp:rationale>
         </tp:docstring>
       </tp:flag>
-      <tp:flag suffix="Message_Depart" value="8192">
+      <tp:flag suffix="Message_Depart" value="2048">
         <tp:added version="0.17.21"/>
         <tp:docstring>
           A message may be sent to the server when calling
@@ -265,37 +211,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         which operations are currently valid. Change notification is via
         the <tp:member-ref>GroupFlagsChanged</tp:member-ref> signal.
       </tp:docstring>
-      <tp:added version="0.17.6">For backwards compatibility,
-        clients should fall back to calling GetGroupFlags if
-        Channel_Group_Flag_Properties is not present.</tp:added>
+      <tp:added version="0.17.6"/>
     </property>
 
-    <method name="GetGroupFlags" tp:name-for-bindings="Get_Group_Flags">
-      <arg direction="out" type="u" tp:type="Channel_Group_Flags"
-        name="Group_Flags">
-        <tp:docstring>
-          The value of the GroupFlags property
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns the value of the <tp:member-ref>GroupFlags</tp:member-ref> property.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Use GetAll on the D-Bus
-        Properties D-Bus interface to get properties including GroupFlags
-        instead, falling back to this method if necessary.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
     <tp:mapping name="Handle_Owner_Map">
       <tp:docstring>
         A map from channel-specific handles to their owners.
       </tp:docstring>
-      <tp:added version="0.17.6">For backwards compatibility,
-        clients should fall back to calling GetHandleOwners if
-        Channel_Group_Flag_Properties is not present.</tp:added>
+      <tp:added version="0.17.6"/>
 
       <tp:member type="u" name="Channel_Specific_Handle"
         tp:type="Contact_Handle">
@@ -321,7 +244,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Handles which are channel-specific, but for which the owner is
         unknown, MUST appear in this mapping with 0 as owner. Change
         notification is via the
-        <tp:member-ref>HandleOwnersChanged</tp:member-ref> signal.
+        <tp:member-ref>HandleOwnersChanged</tp:member-ref>
+        signal.
       </tp:docstring>
       <tp:added version="0.17.6"/>
     </property>
@@ -329,42 +253,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <signal name="HandleOwnersChanged"
       tp:name-for-bindings="Handle_Owners_Changed">
       <tp:docstring>
-        Emitted whenever the <tp:member-ref>HandleOwners</tp:member-ref>
-        property changes.
-      </tp:docstring>
-      <tp:added version="0.17.6">This signal should not be relied on
-        unless Channel_Group_Flag_Properties is present.</tp:added>
-      <tp:deprecated version="0.23.4">Clients should listen to
-        <tp:member-ref>HandleOwnersChangedDetailed</tp:member-ref> instead to
-        get the new identifiers as well.
-        </tp:deprecated>
-
-      <arg name="Added" type="a{uu}" tp:type="Handle_Owner_Map">
-        <tp:docstring>
-          A map from channel-specific handles to their owners, in which the
-          keys include all the handles that were added to the keys of the
-          HandleOwners property, and all the handles in that property whose
-          owner has 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
-          HandleOwners property, as a result of the contact leaving this group
-          in a previous <tp:member-ref>MembersChanged</tp:member-ref> signal
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <signal name="HandleOwnersChangedDetailed"
-      tp:name-for-bindings="Handle_Owners_Changed_Detailed">
-      <tp:docstring>
         <p>Emitted whenever the <tp:member-ref>HandleOwners</tp:member-ref>
         property changes.</p>
-
-        <p>Clients can assume this signal is emitted by the Connection Manager
-        if the <tp:member-ref>MemberIdentifiers</tp:member-ref> property exists
-        </p>
       </tp:docstring>
       <tp:added version="0.23.4"/>
 
@@ -394,102 +284,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
     </signal>
 
-    <method name="GetHandleOwners" tp:name-for-bindings="Get_Handle_Owners">
-      <arg direction="in" name="Handles" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          A list of integer handles representing members of the channel
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="au" tp:type="Contact_Handle[]" name="Owners">
-        <tp:docstring>
-          An array of integer handles representing the owner handles of
-          the given room members, in the same order, or 0 if the
-          owner is not available
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        If the CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES flag is set on
-        the channel, then the handles of the group members are specific
-        to this channel, and are not meaningful in a connection-wide
-        context such as contact lists. This method allows you to find
-        the owner of the handle if it can be discovered in this channel,
-        or 0 if the owner is not available.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Clients should use the
-        HandleOwners property and HandleOwnersChanged signal if
-        Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            This channel doesn't have the CHANNEL_SPECIFIC_HANDLES flag,
-            so handles in this channel are globally meaningful and calling
-            this method is not necessary
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            One of the given handles is not a member
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetLocalPendingMembers"
-      tp:name-for-bindings="Get_Local_Pending_Members">
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Handles"/>
-      <tp:docstring>
-        Returns the To_Be_Added handle (only) for each structure in the
-        <tp:member-ref>LocalPendingMembers</tp:member-ref> property.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Use the LocalPendingMembers
-        property, if Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetLocalPendingMembersWithInfo"
-      tp:name-for-bindings="Get_Local_Pending_Members_With_Info">
-      <tp:added version="0.15.0" />
-      <tp:docstring>
-        Returns the <tp:member-ref>LocalPendingMembers</tp:member-ref> property.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Use the LocalPendingMembers
-        property, if Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <arg direction="out" type="a(uuus)" tp:type="Local_Pending_Info[]"
-        name="Info">
-        <tp:docstring>
-          An array of structs containing:
-          <ul>
-            <li>
-              A handle representing the contact requesting channel membership
-            </li>
-            <li>
-              A handle representing the contact making the request, or 0 if
-              unknown
-            </li>
-            <li>
-              The reason for the request: one of the values of
-              <tp:type>Channel_Group_Change_Reason</tp:type>
-            </li>
-            <li>
-              A string message containing the reason for the request if any (or
-              blank if none)
-            </li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
     <property name="LocalPendingMembers" access="read"
       type="a(uuus)" tp:type="Local_Pending_Info[]"
       tp:name-for-bindings="Local_Pending_Members">
@@ -498,10 +292,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         requesting channel membership and awaiting local approval with
         <tp:member-ref>AddMembers</tp:member-ref>.
       </tp:docstring>
-      <tp:added version="0.17.6">If Channel_Group_Flag_Properties is
-        not present, clients should fall back to using the
-        deprecated GetLocalPendingMembersWithInfo method, or fall back
-        from that to the deprecated GetAllMembers method.</tp:added>
+      <tp:added version="0.17.6"/>
     </property>
 
     <property name="Members" tp:name-for-bindings="Members"
@@ -509,70 +300,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring>
         The members of this channel.
       </tp:docstring>
-      <tp:added version="0.17.6">If Channel_Group_Flag_Properties
-        is not set, fall back to calling GetAllMembers.</tp:added>
+      <tp:added version="0.17.6"/>
     </property>
 
-    <method name="GetMembers" tp:name-for-bindings="Get_Members">
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Handles"/>
-      <tp:docstring>
-        Returns the <tp:member-ref>Members</tp:member-ref> property.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Use the Members
-        property, if Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
     <property name="RemotePendingMembers" access="read" type="au"
       tp:type="Contact_Handle[]" tp:name-for-bindings="Remote_Pending_Members">
       <tp:docstring>
         An array of handles representing contacts who have been
         invited to the channel and are awaiting remote approval.
       </tp:docstring>
-      <tp:added version="0.17.6">If Channel_Group_Flag_Properties
-        is not set, fall back to calling GetAllMembers.</tp:added>
+      <tp:added version="0.17.6"/>
     </property>
 
-    <method name="GetRemotePendingMembers"
-      tp:name-for-bindings="Get_Remote_Pending_Members">
-      <arg direction="out" type="au" tp:type="Contact_Handle[]"
-        name="Handles"/>
-      <tp:docstring>
-        Returns an array of handles representing contacts who have been
-        invited to the channel and are awaiting remote approval.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Use the
-        <tp:member-ref>RemotePendingMembers</tp:member-ref>
-        property, if Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="SelfHandleChanged" tp:name-for-bindings="Self_Handle_Changed">
-      <tp:docstring>
-        Emitted whenever the <tp:member-ref>SelfHandle</tp:member-ref> property
-        changes.
-      </tp:docstring>
-      <tp:added version="0.17.6">This signal should not be relied on
-        unless Channel_Group_Flag_Properties is present.</tp:added>
-      <tp:deprecated version="0.23.4">Clients should listen to
-        <tp:member-ref>SelfContactChanged</tp:member-ref> instead to get the new
-        identifier as well.
-        </tp:deprecated>
-
-      <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
-        <tp:docstring>
-          The new value of the SelfHandle property.
-        </tp:docstring>
-      </arg>
-    </signal>
-
     <signal name="SelfContactChanged" tp:name-for-bindings="Self_Contact_Changed">
       <tp:docstring>
         <p>Emitted whenever the <tp:member-ref>SelfHandle</tp:member-ref> property
@@ -600,18 +339,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       access="read" tp:name-for-bindings="Self_Handle">
       <tp:docstring>
         The handle for the user on this channel (which can also be a
-        local or remote pending member), or 0 if the user is not a member at
-        all (which is likely to be the case, for instance, on <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Type">ContactList</tp:dbus-ref>
-        channels). Note that this is different from the result of
-        <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Connection.GetSelfHandle</tp:dbus-ref>
-        on some protocols, so the value of this handle should
+        local or remote pending member), or 0 if the user is not a
+        member at all (which is likely to be the case, for instance,
+        on the old ContactList channels). Note that this is different
+        from the value of the <tp:dbus-ref
+        namespace="im.telepathy1">Connection.SelfHandle</tp:dbus-ref>
+        property on some protocols, so the value of this handle should
         always be used with the methods of this interface.
       </tp:docstring>
-      <tp:added version="0.17.6">For backwards compatibility,
-        clients should fall back to calling GetSelfHandle if
-        Channel_Group_Flag_Properties is not present.</tp:added>
+      <tp:added version="0.17.6"/>
     </property>
 
     <property name="MemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
@@ -623,30 +359,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         least the identifiers for
         <tp:member-ref>SelfHandle</tp:member-ref>,
         <tp:member-ref>Members</tp:member-ref>,
-        <tp:member-ref>LocalPendingMembers</tp:member-ref> (and their actors if
-        any),
         <tp:member-ref>RemotePendingMembers</tp:member-ref> and
         <tp:member-ref>HandleOwners</tp:member-ref>.
       </tp:docstring>
       <tp:added version="0.23.4"/>
     </property>
 
-    <method name="GetSelfHandle" tp:name-for-bindings="Get_Self_Handle">
-      <arg direction="out" type="u" tp:type="Contact_Handle"
-        name="Self_Handle"/>
-      <tp:docstring>
-        Returns the value of the <tp:member-ref>SelfHandle</tp:member-ref>
-        property.
-      </tp:docstring>
-      <tp:deprecated version="0.17.6">Clients should retrieve the
-        SelfHandle property using GetAll instead,
-        if Channel_Group_Flag_Properties is present.</tp:deprecated>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
     <signal name="GroupFlagsChanged" tp:name-for-bindings="Group_Flags_Changed">
       <arg name="Added" type="u" tp:type="Channel_Group_Flags">
         <tp:docstring>
@@ -659,9 +377,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </arg>
       <tp:docstring>
-        Emitted when the flags as returned by
-        <tp:member-ref>GetGroupFlags</tp:member-ref> are changed.
-        The user interface should be updated as appropriate.
+        Emitted when the flags as retrieved by the
+        <tp:member-ref>GroupFlags</tp:member-ref> property are
+        changed. The user interface should be updated as appropriate.
       </tp:docstring>
     </signal>
 
@@ -673,10 +391,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:member-ref>RemotePendingMembers</tp:member-ref>, or to be removed
           from the group. A client may supply a reason when attempting to
           remove members from a group with
-          <tp:member-ref>RemoveMembersWithReason</tp:member-ref>, and reasons
+          <tp:member-ref>RemoveMembers</tp:member-ref>, and reasons
           are supplied by the CM when emitting
-          <tp:member-ref>MembersChanged</tp:member-ref> and
-          <tp:member-ref>MembersChangedDetailed</tp:member-ref>. Some reason
+          <tp:member-ref>MembersChanged</tp:member-ref>. Some reason
           codes have different meanings depending on the <var>Actor</var> in a
           MembersChanged signal.</p>
       </tp:docstring>
@@ -693,11 +410,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <p>If the <tp:member-ref>SelfHandle</tp:member-ref> is removed from
             a group for this reason and the actor is not the SelfHandle, the
             equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Terminated</code>.</p>
+            <code>im.telepathy1.Error.Terminated</code>.</p>
 
           <p>If the SelfHandle is removed from a group for this reason and
             the actor is also the SelfHandle, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cancelled</code>.</p>
+            <code>im.telepathy1.Error.Cancelled</code>.</p>
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Offline" value="1">
@@ -705,12 +422,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <p>The change is due to a user going offline. Also used when
             user is already offline, but this wasn't known previously.</p>
 
-          <p>If a one-to-one <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-            call fails because the contact being called is offline, the
-            connection manager SHOULD indicate this by removing both the
-            <tp:member-ref>SelfHandle</tp:member-ref> and the other contact's
-            handle from the Group interface with reason Offline.</p>
+          <p>If a one-to-one StreamedMedia call fails because the
+            contact being called is offline, the connection manager
+            SHOULD indicate this by removing both the
+            <tp:member-ref>SelfHandle</tp:member-ref> and the other
+            contact's handle from the Group interface with reason
+            Offline.</p>
 
           <tp:rationale>
             For 1-1 calls, the call terminates as a result of removing the
@@ -720,7 +437,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If a handle is removed from a group for this reason, the
             equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Offline</code>.</p>
+            <code>im.telepathy1.Error.Offline</code>.</p>
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Kicked" value="2">
@@ -729,7 +446,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If the <tp:member-ref>SelfHandle</tp:member-ref> is removed
             from a group for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Channel.Kicked</code>.
+            <code>im.telepathy1.Error.Channel.Kicked</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -737,12 +454,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The change is due to a busy indication.</p>
 
-          <p>If a one-to-one <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-            call fails because the contact being called is busy, the
-            connection manager SHOULD indicate this by removing both the
-            <tp:member-ref>SelfHandle</tp:member-ref> and the other contact's
-            handle from the Group interface with reason Busy.</p>
+          <p>If a one-to-one StreamedMedia call fails because the
+            contact being called is busy, the connection manager
+            SHOULD indicate this by removing both the
+            <tp:member-ref>SelfHandle</tp:member-ref> and the other
+            contact's handle from the Group interface with reason
+            Busy.</p>
 
           <tp:rationale>
             For 1-1 calls, the call terminates as a result of removing the
@@ -752,7 +469,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If the <tp:member-ref>SelfHandle</tp:member-ref> is removed
             from a group for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Busy</code>.
+            <code>im.telepathy1.Error.Busy</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -774,7 +491,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If the <tp:member-ref>SelfHandle</tp:member-ref> is removed
             from a group for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Channel.Banned</code>.
+            <code>im.telepathy1.Error.Channel.Banned</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -803,7 +520,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If a contact is removed from a group for this reason, the
             equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.DoesNotExist</code>.
+            <code>im.telepathy1.Error.DoesNotExist</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -811,13 +528,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The change is because the requested contact did not respond.</p>
 
-          <p>If a one-to-one <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-            call fails because the contact being called did not respond, or the
-            local user did not respond to an incoming call, the
-            connection manager SHOULD indicate this by removing both the
-            <tp:member-ref>SelfHandle</tp:member-ref> and the other contact's
-            handle from the Group interface with reason No_Answer.</p>
+          <p>If a one-to-one StreamedMedia call fails because the
+            contact being called did not respond, or the local user
+            did not respond to an incoming call, the connection
+            manager SHOULD indicate this by removing both the
+            <tp:member-ref>SelfHandle</tp:member-ref> and the other
+            contact's handle from the Group interface with reason
+            No_Answer.</p>
 
           <tp:rationale>
             Documenting existing practice.
@@ -825,7 +542,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If a contact is removed from a group for this reason, the
             equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.NoAnswer</code>.
+            <code>im.telepathy1.Error.NoAnswer</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -834,10 +551,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <p>The change is because a contact's unique identifier changed.
           There must be exactly one handle in the removed set and exactly
           one handle in one of the added sets. The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Renaming">Renamed</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Renaming1">Renamed</tp:dbus-ref>
           signal on the
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface">Renaming</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface">Renaming1</tp:dbus-ref>
           interface will have been emitted for the same handles,
           shortly before this <tp:member-ref>MembersChanged</tp:member-ref> signal is emitted.</p>
         </tp:docstring>
@@ -849,7 +566,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
           <p>If a contact is removed from a group for this reason, the
             equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.PermissionDenied</code>.
+            <code>im.telepathy1.Error.PermissionDenied</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -864,9 +581,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             If members are added with this reason code, the change is because
             unconnected parts of the group have rejoined. If this channel
             carries messages (e.g. <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
-            or <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">Tubes</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>
             channels) applications must
             assume that the contacts being added are likely to have missed some
             messages as a result of the separation, and that the contacts
@@ -886,66 +601,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:enumvalue>
     </tp:enum>
 
-    <signal name="MembersChanged" tp:name-for-bindings="Members_Changed">
-      <arg name="Message" type="s">
-        <tp:docstring>
-          A string message from the server, or blank if not
-        </tp:docstring>
-      </arg>
-      <arg name="Added" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          A list of members added to the channel
-        </tp:docstring>
-      </arg>
-      <arg name="Removed" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          A list of members removed from the channel
-        </tp:docstring>
-      </arg>
-      <arg name="Local_Pending" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          A list of members who are pending local approval
-        </tp:docstring>
-      </arg>
-      <arg name="Remote_Pending" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          A list of members who are pending remote approval
-        </tp:docstring>
-      </arg>
-      <arg name="Actor" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The contact handle of the person who made the change, or 0
-          if not known
-        </tp:docstring>
-      </arg>
-      <arg name="Reason" type="u" tp:type="Channel_Group_Change_Reason">
-        <tp:docstring>
-          A reason for the change
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when contacts join any of the three lists (members, local
-          pending or remote pending) or when they leave any of the three lists.
-          There may also be a message from the server regarding this change,
-          which may be displayed to the user if desired.</p>
-
-        <p>All channel-specific handles that are mentioned in this signal
-          MUST be represented in the value of the
-          <tp:member-ref>HandleOwners</tp:member-ref> property.
-          In practice, this will mean that
-          <tp:member-ref>HandleOwnersChanged</tp:member-ref> is
-          emitted <em>before</em> emitting a MembersChanged signal in which
-          channel-specific handles are added, but that it is emitted
-          <em>after</em> emitting a MembersChanged signal in which
-          channel-specific handles are removed.</p>
-
-        <p>See <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-          for an overview of how group state changes are used to indicate the
-          progress of a call.</p>
-      </tp:docstring>
-    </signal>
-
     <tp:mapping name="Handle_Identifier_Map">
       <tp:docstring>
         A map from handles to the corresponding normalized string identifier.
@@ -959,15 +614,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:member>
       <tp:member type="s" name="Identifier">
         <tp:docstring>
-          The same string that would be returned by <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>
-          for this handle.
+          The normalized contact identifier.
         </tp:docstring>
       </tp:member>
     </tp:mapping>
 
-    <signal name="MembersChangedDetailed"
-      tp:name-for-bindings="Members_Changed_Detailed">
+    <signal name="MembersChanged"
+      tp:name-for-bindings="Members_Changed">
       <arg name="Added" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
           A list of members added to the channel
@@ -1055,26 +708,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Emitted when contacts join any of the three lists (members, local
           pending or remote pending) or when they leave any of the three
-          lists. This signal provides a superset of the information provided by
-          <tp:member-ref>MembersChanged</tp:member-ref>;
-          if the channel's <tp:member-ref>GroupFlags</tp:member-ref>
-          contains Members_Changed_Detailed, then clients may listen exclusively
-          to this signal in preference to that signal.</p>
+          lists.</p>
 
         <p>All channel-specific handles that are mentioned in this signal
           MUST be represented in the value of the
-          <tp:member-ref>HandleOwners</tp:member-ref> property.  In practice,
-          this will mean that
-          <tp:member-ref>HandleOwnersChanged</tp:member-ref> is emitted
-          <em>before</em> emitting a MembersChangedDetailed signal in which
-          channel-specific handles are added, but that it is emitted
-          <em>after</em> emitting a MembersChangedDetailed signal in which
-          channel-specific handles are removed.</p>
-
-        <p>See <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-          for an overview of how group state changes are used to indicate the
-          progress of a call.</p>
+          <tp:member-ref>HandleOwners</tp:member-ref> property.</p>
       </tp:docstring>
       <tp:added version="0.17.16"/>
     </signal>
@@ -1090,6 +728,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           A string message, which can be blank if desired
         </tp:docstring>
       </arg>
+      <arg direction="in" name="Reason" type="u"
+           tp:type="Channel_Group_Change_Reason">
+        <tp:docstring>
+          A reason for the change
+        </tp:docstring>
+      </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Requests the removal of contacts from a channel, reject their
           request for channel membership on the pending local list, or
@@ -1097,10 +741,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>If the <tp:member-ref>SelfHandle</tp:member-ref> is in a Group,
           it can be removed via this method, in order to leave the group
-          gracefully. This is the recommended way to leave a chatroom, close
-          or reject a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-          call, and so on.</p>
+          gracefully. This is the recommended way to leave a chatroom.</p>
 
         <p>Accordingly, connection managers SHOULD support
           doing this, regardless of the value of
@@ -1108,7 +749,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           If doing so fails with PermissionDenied, this is considered to a bug
           in the connection manager, but clients MUST recover by falling back
           to closing the channel with the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+            namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
           method.</p>
 
         <p>Removing any contact from the local pending list is always
@@ -1129,47 +770,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           Channel_Group_Flag_Message_Rescind
           <tp:member-ref>GroupFlags</tp:member-ref> to see in which cases this
           message should be provided.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-      </tp:possible-errors>
-    </method>
 
-    <method name="RemoveMembersWithReason"
-      tp:name-for-bindings="Remove_Members_With_Reason">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of contact handles to remove from the channel
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Message" type="s">
-        <tp:docstring>
-          A string message, which can be blank if desired
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Reason" type="u"
-           tp:type="Channel_Group_Change_Reason">
-        <tp:docstring>
-          A reason for the change
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        As <tp:member-ref>RemoveMembers</tp:member-ref>, but a reason code may
-        be provided where
-        appropriate. The reason code may be ignored if the underlying
-        protocol is unable to represent the given reason.
+          <p>The reason code may be ignored if the underlying
+            protocol is unable to represent the given reason.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The provided reason code was invalid.
           </tp:docstring>
@@ -1195,19 +806,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     their request before they may join. A single contact should never appear on
     more than one of the three lists. The lists are empty when the channel is
     created, and the <tp:member-ref>MembersChanged</tp:member-ref> signal
-    (and, if the channel's <tp:member-ref>GroupFlags</tp:member-ref> contains
-    Members_Changed_Detailed, the
-    <tp:member-ref>MembersChangedDetailed</tp:member-ref> signal)
-    should be emitted when information
-    is retrieved from the server, or changes occur.</p>
-
-  <p>If the <tp:member-ref>MembersChanged</tp:member-ref> or
-    <tp:member-ref>MembersChangedDetailed</tp:member-ref> signal indicates
+    should be emitted when information is retrieved from the server,
+    or changes occur.</p>
+
+  <p>If the <tp:member-ref>MembersChanged</tp:member-ref> signal indicates
     that the <tp:member-ref>SelfHandle</tp:member-ref> has been removed from
     the channel, and the channel subsequently emits <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Channel">Closed</tp:dbus-ref>,
-    clients SHOULD consider the details given in the MembersChanged or
-    MembersChangedDetailed signal to be the reason why the channel closed.</p>
+      namespace="im.telepathy1.Channel">Closed</tp:dbus-ref>,
+    clients SHOULD consider the details given in the MembersChanged
+    signal to be the reason why the channel closed.</p>
 
   <p>Addition of members to the channel may be requested by using
     <tp:member-ref>AddMembers</tp:member-ref>. If
diff --git a/spec/Channel_Interface_HTML.xml b/spec/Channel_Interface_HTML1.xml
index ad86867c..245ad1b1 100644
--- a/spec/Channel_Interface_HTML.xml
+++ b/spec/Channel_Interface_HTML1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_HTML"
+<node name="/Channel_Interface_HTML1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
@@ -19,17 +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.Channel.Interface.HTML.DRAFT"
+    name="im.telepathy1.Channel.Interface.HTML1"
     tp:causes-havoc="unfinished">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
-    <tp:requires
-      interface="org.freedesktop.Telepathy.Channel.Interface.Messages"/>
+    <tp:requires interface="im.telepathy1.Channel.Type.Text"/>
     <tp:added version="0.17.5">(draft version, not API-stable)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>This interface extends the Messages interface to support
-        capability discovery, so clients can decide what subset of HTML
-        is supported.</p>
+      <p>This interface extends the <tp:dbus-ref
+        namespace="imt1.Channel.Type">Text</tp:dbus-ref> interface to
+        support capability discovery, so clients can decide what
+        subset of HTML is supported.</p>
 
       <p>(However, the capability discovery mechanism has not been written
         yet, so this interface MUST NOT be used. It exists only to
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold1.xml
index 69d295d9..9801827e 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Hold" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Hold1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2005-2008 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2005-2008 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
@@ -19,12 +19,9 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Hold">
-    <tp:xor-requires>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
-    </tp:xor-requires>
+  <interface name="im.telepathy1.Channel.Interface.Hold1">
+    <tp:requires interface="im.telepathy1.Channel.Type.Call1"/>
+    <tp:requires interface="im.telepathy1.Call1.Content"/>
     <tp:changed version="0.17.4">first API-stable version</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -32,7 +29,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         This only makes sense for channels where
         you are streaming media to or from the members. (To see whether the
         other participant has put you on hold, see <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface"
+          namespace="im.telepathy1.Channel.Type.Call1"
         >CallState</tp:dbus-ref>.)</p>
 
       <p>If you place a channel on hold, this indicates that you do not wish
@@ -215,9 +212,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The requested hold state cannot be achieved; for example,
             if only a limited number of channels can be in the "not on hold"
diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml
deleted file mode 100644
index 58a222c1..00000000
--- a/spec/Channel_Interface_Media_Signalling.xml
+++ /dev/null
@@ -1,189 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Media_Signalling" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright © 2006 INdT </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.MediaSignalling">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-    <tp:changed version="0.24.0">The old-style Telepathy properties,
-      deprecated since March 2009, have been removed.</tp:changed>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>An interface for signalling a channel containing synchronised media
-        sessions which can contain an arbitrary number of streams. The
-        presence of this interface on a Channel indicates that the connection
-        manager will not carry out the actual streaming for this channel,
-        and that the client handling the channel is responsible for doing
-        so; in most cases we recommend doing this by using the
-        telepathy-farsight library.</p>
-
-      <tp:rationale>
-        <p>Streaming audio and (particularly) video requires a high level of
-          integration with the UI, and having the connection manager act as
-          a proxy would be likely to introduce unacceptable latency. As a
-          result, audio/video streaming is offloaded into the client
-          where possible, as an exception to the general design of
-          Telepathy.</p>
-      </tp:rationale>
-
-      <p>The negotiation interface is based on the API of the
-        <a href="http://farsight.freedesktop.org/">Farsight</a> library.
-        This, in turn, is based upon the IETF MMusic ICE drafts, where
-        connections are established by signalling potential connection
-        candidates to the peer until a usable connection is found, and
-        codecs are negotiated with an SDP-style offer and answer. However,
-        the principles should be applicable to other media streaming methods
-        and the API re-used without difficulty.</p>
-
-      <p>Note that the naming conventions used in the MediaStreamHandler
-        and MediaSessionHandler interfaces are rather confusing; methods
-        have signal-like names and signals have method-like names, due to
-        the API being based rather too closely on that of Farsight. This
-        is for historical reasons and will be fixed in a future release
-        of the Telepathy specification.</p>
-    </tp:docstring>
-
-    <tp:simple-type name="Media_Session_Type" type="s">
-      <tp:docstring>The type of a media session. Currently, the only supported
-        value is "rtp".</tp:docstring>
-    </tp:simple-type>
-
-    <tp:struct name="Media_Session_Handler_Info"
-        array-name="Media_Session_Handler_Info_List">
-      <tp:docstring>A struct representing a active session handler.</tp:docstring>
-      <tp:member type="o" name="Session_Handler">
-        <tp:docstring>The object path of the session handler, which is on the
-          same bus name as the channel.</tp:docstring>
-      </tp:member>
-      <tp:member type="s" tp:type="Media_Session_Type" name="Media_Session_Type">
-        <tp:docstring>The media session's type</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <method name="GetSessionHandlers"
-      tp:name-for-bindings="Get_Session_Handlers">
-      <arg direction="out" type="a(os)" tp:type="Media_Session_Handler_Info[]"
-        name="Session_Handlers"/>
-      <tp:docstring>
-        Returns all currently active session handlers on this channel
-        as a list of (session_handler_path, type).
-      </tp:docstring>
-    </method>
-
-    <signal name="NewSessionHandler" tp:name-for-bindings="New_Session_Handler">
-      <arg name="Session_Handler" type="o">
-        <tp:docstring>
-          Object path of the new <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Media.SessionHandler</tp:dbus-ref>
-          object
-        </tp:docstring>
-      </arg>
-      <arg name="Session_Type" tp:type="Media_Session_Type" type="s">
-        <tp:docstring>
-          String indicating type of session, eg &quot;rtp&quot;
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal that a session handler object has been created. The client
-        should create a session object and create streams for the streams
-        within.
-      </tp:docstring>
-    </signal>
-
-    <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.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-          property is <code>gtalk-p2p</code>.</p>
-      </tp:docstring>
-    </tp:hct>
-
-    <tp:hct name="ice-udp">
-      <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.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-          property is <code>ice-udp</code>.</p>
-      </tp:docstring>
-    </tp:hct>
-
-    <tp:hct name="wlm-8.5">
-      <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.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-          property is <code>wlm-8.5</code>.</p>
-      </tp:docstring>
-    </tp:hct>
-
-    <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.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-          property is <code>wlm-2009</code>.</p>
-      </tp:docstring>
-    </tp:hct>
-
-    <tp:hct name="video/h264" is-family="yes">
-      <tp:docstring>
-        <p>The client supports media streaming with H264 (etc.).</p>
-
-        <p>This handler capability token is a one of a family
-          of similar tokens: for any other audio or video codec whose MIME
-          type is audio/<em>subtype</em> or video/<em>subtype</em>, a handler
-          capability token of this form may exist (the subtype MUST appear
-          in lower case in this context). Clients MAY support more
-          codecs than they explicitly advertise support for; clients SHOULD
-          explicitly advertise support for their preferred codec(s), and
-          for codecs like H264 that are, in practice, significant in codec
-          negotiation.</p>
-
-        <tp:rationale>
-          <p>For instance, the XMPP capability used by the Google Video
-            Chat web client to determine whether a client is compatible
-            with it requires support for H264 video, so an XMPP
-            connection manager that supports this version of Jingle should
-            not advertise the Google Video Chat capability unless there
-            is at least one installed client that declares that it supports
-            <code>video/h264</code> on StreamedMedia channels.</p>
-        </tp:rationale>
-
-        <p>For example, a client could advertise support for
-          Speex, Theora and H264 by having three
-          handler capability tokens,
-          <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex</code>,
-          <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora</code> and
-          <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264</code>,
-          in its <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref>
-          property.</p>
-
-        <p>Clients MAY have media signalling abilities without explicitly
-          supporting any particular codec, and connection managers SHOULD
-          support this usage.</p>
-
-        <tp:rationale>
-          <p>This is necessary to support gatewaying between two Telepathy
-            connections, in which case the available codecs might not be
-            known to the gatewaying process.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </tp:hct>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Mergeable_Conference.xml b/spec/Channel_Interface_Mergeable_Conference1.xml
index cd606c1b..91ed1051 100644
--- a/spec/Channel_Interface_Mergeable_Conference.xml
+++ b/spec/Channel_Interface_Mergeable_Conference1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Mergeable_Conference"
+<node name="/Channel_Interface_Mergeable_Conference1"
   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>
@@ -20,10 +20,10 @@
       02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.MergeableConference.DRAFT"
+    name="im.telepathy1.Channel.Interface.MergeableConference1"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Conference"/>
+    <tp:requires interface="im.telepathy1.Channel.Interface.Conference1"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for multi-user conference channels that can have
@@ -49,12 +49,12 @@
           channel.</p>
 
         <p>The given channel SHOULD be added to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.Channels</tp:dbus-ref> if and only if the
+            namespace="im.telepathy1.Channel.Interface"
+            >Conference1.Channels</tp:dbus-ref> if and only if the
           underlying protocol signals the merge in some way. It MUST NOT be
           added to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference.InitialChannels</tp:dbus-ref> (to preserve
+            namespace="im.telepathy1.Channel.Interface"
+            >Conference1.InitialChannels</tp:dbus-ref> (to preserve
           immutability).</p>
 
         <tp:rationale>
@@ -73,28 +73,28 @@
       <arg direction="in" name="Channel" type="o">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A channel with the same <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
+              namespace="im.telepathy1.Channel"
               >ChannelType</tp:dbus-ref>
             as this one, but with <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel"
+              namespace="im.telepathy1.Channel"
               >TargetHandleType</tp:dbus-ref> = CONTACT.</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.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.Error.NotImplemented">
+        <tp:error name="im.telepathy1.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.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             The given channel is theoretically suitable for merging into this
             one, but that's not currently possible for some reason (for
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
deleted file mode 100644
index a88576dc..00000000
--- a/spec/Channel_Interface_Messages.xml
+++ /dev/null
@@ -1,1484 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Messages"
-  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>Copyright © 2008–2010 Collabora Ltd.</tp:copyright>
-  <tp:copyright>Copyright © 2008–2010 Nokia Corporation</tp:copyright>
-  <tp:license xmlns="http://www.w3.org/1999/xhtml">
-    <p>This library is free software; you can redistribute it and/or
-modify it under the terms of the GNU Lesser General Public
-License as published by the Free Software Foundation; either
-version 2.1 of the License, or (at your option) any later version.</p>
-
-<p>This library is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-Lesser General Public License for more details.</p>
-
-<p>You should have received a copy of the GNU Lesser General Public
-License along with this library; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-USA.</p>
-  </tp:license>
-  <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Messages">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
-    <tp:added version="0.17.16">(as stable API)</tp:added>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>This interface extends the <tp:dbus-ref
-          namespace='org.freedesktop.Telepathy.Channel.Type'>Text</tp:dbus-ref>
-        interface to support more general messages, including:</p>
-
-      <ul>
-        <li>messages with attachments (like MIME multipart/mixed)</li>
-        <li>groups of alternatives (like MIME multipart/alternative)</li>
-        <li>delivery reports (which replace <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">Text.SendError</tp:dbus-ref>),
-          addding support for protocols where the message content is not echoed
-          back to the sender on failure and for receiving positive
-          acknowledgements, as well as ensuring that incoming delivery reports
-          are not lost if no client is handling the channel yet;</li>
-        <li>any extra types of message we need in future</li>
-      </ul>
-
-      <p>Incoming messages, outgoing messages, and delivery reports are all
-        represented as lists of <tp:type>Message_Part</tp:type> structures,
-        with a format reminiscent of e-mail. Messages are sent by calling
-        <tp:member-ref>SendMessage</tp:member-ref>; outgoing messages are
-        announced to other clients which may be interested in the channel by
-        the <tp:member-ref>MessageSent</tp:member-ref> signal. Incoming
-        messages and delivery reports are signalled by
-        <tp:member-ref>MessageReceived</tp:member-ref>, and are stored in the
-        the <tp:member-ref>PendingMessages</tp:member-ref> property until
-        acknowledged by calling <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">Text.AcknowledgePendingMessages</tp:dbus-ref>.
-        Only the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
-        for a channel should acknowledge messages; <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Observer</tp:dbus-ref>s
-        (such as loggers) and <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
-        for the channel may listen for incoming messages, and send messages of their own, but SHOULD NOT acknowledge messages.</p>
-
-      <tp:rationale>
-        <p>If observers were allowed to acknowledge messages, then messages
-          might have been acknowledged before the handler even got to see the
-          channel, and hence could not be shown to the user.</p>
-      </tp:rationale>
-
-      <p>If this interface is present, clients that support it SHOULD
-        listen for the <tp:member-ref>MessageSent</tp:member-ref> and
-        <tp:member-ref>MessageReceived</tp:member-ref> signals, and
-        ignore the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.Text">Sent</tp:dbus-ref>,
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.Text">SendError</tp:dbus-ref>
-        and <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.Text">Received</tp:dbus-ref>
-        signals on the Text interface (which are guaranteed to duplicate
-        signals from this interface).</p>
-
-      <p>Although this specification supports formatted (rich-text)
-        messages with unformatted alternatives, implementations SHOULD NOT
-        attempt to send formatted messages until the Telepathy specification
-        has also been extended to cover capability discovery for message
-        formatting.</p>
-
-      <tp:rationale>
-        We intend to expose all rich-text messages as XHTML-IM, but on some
-        protocols, formatting is an extremely limited subset of that format
-        (e.g. there are protocols where foreground/background colours, font
-        and size can be set, but only for entire messages).
-        Until we can tell UIs what controls to offer to the user, it's
-        unfriendly to offer the user controls that may have no effect.
-      </tp:rationale>
-    </tp:docstring>
-
-    <property name="SupportedContentTypes" type="as" access="read"
-      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 "*/*"
-          to indicate that attachments with arbitrary MIME types can be sent.
-          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>
-
-        <dl>
-          <dt>A simple IM implementation: only plain text messages are
-            allowed</dt>
-          <dd>SupportedContentTypes = ['text/plain'],
-            MessagePartSupportFlags = 0</dd>
-
-          <dt>Formatted text with a plain text alternative is allowed (see the
-            HTML interface draft)</dt>
-          <dd>SupportedContentTypes = ['text/html', 'text/plain'],
-            MessagePartSupportFlags = 0</dd>
-
-          <dt>JPEG or PNG images may be sent, but without any attached
-            text</dt>
-          <dd>SupportedContentTypes = ['text/plain', 'image/jpeg',
-            'image/png'], MessagePartSupportFlags = 0</dd>
-
-          <dt>Unformatted text to which an optional JPEG or PNG image may be
-            attached</dt>
-          <dd>SupportedContentTypes = ['text/plain', 'image/jpeg',
-            'image/png'], MessagePartSupportFlags = One_Attachment</dd>
-
-          <dt>Formatted text to which arbitrarily many images may be
-            attached</dt>
-          <dd>SupportedContentTypes = ['text/html', 'text/plain', 'image/jpeg',
-            'image/png', 'image/x-ms-bmp'], MessagePartSupportFlags =
-            One_Attachment | Multiple_Attachments</dd>
-
-          <dt>A full SIP implementation: arbitrary MIME messages are
-            allowed</dt>
-          <dd>SupportedContentTypes = ['*/*'], MessagePartSupportFlags =
-            One_Attachment | Multiple_Attachments</dd>
-        </dl>
-      </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:immutable="yes">
-      <tp:docstring>
-        Flags indicating the level of support for message parts on this
-        channel.
-      </tp:docstring>
-    </property>
-
-    <tp:flags name="Message_Part_Support_Flags"
-      value-prefix="Message_Part_Support_Flag" type="u">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Flags indicating the level of support for message parts on this
-          channel. They are designed such that setting more flags always
-          implies that the channel has more capabilities.</p>
-
-        <p>If no flags are set, this indicates that messages may contain
-          a single message part whose content-type is any of the types
-          from SupportedContentTypes, possibly with some alternatives.</p>
-
-        <p>There is no flag indicating support for alternatives. This is
-          because the SendMessage implementation can always accept messages
-          containing alternatives, even if the underlying protocol does not,
-          by deleting all alternatives except the first (most preferred)
-          that is supported.</p>
-
-        <tp:rationale>
-          Each of the flags so far implies the previous flag, so we could
-          have used a simple enumeration here; however, we've defined
-          the message-part support indicator as a flag set for future
-          expansion.
-        </tp:rationale>
-
-        <p>See <tp:member-ref>SupportedContentTypes</tp:member-ref> for some
-          examples.</p>
-      </tp:docstring>
-
-      <tp:flag suffix="One_Attachment" value="1">
-        <tp:docstring>
-          <tp:member-ref>SendMessage</tp:member-ref> will accept messages
-          containing a textual message body,
-          plus a single attachment of any type listed in the
-          SupportedContentTypes property. It does not make sense for this
-          flag to be set if Message_Part_Support_Flag_Data_Only is not also set
-          (because the connection manager can trivially provide an empty text
-          part if necessary).
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Multiple_Attachments" value="2">
-        <tp:docstring>
-          SendMessage will accept messages containing a textual message body,
-          plus an arbitrary number of attachments of any type listed in the
-          SupportedContentTypes property. It does not make sense for this
-          flag to be set if Message_Part_Support_Flag_One_Attachment is not
-          also set.
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-    <tp:mapping name="Message_Part" array-name="Message_Part_List"
-      array-depth="2">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Part of a message's content. In practice, this mapping never
-          appears in isolation: incoming messages are represented by a list of
-          <tp:type>Message_Part</tp:type> mappings in the
-          <tp:member-ref>MessageReceived</tp:member-ref> signal, and outgoing
-          messages are passed to <tp:member-ref>SendMessage</tp:member-ref> as
-          a list of these mappings.</p>
-
-        <p>The first part of the message contains "headers", which refer
-          to the entire message. The second and subsequent parts contain the
-          message's content, including plain text, formatted text and/or
-          attached files. Well-known keys for the header and body parts are
-          defined by the <tp:type>Message_Header_Key</tp:type> and
-          <tp:type>Message_Body_Key</tp:type> types, respectively.  It is an
-          error for a connection manager to put keys referring to the message
-          as a whole in the second or subsequent Message_Part, or keys intended
-          for body parts in the first Message_Part; clients MUST recover from
-          this error by ignoring these mis-placed keys.</p>
-
-        <tp:rationale>
-          <p>Instead of representing messages as aa{sv} where the first
-            dictionary is special (a dictionary of headers), we could have
-            used a signature like (a{sv}aa{sv}) to separate out the headers
-            and the body parts.</p>
-
-          <p>However, this would make access to the messages more awkward.
-            In Python, the syntax for access to a header field would remain
-            <code>message[0]['message-type']</code>, but access to a body
-            field in the second body part would change from
-            <code>message[2]['content'] to message[1][1]['content']</code>. In
-            GLib, the message would change from being a
-            <code>GPtrArray(GHashTable)</code> to being a
-            <code>GValueArray(GHashTable, GPtrArray(GHashTable))</code> which
-            is rather inconvenient to dereference.</p>
-        </tp:rationale>
-
-        <p>In any group of parts with the same non-empty value for the
-          <tt>alternative</tt> key (which represent alternative versions of the
-          same content), more faithful versions of the intended message MUST
-          come before less faithful versions (note that this order is the
-          opposite of MIME <tt>multipart/alternative</tt> parts). Clients
-          SHOULD display the first alternative that they understand.</p>
-
-        <tp:rationale>
-          <p>Specifying the preference order means that if the underlying
-            protocol doesn't support alternatives, the CM can safely delete
-            everything apart from the first supported alternative when
-            sending messages.</p>
-
-          <p>The order is the reverse of MIME because MIME's rationale for
-            placing the "plainest" part first (legibility in pre-MIME UAs)
-            does not apply to us, and placing the most preferred part
-            first simplifies display (a client can iterate the message
-            in order, display the first alternative that it understands,
-            and skip displaying all subsequent parts with the same
-            "alternative" key).</p>
-        </tp:rationale>
-
-        <p>Clients SHOULD present all parts that are not redundant
-          alternatives in the order they appear in this array, possibly
-          excluding parts that are referenced by another displayed part.
-          It is implementation-specific how the parts are presented to the
-          user.</p>
-
-        <tp:rationale>
-          <p>This allows CMs to assume that all parts are actually shown to
-            the user, even if they are not explicitly referenced - we do
-            not yet recommend formatted text, and there is no way for
-            plain text to reference an attachment since it has no concept of
-            markup or references. This also forces clients to do something
-            sensible with messages that consist entirely of "attachments",
-            with no "body" at all.</p>
-
-          <p>For instance, when displaying the above example, a client that
-            understands the HTML part should display the JPEG image once,
-            between the two lines "Here is a photo of my cat:" and
-            "Isn't it cute?"; it may additionally present the image in some
-            way for a second time, after "Isn't it cute?", or may choose
-            not to.</p>
-
-          <p>A client that does not understand HTML, displaying the same
-            message, should display the plain-text part, followed by the JPEG
-            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
-          as:</p>
-
-          <pre>
-[
-  {
-    'message-token': '9de9546a-3400-4419-a505-3ea270cb834c',
-    'message-sender': 42,
-    'message-sent': 1210067943,
-    'message-received': 1210067947,
-    'message-type': 0,              # = Channel_Text_Message_Type_Normal
-    'pending-message-id': 437,
-  },
-  { 'alternative': 'main',
-    'content-type': 'text/html',
-    'content': 'Here is a photo of my cat:&lt;br /&gt;' +
-               '&lt;img src="cid:catphoto" alt="lol!" /&gt;' +
-               '&lt;br /&gt;Isn't it cute?',
-  },
-  { 'alternative': 'main',
-    'content-type': 'text/plain',
-    'content': 'Here is a photo of my cat:\n[IMG: lol!]\nIsn't it cute?',
-  },
-  { 'identifier': 'catphoto',
-    'content-type': 'image/jpeg',
-    'size': 101000,
-    'needs-retrieval': True,
-  },
-]</pre>
-
-        <p>telepathy-ring, Nokia's GSM connection manager, represents vCards
-          sent via SMS as:</p>
-
-        <pre>
-[
-  {
-    'message-token': '9de9546a-3400-4419-a505-3ea270cb834c',
-    'message-sender': 42,
-    'message-sent': 1210067943,
-    'message-received': 1210067947,
-    'message-type': 0,              # = Channel_Text_Message_Type_Normal
-    'pending-message-id': 437,
-  },
-  { 'content-type': 'text/x-vcard',
-    'content': [ 0x66, 0x69, 0x71, ...], # vCard data as an array of bytes
-  },
-]</pre>
-
-        <h3>Delivery reports</h3>
-
-        <div>
-          <p>Delivery reports are also represented as messages with the
-            <tt>message-type</tt> header mapping to
-            <tp:type>Channel_Text_Message_Type</tp:type> Delivery_Report.
-            Delivery reports SHOULD contain the <tt>message-sender</tt> header,
-            mapping to the intended recipient of the original message, if
-            possible; other headers specific to delivery reports are defined by
-            the <tp:type>Delivery_Report_Header_Key</tp:type> type. The second
-            and subsequent parts, if present, are a human-readable report from
-            the IM service.</p>
-
-          <p>For backwards- and forwards-compatibility, whenever a delivery
-            error report is signalled—that is, with <tt>delivery-status</tt>
-            mapping to <tp:type>Delivery_Status</tp:type> Temporarily_Failed or
-            Permanently_Failed—<tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.Text">SendError</tp:dbus-ref>
-            SHOULD also be emitted; whenever <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.Text">SendError</tp:dbus-ref>
-            is emitted, a delivery report MUST also be signalled.
-            Delivery report messages on this interface MUST be represented in
-            emissions of <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.Text">Received</tp:dbus-ref>
-            as messages with the Non_Text_Content
-            <tp:type>Channel_Text_Message_Flags</tp:type>; clients which
-            understand this interface SHOULD ignore the SendError signal in
-            favour of listening for delivery reports, as mentioned in the
-            introduction.</p>
-
-          <p>The result of attempting to send delivery reports using
-            <tp:member-ref>SendMessage</tp:member-ref> is currently
-            undefined.</p>
-
-          <h4>Example delivery reports</h4>
-
-          <dl>
-            <dt>A minimal delivery report indicating permanent failure of the
-              sent message whose token was
-              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code> for an unknown
-              reason</dt>
-            <dd><pre>
-[{
-# header
-'message-sender': 123,
-'message-type': Channel_Text_Message_Type_Delivery_Report,
-'delivery-status': Delivery_Status_Permanently_Failed,
-'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
-}
-# no body
-]</pre></dd>
-
-            <dt>A delivery report where the failed message is echoed back to the
-              sender rather than being referenced by ID, and the failure reason
-              is that this protocol cannot send messages to offline contacts
-              such as the contact with handle 123</dt>
-            <dd><pre>
-[{ # header
-'message-sender': 123,
-'message-type': Channel_Text_Message_Type_Delivery_Report,
-'delivery-status': Delivery_Status_Temporarily_Failed,
-'delivery-error': Channel_Text_Send_Error_Offline,
-'delivery-echo':
-    [{ # header of original message
-    'message-sender': 1,
-    'message-sent': 1210067943,
-    },
-    { # body of original message
-    'content-type': 'text/plain',
-    'content': 'Hello, world!',
-    }]
-  ],
-
-# no body
-]</pre></dd>
-
-            <dt>A maximally complex delivery report: the server reports a
-              bilingual human-readable failure message because the user sent
-              a message "Hello, world!" with token
-              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code> to a contact
-              with handle 123, but that handle represents a contact who does not
-              actually exist</dt>
-            <dd><pre>
-[{ # header
-'message-sender': 123,
-'message-type': Channel_Text_Message_Type_Delivery_Report,
-'delivery-status': Delivery_Status_Permanently_Failed,
-'delivery-error': Channel_Text_Send_Error_Invalid_Contact,
-'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
-'delivery-echo':
-    [{ # header of original message
-    'message-sender': 1,
-    'message-sent': 1210067943,
-    },
-    { # body of original message
-    'content-type': 'text/plain',
-    'content': 'Hello, world!',
-    }]
-  ],
-},
-{ # message from server (alternative in English)
-'alternative': '404',
-'content-type': 'text/plain',
-'lang': 'en',
-'content': 'I have no contact with that name',
-},
-{ # message from server (alternative in German)
-'alternative': '404'.
-'content-type': 'text/plain',
-'lang': 'de',
-'content', 'Ich habe keinen Kontakt mit diesem Namen',
-}
-]</pre></dd>
-
-            <dt>A minimal delivery report indicating successful delivery
-              of the sent message whose token was
-              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code></dt>
-            <dd><pre>
-[{
-# header
-'message-sender': 123,
-'message-type': Channel_Text_Message_Type_Delivery_Report,
-'delivery-status': Delivery_Status_Delivered,
-'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
-}
-# no body
-]</pre></dd>
-
-          </dl>
-
-        </div>
-      </tp:docstring>
-
-      <tp:member name="Key" type="s">
-        <tp:docstring>
-          A key, which SHOULD be one of the well-known keys specified by
-          <tp:type>Message_Header_Key</tp:type>,
-          <tp:type>Message_Body_Key</tp:type> or
-          <tp:type>Delivery_Report_Header_Key</tp:type> if possible.
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member name="Value" type="v">
-        <tp:docstring>
-          The value corresponding to the given key, which SHOULD be one of the
-          specified types for well-known keys.
-        </tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <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
-          with the corresponding value types. Some keys make sense for both
-          incoming and outgoing messages, while others are only meaningful for
-          one or the other.</p>
-
-          <dl>
-            <dt>message-token (s -
-              <tp:type>Protocol_Message_Token</tp:type>)
-            </dt>
-            <dd>
-              <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, 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>
-
-            <dt>message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
-            <dd>The time the message was sent (if unavailable, the time
-              it arrived at a central server MAY be used). Omitted if no
-              reasonable approximation is available; SHOULD always be present
-              on outgoing messages.</dd>
-
-            <dt>message-received (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
-            <dd>The time the message was received locally. SHOULD always
-              be present.</dd>
-
-            <dt>message-sender (u - <tp:type>Contact_Handle</tp:type>)</dt>
-            <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>
-
-            <dt>message-type (u - <tp:type>Channel_Text_Message_Type</tp:type>)
-            </dt>
-            <dd>The type of message; if omitted,
-              Channel_Text_Message_Type_Normal MUST be assumed. MAY
-              be omitted for normal chat messages.</dd>
-
-            <dt>supersedes (s – <tp:type>Protocol_Message_Token</tp:type>)</dt>
-            <dd>If present, this message supersedes a previous message,
-              identified by its <tt>message-token</tt> header. The user
-              interface MAY, for example, choose to replace the superseded
-              message with this message, or grey out the superseded message.
-
-              <tp:rationale>Skype, for example, allows the user to amend
-                messages they have already sent (to correct typos,
-                etc.).</tp:rationale>
-
-              Connection Managers SHOULD represent repeatedly edited messages
-              in the following form:
-              <pre>
-                message {token = a};
-                message {token = b, supersedes = a};
-                message {token = c, supersedes = a};
-              </pre>
-
-              <tp:rationale>The alternative form is:
-                <pre>
-                  message {token = a};
-                  message {token = b, supersedes = a};
-                  message {token = c, supersedes = b};
-                </pre>
-                but it is more difficult to implement in UIs/loggers, and it
-                breaks irrecoverably if message b is lost. If a CM is forced
-                to use this form, it should be tested extensively for
-                interoperability with existing clients.
-                </tp:rationale>
-
-              Clients should deal gracefully if the original message gets
-              lost, but one or more corrections to it get through:
-              <pre>
-                message {token = x} gets lost;
-                message {token = y, supersedes = x};
-                message {token = z, supersedes = x};
-              </pre>
-
-              <tp:rationale>This is the form that CMs will use to mean "I know
-                that this message was edited, but I don't know what it
-                originally said." It is often in the interests of the
-                remote side for message x to be lost (e.g. to hide
-                embarassing mistakes or sensitive information) so it might not
-                be possible to retrieve it (even on protocols with reliable
-                message-delivery guarantees).</tp:rationale></dd>
-
-            <dt>original-message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
-            <dd>The <tt>message-sent</tt> header of the message that this
-              one supersedes.
-              This key should only be present if <tt>supersedes</tt> is also
-              present. It MAY be used as a hint to help clients locate the
-              original message in its logs. If present, comparing the tuple
-              (original-message-sent, supersedes) with (message-sent,
-              message-token) SHOULD be enough to uniquely
-              identify the original message.</dd>
-
-            <dt>original-message-received (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
-            <dd>The <tt>message-received</tt> header of the message that this
-              one supersedes.
-              This key should only be present if <tt>supersedes</tt> is also
-              present. It MAY be used as a hint in a similar way to
-              <tt>original-message-sent</tt>.</dd>
-
-            <dt>pending-message-id (u - <tp:type>Message_ID</tp:type>)</dt>
-            <dd>The incoming message ID. This MUST NOT be present on outgoing
-              messages. Clients SHOULD NOT store this key - it is only valid
-              for as long as the message remains unacknowledged.</dd>
-
-            <dt>interface (s - <tp:type>DBus_Interface</tp:type>)</dt>
-            <dd>This message is specific to the given interface, which is
-              neither Text nor Messages. It SHOULD be ignored if that
-              interface is not supported. (Note that an 'interface' key
-              can also appear on the second and subsequent parts, where
-              it indicates that that part (only) should be ignored if
-              unsupported.)</dd>
-
-            <dt>scrollback (b)</dt>
-            <dd>If present and true, the incoming message was part of a
-              replay of message history (this matches the Scrollback flag in
-              <tp:type>Channel_Text_Message_Flags</tp:type>). This flag
-              does not make sense on outgoing messages and SHOULD NOT
-              appear there.</dd>
-
-            <dt>rescued (b)</dt>
-            <dd>If present and true, the incoming message has been seen in
-              a previous channel during the lifetime of the Connection,
-              but had not been acknowledged when that channel closed, causing
-              an identical channel (in which the message now appears) to open.
-              This matches the Rescued flag in
-              <tp:type>Channel_Text_Message_Flags</tp:type>; it
-              does not make sense on outgoing messages, and SHOULD NOT
-              appear there.</dd>
-          </dl>
-
-      </tp:docstring>
-    </tp:simple-type>
-
-    <tp:simple-type type="s" name="Message_Body_Key">
-      <tp:added version="0.19.8"/>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Well-known keys for the second and subsequent
-          <tp:type>Message_Part</tp:type>s of a message, which contain the
-          message content, along with the corresponding value types.</p>
-
-          <dl>
-            <dt>identifier (s —
-              <tp:type>Protocol_Content_Identifier</tp:type>)</dt>
-            <dd>An opaque identifier for this part.
-              Parts of a message MAY reference other parts by treating
-              this identifier as if it were a MIME Content-ID and using
-              the cid: URI scheme.</dd>
-
-            <dt>alternative (s)</dt>
-            <dd>
-              <p>If present, this part of the message is an alternative for
-                all other parts with the same value for "alternative".
-                Clients SHOULD only display one of them (this is expected to
-                be used for XHTML messages in a future version of this
-                specification).</p>
-
-              <p>If omitted, this part is not an alternative for any other
-                part.</p>
-
-              <p>Parts of a message MAY reference the group of alternatives
-                as a whole (i.e. a reference to whichever of them is chosen)
-                by treating this identifier as if it were the MIME Content-ID
-                of a multipart/alternative part, and using the cid: URI
-                scheme.</p>
-            </dd>
-
-            <dt>content-type (s)</dt>
-            <dd>
-              <p>The MIME type of this part. See the documentation
-                for <tp:member-ref>MessageReceived</tp:member-ref> and
-                <tp:member-ref>MessageSent</tp:member-ref> for notes on the
-                special status of "text/plain" parts.</p>
-
-              <p>Connection managers MUST NOT signal parts without a
-                'content-type' key; if a protocol provides no way to determine
-                the MIME type, the connection manager is responsible for
-                guessing it, but MAY fall back to "text/plain" for text and
-                "application/octet-stream" for non-text.</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>
-            <dd>The natural language of this part, identified by a
-              RFC 3066 language tag.
-
-              <tp:rationale>
-                XMPP allows alternative-selection by language as well as
-                by content-type.
-              </tp:rationale>
-            </dd>
-
-            <dt>size (u)</dt>
-            <dd>The size in bytes (if needs-retrieval is true, this MAY be an
-              estimated or approximate size). SHOULD be omitted if 'content'
-              is provided.
-
-              <tp:rationale>
-                There's no point in providing the size if you're already
-                providing all the content.
-              </tp:rationale>
-            </dd>
-
-            <dt>thumbnail (b)</dt>
-            <dd>
-              <p>This part is a thumbnail. To represent an image together with
-                its thumbnail in a single message, there should be one part for
-                the full image followed by a part for the thumbnail (following
-                the “more complete versions first” requirement), with the same
-                'alternative' value. For example:</p>
-
-              <pre>
-[ ... ,
-  { 'alternative': 'catphoto',
-    'content-type': 'image/jpeg',
-    'size': 150000,
-    'content': [0xFF, 0xD8, ... 0xFF 0xD9],
-  },
-  { 'alternative': 'catphoto',
-    'content-type': 'image/jpeg'
-    'size': 1024,
-    'thumbnail': True,
-    'content': [0xFF, 0xD8, ... 0xFF 0xD9],
-  },
-  ...
-]</pre>
-            </dd>
-
-            <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 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 has been truncated
-              by the server or connection manager (equivalent to
-              Channel_Text_Message_Flag_Truncated in the Text interface).
-            </dd>
-
-            <dt>content (s or ay)</dt>
-            <dd>The part's content, if it is available and
-              sufficiently small to include here (implies that
-              'needs-retrieval' is false or omitted). Otherwise, omitted.
-              If the part is human-readable text or HTML, the value for this
-              key MUST be a UTF-8 string (D-Bus signature 's').
-              If the part is not text, the value MUST be a byte-array
-              (D-Bus signature 'ay'). If the part is a text-based format
-              that is not the main body of the message (e.g. an iCalendar
-              or an attached XML document), the value SHOULD be a UTF-8 string,
-              transcoding from another charset to UTF-8 if necessary, but
-              MAY be a byte-array (of unspecified character set) if
-              transcoding fails or the source charset is not known.</dd>
-
-              <!-- FIXME: "sufficiently small to include" is not currently
-              defined; we should add some API so clients can tell the
-                CM how large a message it should emit in the signal.-->
-
-            <dt>interface (s - <tp:type>DBus_Interface</tp:type>)</dt>
-            <dd>This part is specific to the given interface, which is
-              neither Text nor Messages. It SHOULD be ignored if that
-              interface is not supported. (Note that an 'interface' key
-              can also appear on the first part, where it indicates that the
-              entire message should be ignored if unsupported.)</dd>
-          </dl>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <tp:simple-type type="s" name="Delivery_Report_Header_Key">
-      <tp:added version="0.19.8"/>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Well-known keys for the first <tp:type>Message_Part</tp:type> of a
-          delivery report, along with the corresponding value types. Some of
-          these are special-cases of headers defined by
-          <tp:type>Message_Header_Key</tp:type>.</p>
-
-          <dl>
-            <dt>message-sender (u - <tp:type>Contact_Handle</tp:type>, as
-              defined by <tp:type>Message_Header_Key</tp:type>)</dt>
-            <dd>MUST be the intended recipient of the original message, if
-              available (zero or omitted if the intended recipient is
-              unavailable or is not a contact, e.g. a chatroom), even if the
-              delivery report actually came from an intermediate server.</dd>
-
-            <dt>message-type (u - <tp:type>Channel_Text_Message_Type</tp:type>,
-              as defined by <tp:type>Message_Header_Key</tp:type>)</dt>
-            <dd>MUST be Channel_Text_Message_Type_Delivery_Report.</dd>
-
-            <dt>delivery-status (u - <tp:type>Delivery_Status</tp:type>)</dt>
-            <dd>The status of the message. All delivery reports MUST contain
-              this key in the first Message_Part.</dd>
-
-            <dt>delivery-token (s - <tp:type>Protocol_Message_Token</tp:type>)</dt>
-
-            <dd>
-              <p>An identifier for the message to which this delivery report
-                refers. MUST NOT be an empty string. Omitted if not
-                available.</p>
-
-              <p>Clients may match this against the token produced by the
-                SendMessage method and MessageSent signal. A status report
-                with no token could match any sent message, and a sent
-                message with an empty token could match any status report.
-                If multiple sent messages match, clients SHOULD use some
-                reasonable heuristic.</p>
-
-              <tp:rationale>
-                In an ideal world, we could unambiguously match reports
-                against messages; however, deployed protocols are not ideal,
-                and not all reports and messages can be matched.
-              </tp:rationale>
-            </dd>
-
-            <dt>delivery-error (u -
-              <tp:type>Channel_Text_Send_Error</tp:type>)</dt>
-            <dd>
-              The reason for the failure. MUST be omitted if this was a
-              successful delivery; SHOULD be omitted if it would be
-              Channel_Text_Send_Error_Unknown.
-            </dd>
-
-            <dt>delivery-dbus-error (s -
-              <tp:type>DBus_Error_Name</tp:type>)</dt>
-            <dd>
-              The reason for the failure, specified as a (possibly
-              implementation-specific) D-Bus error. MUST be omitted if this was
-              a successful delivery. If set, the 'delivery-error' key SHOULD be
-              set to the closest available value.
-            </dd>
-
-            <dt>delivery-error-message (s)</dt>
-            <dd>
-              Debugging information on why the message could not be delivered.
-              MUST be omitted if this was a successful delivery; MAY always be
-              omitted.
-            </dd>
-
-            <dt>delivery-echo (aa{sv} - <tp:type>Message_Part[]</tp:type>)</dt>
-            <dd>
-              <p>The message content, as defined by the Messages interface.
-                Omitted if no content is available. Content MAY have been
-                truncated, message parts MAY have been removed, and message
-                parts MAY have had their content removed (i.e. the message part
-                metadata is present, but the 'content' key is not).</p>
-
-              <tp:rationale>
-                Some protocols, like XMPP, echo the failing message back to
-                the sender. This is sometimes the only way to match it
-                against the sent message, so we include it here.
-              </tp:rationale>
-            </dd>
-
-          </dl>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <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.
-      </tp:docstring>
-    </tp:simple-type>
-
-    <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>.
-      </tp:docstring>
-
-      <tp:member type="u" tp:type="Message_Part_Index" name="Part">
-        <tp:docstring>
-          Indexes into the array of <tp:type>Message_Part</tp:type>s that
-          represents a message. The "headers" part (which is not a valid
-          argument to GetPendingMessageContent) is considered to be part 0,
-          so the valid part numbers start at 1 (for the second message part).
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member type="v" name="Content">
-        <tp:docstring>
-          The message part's content. The variant MUST contain either type
-          's' or 'ay' (UTF-8 text string, or byte array), following the
-          same rules as for the value of the 'content' key in
-          the <tp:type>Message_Part</tp:type> mappings.
-        </tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <tp:simple-type type="s" name="Protocol_Message_Token"
-                    array-name="Protocol_Message_Token_List">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>An opaque token used to identify messages in the underlying.
-          protocol. As a special case, the empty string indicates that there
-          is no particular identification for a message.</p>
-
-        <p>CM implementations SHOULD use an identifier expected to be unique,
-          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
-          byte), and some implementations send non-unique identifiers (some
-          XMPP clients use very simple message IDs, such as an incrementing
-          integer that resets to 1 at the beginning of each connection). As a
-          result, clients MUST NOT assume that protocol tokens will not be
-          re-used.</p>
-
-        <p>In particular, clients SHOULD use a heuristic to assign delivery
-          reports to messages, such as matching on message content or
-          timestamp (if available), or assuming that the delivery report
-          refers to the most recent message with that ID.</p>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <tp:simple-type name="Protocol_Content_Identifier" type="s">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A protocol-specific identifier for a blob of content, as used for
-          the <tt>identifier</tt> key in a <tp:type>Message_Part</tp:type>. The
-          same identifier MAY be re-used if the same content, byte-for-byte,
-          appears as a part of several messages.</p>
-
-        <tp:rationale>
-          <p>On XMPP, these identifiers might be Content-IDs for custom
-            smileys implemented using <a
-              href="http://xmpp.org/extensions/xep-0231.html">XEP-0232 Bits of
-            Binary</a>; the same smiley might well appear in multiple
-            messages.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <method name="SendMessage" tp:name-for-bindings="Send_Message">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Submit a message to the server for sending.
-          If this method returns successfully, the message has been submitted
-          to the server and the <tp:member-ref>MessageSent</tp:member-ref>
-          signal is emitted. A corresponding
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.Text">Sent</tp:dbus-ref>
-          signal on the Text interface MUST also be emitted.</p>
-
-        <p>This method MUST return before the MessageSent signal is
-          emitted.</p>
-
-        <tp:rationale>
-          <p>This means that the process sending the message is the first
-            to see the <tp:type>Protocol_Message_Token</tp:type>, and can
-            relate the message to the corresponding
-            <tp:member-ref>MessageSent</tp:member-ref> signal by comparing
-            message tokens (if supported by the protocol).</p>
-        </tp:rationale>
-
-        <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:value-ref type="Channel_Text_Message_Type">Delivery_Report</tp:value-ref>.
-          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.
-          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"
-        tp:type="Message_Sending_Flags">
-        <tp:docstring>
-          Flags affecting how the message is sent. The channel MAY ignore some
-          or all flags, depending on
-          <tp:member-ref>DeliveryReportingSupport</tp:member-ref>; the flags
-          that were handled by the CM are provided in
-          <tp:member-ref>MessageSent</tp:member-ref>.
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" type="s" tp:type="Protocol_Message_Token"
-        name="Token">
-        <tp:docstring>
-          An opaque token used to match any incoming delivery or failure
-          reports against this message, or an empty string if the message
-          is not readily identifiable.
-        </tp:docstring>
-      </arg>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The requested message is malformed and cannot be sent.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <tp:flags name="Message_Sending_Flags" value-prefix="Message_Sending_Flag"
-      type="u">
-      <tp:docstring>
-        Flags altering the way a message is sent. The "most usual" action
-        should always be to have these flags unset. Some indication of which
-        flags are supported is provided by the
-        <tp:member-ref>DeliveryReportingSupport</tp:member-ref> property.
-      </tp:docstring>
-
-      <tp:flag suffix="Report_Delivery" value="1">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Provide a successful delivery report if possible, even if this is
-            not the default for this protocol. Ignored if delivery reports are
-            not possible on this protocol.</p>
-
-          <tp:rationale>
-            <p>In some protocols, like XMPP, it is not conventional to request
-              or send positive delivery notifications.</p>
-          </tp:rationale>
-
-          <p>Delivery failure reports SHOULD always be sent, but if this flag
-            is present, the connection manager MAY also try harder to obtain
-            failed delivery reports or allow them to be matched to outgoing
-            messages.</p>
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Report_Read" value="2">
-        <tp:added version="0.19.9"/>
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Provide a delivery report when the message is read by the
-            recipient, even if this is not the default for this protocol.
-            Ignored if read reports are not possible on this protocol.</p>
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Report_Deleted" value="4">
-        <tp:added version="0.19.9"/>
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Provide a delivery report when the message is deleted by the
-            recipient, even if this is not the default for this protocol.
-            Ignored if such reports are not possible on this protocol.</p>
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-    <signal name="MessageSent" tp:name-for-bindings="Message_Sent">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Signals that a message has been submitted for sending. This
-          MUST be emitted exactly once per emission of the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.Text">Sent</tp:dbus-ref>
-          signal on the Text interface, for backwards-compatibility; clients
-          SHOULD ignore the latter if this interface is present, as mentioned
-          in the introduction.</p>
-
-        <p>This SHOULD be emitted as soon as the CM determines it's
-          theoretically possible to send the message (e.g. the parameters are
-          supported and correct).</p>
-
-        <tp:rationale>
-          <p>This signal allows a process that is not the caller of
-            SendMessage to log sent messages.</p>
-        </tp:rationale>
-      </tp:docstring>
-
-      <arg type="aa{sv}" tp:type="Message_Part[]" name="Content">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The message content (see <tp:type>Message_Part</tp:type> for full
-            details). If the message that was passed to
-            <tp:member-ref>SendMessage</tp:member-ref> has a formatted text
-            part that the connection manager recognises, but no
-            <tt>text/plain</tt> alternative, the CM MUST use the formatted text
-            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
-            argument to SendMessage (if the message is truncated,
-            formatting or alternatives are dropped, etc., then the edited
-            version SHOULD appear in this signal).</p>
-        </tp:docstring>
-      </arg>
-
-      <arg name="Flags" type="u" tp:type="Message_Sending_Flags">
-        <tp:docstring>
-          <p>Flags affecting how the message was sent.  The flags might be a
-            subset of those passed to SendMessage if the caller requested
-            unsupported flags.</p>
-        </tp:docstring>
-      </arg>
-
-      <arg name="Message_Token" type="s" tp:type="Protocol_Message_Token">
-        <tp:docstring>
-          An opaque token used to match any incoming delivery or failure
-          reports against this message, or an empty string if the message
-          is not readily identifiable.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <property name="PendingMessages" type="aaa{sv}" access="read"
-      tp:type="Message_Part[][]" tp:name-for-bindings="Pending_Messages">
-      <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>
-
-    <signal name="PendingMessagesRemoved"
-      tp:name-for-bindings="Pending_Messages_Removed">
-      <tp:docstring>
-        The messages with the given IDs have been removed from the
-        <tp:member-ref>PendingMessages</tp:member-ref> list. Clients SHOULD NOT
-        attempt to acknowledge those messages.
-
-        <tp:rationale>
-          This completes change notification for the PendingMessages property
-          (previously, there was change notification when pending messages
-          were added, but not when they were removed).
-        </tp:rationale>
-      </tp:docstring>
-
-      <arg name="Message_IDs" type="au" tp:type="Message_ID[]">
-        <tp:docstring>
-          The messages that have been removed from the pending message list.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <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
-        to return if the part's 'needs-retrieval' flag is true; consider
-        extending the default D-Bus method call timeout. Additional API is
-        likely to be added in future, to stream large message parts.
-      </tp:docstring>
-
-      <arg name="Message_ID" type="u" tp:type="Message_ID" direction="in">
-        <tp:docstring>
-          The ID of a pending message
-        </tp:docstring>
-      </arg>
-
-      <arg name="Parts" type="au" direction="in"
-        tp:type="Message_Part_Index[]">
-        <tp:docstring>
-          The desired entries in the array of message parts, identified by
-          their position. The "headers" part (which is not a valid argument
-          to this method) is considered to be part 0, so the valid part
-          numbers start at 1 (for the second Message_Part).
-        </tp:docstring>
-      </arg>
-
-      <arg name="Content" type="a{uv}" direction="out"
-        tp:type="Message_Part_Content_Map">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The content of the requested parts. The keys in this mapping
-            are positions in the array of message parts; the values are
-            either of type 's' or 'ay' (UTF-8 text string, or byte array),
-            following the same rules as for the value of the 'content' key in
-            the <tp:type>Message_Part</tp:type> mappings.</p>
-
-          <p>If the one of the requested part numbers was greater than zero
-            but referred to a part that had no content (i.e. it had no
-            'content-type' key or no 'content' key), it is simply omitted from
-            this mapping; this is not considered to be an error condition.</p>
-        </tp:docstring>
-      </arg>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-            Either there is no pending message with the given message ID,
-            or one of the part numbers given was 0 or too large.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="MessageReceived" tp:name-for-bindings="Message_Received">
-      <tp:docstring>
-        Signals that a message has been received and added to the pending
-        messages queue. This MUST be emitted exactly once per emission of the
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.Text">Received</tp:dbus-ref>
-        signal on the Text interface, for backwards-compatibility; clients
-        SHOULD ignore the latter in favour of this signal if this interface is
-        present, as mentioned in the introduction.
-      </tp:docstring>
-
-      <arg type="aa{sv}" tp:type="Message_Part[]" name="Message">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The message content, including any attachments or alternatives. If
-            the incoming message contains formatted text without a plain text
-            alternative, the connection manager MUST generate a
-            <tt>text/plain</tt> alternative from the formatted text, and
-            include it in this message (both here, and in the
-            <tp:member-ref>PendingMessages</tp:member-ref> property).</p>
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <tp:enum name="Delivery_Status" value-prefix="Delivery_Status"
-      plural="Delivery_Statuses" type="u">
-      <tp:docstring>
-        <p>The status of a message as indicated by a delivery report.</p>
-
-        <p>If this enum is extended in future specifications, this should
-          only be to add new, non-overlapping conditions (i.e. all failures
-          should still be signalled as either Temporarily_Failed
-          or Permanently_Failed). If additional detail is required (e.g.
-          distinguishing between the various types of permanent failure) this
-          will be done using additional
-          <tp:type>Delivery_Report_Header_Key</tp:type>s.</p>
-      </tp:docstring>
-
-      <tp:enumvalue suffix="Unknown" value="0">
-        <tp:docstring>
-          The message's disposition is unknown.
-          Clients SHOULD consider all messages to have status
-          Delivery_Status_Unknown unless otherwise specified; connection
-          managers SHOULD NOT signal this delivery status explicitly.
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Delivered" value="1">
-        <tp:docstring>
-          The message has been delivered to the intended recipient.
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Temporarily_Failed" value="2">
-        <tp:docstring>
-          Delivery of the message has failed. Clients SHOULD notify the user,
-          but MAY automatically try sending another copy of the message.
-
-          <tp:rationale>
-            Similar to errors with type="wait" in XMPP; analogous to
-            4xx errors in SMTP.
-          </tp:rationale>
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Permanently_Failed" value="3">
-        <tp:docstring>
-          Delivery of the message has failed. Clients SHOULD NOT try again
-          unless by specific user action. If the user does not modify the
-          message or alter configuration before re-sending, this error is
-          likely to happen again.
-
-          <tp:rationale>
-            Similar to errors with type="cancel", type="modify"
-            or type="auth" in XMPP; analogous to 5xx errors in SMTP.
-          </tp:rationale>
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Accepted" value="4">
-        <tp:docstring>
-          An intermediate server has accepted the message but the message
-          has not been yet delivered to the ultimate recipient. The
-          connection manager might send a Failed report or Delivered report
-          later.
-
-          <tp:rationale>
-            Similar to "202 Accepted" success code in SIP; analogous to
-            251 and 252 responses in SMTP.
-          </tp:rationale>
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Read" value="5">
-        <tp:added version="0.19.9"/>
-        <tp:docstring>
-          The message has been read by the intended recipient.
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Deleted" value="6">
-        <tp:added version="0.19.9"/>
-        <tp:docstring>
-          The message has been deleted by the intended recipient. This MAY be
-          signalled on its own if the message is deleted without being read, or
-          after <code>Read</code> if the message was read before being deleted.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:flags name="Delivery_Reporting_Support_Flags"
-      value-prefix="Delivery_Reporting_Support_Flag" type="u">
-      <tp:docstring>
-        Flags indicating the level of support for delivery reporting on this
-        channel, as found on the
-        <tp:member-ref>DeliveryReportingSupport</tp:member-ref> property. Any
-        future flags added to this set will conform to the
-        convention that the presence of an extra flag implies that
-        more operations will succeed. Note that CMs may always provide more
-        reports than are requested in the
-        <tp:type>Message_Sending_Flags</tp:type> passed to
-        <tp:member-ref>SendMessage</tp:member-ref>.
-
-        <tp:rationale>
-          If senders want delivery reports, they should ask for them.  If they
-          don't want delivery reports, they can just ignore them, so there's no
-          need to have capability discovery for what will happen if a delivery
-          report isn't requested.
-        </tp:rationale>
-      </tp:docstring>
-
-      <tp:flag suffix="Receive_Failures" value="1">
-        <tp:docstring>
-          Clients MAY expect to receive negative delivery reports if
-          Message_Sending_Flag_Report_Delivery is specified when sending.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Receive_Successes" value="2">
-        <tp:docstring>
-          Clients MAY expect to receive positive delivery reports if
-          Message_Sending_Flag_Report_Delivery is specified when sending.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Receive_Read" value="4">
-        <tp:added version="0.19.9"/>
-        <tp:docstring>
-          Clients MAY expect to receive <tp:type>Delivery_Status</tp:type>
-          <code>Read</code> reports if Message_Sending_Flag_Report_Read
-          is specified when sending.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Receive_Deleted" value="8">
-        <tp:added version="0.19.9"/>
-        <tp:docstring>
-          Clients MAY expect to receive <tp:type>Delivery_Status</tp:type>
-          <code>Deleted</code> reports if Message_Sending_Flag_Report_Deleted
-          is specified when sending.
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-    <property name="DeliveryReportingSupport" access="read"
-      tp:type="Delivery_Reporting_Support_Flags" type="u"
-      tp:name-for-bindings="Delivery_Reporting_Support"
-      tp:immutable="yes">
-      <tp:docstring>
-        A bitfield indicating features supported by this channel.
-      </tp:docstring>
-    </property>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Password.xml b/spec/Channel_Interface_Password1.xml
index 8f08627e..e2a35b82 100644
--- a/spec/Channel_Interface_Password.xml
+++ b/spec/Channel_Interface_Password1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Password" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Password1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>
 Copyright © 2005-2011 Collabora Limited
 Copyright © 2005-2009 Nokia Corporation
@@ -20,8 +20,8 @@ You should have received a copy of the GNU Lesser General Public
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Password">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Interface.Password1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:flags name="Channel_Password_Flags" value-prefix="Channel_Password_Flag" type="u">
       <tp:flag suffix="Provide" value="8">
         <tp:docstring>
@@ -32,7 +32,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Hint" value="4">
         <tp:added version="0.25.0"/>
         <tp:docstring>
-          The <tp:dbus-ref namespace="ofdT.Channel.Interface">RoomConfig1.PasswordHint</tp:dbus-ref>
+          The <tp:dbus-ref namespace="imt1.Channel.Interface">RoomConfig1.PasswordHint</tp:dbus-ref>
           contains a hint for the password.
         </tp:docstring>
       </tp:flag>
@@ -51,8 +51,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         which operations are currently valid.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
     <signal name="PasswordFlagsChanged"
@@ -90,9 +90,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         proceed if the 'provide' password flag is set.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -106,7 +106,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <p>Once the user has joined the channel, the current
         password-protectedness of the room can be checked (and possibly
         modified) using the <tp:dbus-ref
-        namespace='ofdT.Channel.Interface'>RoomConfig1</tp:dbus-ref>
+        namespace='imt1.Channel.Interface'>RoomConfig1</tp:dbus-ref>
         interface, if implemented.</p>
     </tp:docstring>
   </interface>
diff --git a/spec/Channel_Interface_Picture.xml b/spec/Channel_Interface_Picture1.xml
index fb2fcf3d..ae1bbeb9 100644
--- a/spec/Channel_Interface_Picture.xml
+++ b/spec/Channel_Interface_Picture1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Picture"
+<node name="/Channel_Interface_Picture1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2011 Collabora Ltd.</tp:copyright>
@@ -20,9 +20,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Picture1"
+  <interface name="im.telepathy1.Channel.Interface.Picture1"
              tp:causes-havoc="draft">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.25.0"/>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
                 value="true"/>
@@ -31,13 +31,13 @@
       <p>An interface channels can implement to support a picture. Most
         of the time this will be implemented by channels implementing
         the <tp:dbus-ref
-        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        namespace="imt1.Channel.Interface">Room1</tp:dbus-ref>
         interface. Note that this interface is not restricted to
         Text channels, and can also be used on Call channels.</p>
 
       <tp:rationale>
         This is a separate interface from
-        <tp:dbus-ref namespace="ofdT.Channel.Interface">RoomConfig1</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Channel.Interface">RoomConfig1</tp:dbus-ref>
         because (a) it's possible some protocol might support pictures for
         1:1 chats; and (b) it avoids downloading an unwanted picture in a
         GetAll request.
@@ -62,14 +62,14 @@
           further changes by other users or the server.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             Picture is somehow invalid: e.g. unsupported MIME type,
             too big, etc.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Channel_Interface_Room.xml b/spec/Channel_Interface_Room1.xml
index 92423b67..f0cad304 100644
--- a/spec/Channel_Interface_Room.xml
+++ b/spec/Channel_Interface_Room1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Room"
+<node name="/Channel_Interface_Room1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -21,8 +21,8 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Room2">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Interface.Room1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.24.0">(version 2)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -45,9 +45,9 @@
 
       <p>This interface intends to support and differentiate these mechanisms
         more clearly than the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
         and <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
         properties can alone. It initially contains a pair of properties used
         to represent the human-readable parts of a
         <tp:type>Room_Handle</tp:type>'s identifier, if any. The above examples
@@ -57,10 +57,10 @@
         <li>The IRC channel <tt>#telepathy</tt> on Freenode is represented by a
           channel with properties
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>Room</code>,
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
           = <code>"#telepathy"</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>"#telepathy"</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
@@ -78,10 +78,10 @@
 
         <li>A Skype group chat with opaque identifier <tt>0xdeadbeef</tt> has
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>Room</code>,
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
           = <code>"0xdeadbeef"</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
@@ -90,7 +90,7 @@
 
         <li>An MSN group chat has
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>None</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
@@ -101,10 +101,10 @@
         <li>A standard Jabber multi-user chat
           <tt>jdev@conference.jabber.org</tt> has
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>Room</code>,
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
           = <code>"jdev@conference.jabber.org"</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>"jdev"</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>"conference.jabber.org"</code>.
@@ -112,10 +112,10 @@
 
         <li>A Google Talk private MUC <tt>private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com</tt> has
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>Room</code>,
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
           = <code>"private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com"</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> =
@@ -127,10 +127,10 @@
         <li>Similarly, a XEP-0045 §10.1.4 uniquely-named room
           <tt>lrcgsnthzvwm@conference.jabber.org</tt> has
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
           = <code>Room</code>,
           <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
           = <code>"lrcgsnthzvwm@conference.jabber.org"</code>,
           <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> =
@@ -148,21 +148,21 @@
 
       <blockquote>
         <pre>
-( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+( Fixed = { ...<tp:dbus-ref namespace="im.telepathy1.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type"
                                         >Text</tp:dbus-ref>,
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            ...<tp:dbus-ref namespace="im.telepathy1.Channel"
             >TargetHandleType</tp:dbus-ref>: Room,
           },
-  Allowed = [ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+  Allowed = [ ...<tp:dbus-ref namespace="im.telepathy1.Channel"
               >TargetID</tp:dbus-ref>,
-              ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              ...<tp:dbus-ref namespace="im.telepathy1.Channel"
               >TargetHandle</tp:dbus-ref>,
             ]
 )</pre></blockquote>
 
-      <p>Channel requests must specify either <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-        >TargetID</tp:dbus-ref> or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+      <p>Channel requests must specify either <tp:dbus-ref namespace="im.telepathy1.Channel"
+        >TargetID</tp:dbus-ref> or <tp:dbus-ref namespace="im.telepathy1.Channel"
         >TargetHandle</tp:dbus-ref>.</p>
 
       <p>If, like IRC, the room identifiers are also human-readable, the
@@ -170,22 +170,22 @@
 
       <blockquote>
         <pre>
-( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+( Fixed = { ...<tp:dbus-ref namespace="im.telepathy1.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type"
                                         >Text</tp:dbus-ref>,
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            ...<tp:dbus-ref namespace="im.telepathy1.Channel"
             >TargetHandleType</tp:dbus-ref>: Room,
           },
-  Allowed = [ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+  Allowed = [ ...<tp:dbus-ref namespace="im.telepathy1.Channel"
               >TargetID</tp:dbus-ref>,
-              ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+              ...<tp:dbus-ref namespace="im.telepathy1.Channel"
               >TargetHandle</tp:dbus-ref>,
               ...<tp:member-ref>RoomName</tp:member-ref>
             ]
 ),
 
-( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+( Fixed = { ...<tp:dbus-ref namespace="im.telepathy1.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type"
                                         >Text</tp:dbus-ref>
           },
   Allowed = [ ...<tp:member-ref>RoomName</tp:member-ref>,
@@ -193,20 +193,20 @@
 )</pre></blockquote>
 
       <p>Requests may specify the RoomName in place of
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref> or
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
         . Note how <tp:member-ref>RoomName</tp:member-ref> appears
         in <var>Allowed_Properties</var> of a different RCC because
-        when <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        when <tp:dbus-ref namespace="im.telepathy1.Channel"
         >TargetHandleType</tp:dbus-ref> is omitted (or is None), both
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        <tp:dbus-ref namespace="im.telepathy1.Channel"
         >TargetHandle</tp:dbus-ref> and
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+        <tp:dbus-ref namespace="im.telepathy1.Channel"
         >TargetID</tp:dbus-ref> must also be omitted.
         <tp:member-ref>RoomName</tp:member-ref> is allowed in conjuction
         with
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref> or
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
         in some situations, as explained below in the <em>Requesting room
         channels</em> section.
       </p>
@@ -217,22 +217,22 @@
         <tp:member-ref>Server</tp:member-ref> if not explicitly
         specified in a channel request. The CM's default server MAY
         be configurable by a connection parameter specified on a
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.ConnectionManager"
+        <tp:dbus-ref namespace="im.telepathy1.ConnectionManager"
         >RequestConnection</tp:dbus-ref> call, similarly to how the
         fallback conference server is specified on jabber connections in
         gabble.</p>
 
       <p>If the protocol supports unnamed rooms, <tp:member-ref>RoomName</tp:member-ref>
         should be fixed to the empty string, and
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
         should be None:</p>
 
       <blockquote>
         <pre>
-( Fixed = { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
-            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+( Fixed = { ...<tp:dbus-ref namespace="im.telepathy1.Channel"
+            >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type"
                                         >Text</tp:dbus-ref>,
-            ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+            ...<tp:dbus-ref namespace="im.telepathy1.Channel"
             >TargetHandleType</tp:dbus-ref>: None,
             ...<tp:member-ref>RoomName</tp:member-ref>: "",
           },
@@ -248,18 +248,18 @@
 
       <blockquote>
         <pre>
-{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
-  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
-  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "qwerasdfzxcv@conference.jabber.org",
+{ ...<tp:dbus-ref namespace="im.telepathy1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>: Room,
+  ...<tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>: "qwerasdfzxcv@conference.jabber.org",
   ...<tp:member-ref>RoomName</tp:member-ref>: ""
 }</pre></blockquote>
 
       <p>If <tp:member-ref>RoomName</tp:member-ref> features in
         <var>Allowed_Properties</var> then the only value allowed in conjunction
-        with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
-        or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+        with <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
+        or <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
         is the empty string. Requests with conflicting
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>
         and <tp:member-ref>RoomName</tp:member-ref> properties
         will fail with InvalidArgument.</p>
 
@@ -269,7 +269,7 @@
 
       <blockquote>
         <pre>
-{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
+{ ...<tp:dbus-ref namespace="im.telepathy1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>,
   ...<tp:member-ref>RoomName</tp:member-ref>: ""
   ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
 }</pre>
@@ -280,9 +280,9 @@
 
       <blockquote>
         <pre>
-{ ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
-  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
-  ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "kajsdhkajshdfjkshdfjkhs@conference.jabber.org",
+{ ...<tp:dbus-ref namespace="im.telepathy1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>: Room,
+  ...<tp:dbus-ref namespace="im.telepathy1.Channel">TargetID</tp:dbus-ref>: "kajsdhkajshdfjkshdfjkhs@conference.jabber.org",
   ...<tp:member-ref>RoomName</tp:member-ref>: ""
   ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
 }</pre>
@@ -306,7 +306,7 @@
           persistent. This D-Bus property is <strong>not</strong> this
           XMPP room name, but the bit before the @ in the room jid; see
           <tp:dbus-ref
-          namespace='ofdT.Channel.Interface'>RoomConfig1.Title</tp:dbus-ref>
+          namespace='imt1.Channel.Interface'>RoomConfig1.Title</tp:dbus-ref>
           for that concept.</p>
 
         <p>This property cannot change during the lifetime of the channel. It
diff --git a/spec/Channel_Interface_Room_Config.xml b/spec/Channel_Interface_Room_Config1.xml
index 15ef0999..a2b25079 100644
--- a/spec/Channel_Interface_Room_Config.xml
+++ b/spec/Channel_Interface_Room_Config1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Room_Config"
+<node name="/Channel_Interface_Room_Config1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2011 Collabora Ltd.</tp:copyright>
@@ -20,11 +20,11 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.RoomConfig1">
+  <interface name="im.telepathy1.Channel.Interface.RoomConfig1">
     <tp:added version="0.24.0">version 1. This replaces the old-school
       Telepathy properties on <tp:dbus-ref
-      namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>.</tp:added>
-    <tp:requires interface='org.freedesktop.Telepathy.Channel.Interface.Room2'/>
+      namespace='imt1.Channel.Type'>Text</tp:dbus-ref>.</tp:added>
+    <tp:requires interface='im.telepathy1.Channel.Interface.Room1'/>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
                 value="true"/>
 
@@ -36,7 +36,7 @@
 
       <p>The “topic” (on IRC) or “subject” (on XMPP) is not part of this
         interface; it can be found on the <tp:dbus-ref
-        namespace='ofdT.Channel.Interface'>Subject2</tp:dbus-ref>
+        namespace='imt1.Channel.Interface'>Subject1</tp:dbus-ref>
         interface.</p>
     </tp:docstring>
 
@@ -64,7 +64,7 @@
     <property name="Title" tp:name-for-bindings="Title" type="s" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       A human-visible name for the channel, if it differs from <tp:dbus-ref
-      namespace='ofdT.Channel.Interface'>Room2.RoomName</tp:dbus-ref>; the
+      namespace='imt1.Channel.Interface'>Room1.RoomName</tp:dbus-ref>; the
       empty string, otherwise.
 
       <tp:rationale>
@@ -75,10 +75,10 @@
 
         <ul>
           <li><tp:dbus-ref
-            namespace='ofdT.Channel.Interface'>Room2.RoomName</tp:dbus-ref>
+            namespace='imt1.Channel.Interface'>Room1.RoomName</tp:dbus-ref>
             = <code>"jdev"</code>;</li>
           <li><tp:dbus-ref
-            namespace='ofdT.Channel.Interface'>Room2.Server</tp:dbus-ref>
+            namespace='imt1.Channel.Interface'>Room1.Server</tp:dbus-ref>
             = <code>"conference.jabber.org"</code>;</li>
           <li><tp:member-ref>Title</tp:member-ref> = <code>"General Jabber
             development discussion"</code>.</li>
@@ -111,7 +111,7 @@
         <code>True</code> if contacts joining this channel must provide a
         password to be granted entry.  Note that this property does not
         indicate that a password is required <em>right now</em>; see the
-        <tp:dbus-ref namespace='ofdT.Channel.Interface'>Password</tp:dbus-ref>
+        <tp:dbus-ref namespace='imt1.Channel.Interface'>Password1</tp:dbus-ref>
         interface for the API used to provide a password while joining a room.
       </tp:docstring>
     </property>
@@ -233,26 +233,26 @@
           method.</p>
       </tp:docstring>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
+      <tp:error name="im.telepathy1.Error.PermissionDenied">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           The user is not allowed to reconfigure this room.
         </tp:docstring>
       </tp:error>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+      <tp:error name="im.telepathy1.Error.InvalidArgument">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           One or more of the specified properties is unknown, or ill-typed.
         </tp:docstring>
       </tp:error>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+      <tp:error name="im.telepathy1.Error.NotImplemented">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           One or more of the specified properties cannot be modified on this
           protocol.
         </tp:docstring>
       </tp:error>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+      <tp:error name="im.telepathy1.Error.NotAvailable">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           The room's current configuration has not yet been retrieved, so we
           cannot update it just yet. The application might like to try again
diff --git a/spec/Channel_Interface_SASL_Authentication.xml b/spec/Channel_Interface_SASL_Authentication1.xml
index 7985a6bd..b58c90e5 100644
--- a/spec/Channel_Interface_SASL_Authentication.xml
+++ b/spec/Channel_Interface_SASL_Authentication1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_SASL_Authentication"
+<node name="/Channel_Interface_SASL_Authentication1"
       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">
@@ -17,20 +17,20 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication">
+  <interface name="im.telepathy1.Channel.Interface.SASLAuthentication1">
     <tp:added version="0.21.5">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.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>
+          namespace="imt1.Channel.Type">ServerAuthentication1</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
+        this interface does not REQUIRE <tp:dbus-ref namespace="imt1.Channel.Type"
+        >ServerAuthentication1</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
@@ -39,7 +39,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         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>
+          namespace="imt1">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
@@ -55,9 +55,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:rationale>
 
       <p>For channels managed by a
-        <tp:dbus-ref namespace="ofdT">ChannelDispatcher</tp:dbus-ref>,
+        <tp:dbus-ref namespace="imt1">ChannelDispatcher</tp:dbus-ref>,
         only the channel's <tp:dbus-ref
-          namespace="ofdT.Client">Handler</tp:dbus-ref> may call the
+          namespace="imt1.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>
 
@@ -189,11 +189,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <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>
+            namespace="imt1.Channel.Type">ServerAuthentication1</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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </property>
@@ -207,14 +207,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>.</p>
 
         <p>If this interface appears on a <tp:dbus-ref
-            namespace="ofdT.Channel.Type">ServerAuthentication</tp:dbus-ref>
+            namespace="imt1.Channel.Type">ServerAuthentication1</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>
+            namespace="imt1">Connection.ConnectionError</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </property>
@@ -225,7 +225,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <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>
+            namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>
           parameters, normalized and formatted according to the
           conventions used for SASL in this protocol.</p>
 
@@ -311,7 +311,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>For example, in the simple case, if the user connects with
         <tp:dbus-ref
-        namespace="ofdT.ConnectionManager">RequestConnection</tp:dbus-ref>({
+        namespace="imt1.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
@@ -324,7 +324,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <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>({
+            namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>({
           account: "<tt>announcements@example.com</tt>" }) and the SASL
           channel would look like this:</p>
 
@@ -407,7 +407,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The channel is not in a state where starting authentication makes
             sense (i.e. SASL_Status_Not_Started, or (if
@@ -418,8 +418,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             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:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The server or connection manager doesn't implement the given
             SASL mechanism. Choose a SASL mechanism from
@@ -481,7 +481,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The channel is not in a state where starting authentication makes
             sense (i.e. SASL_Status_Not_Started, or (if
@@ -492,8 +492,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             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:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The server or connection manager doesn't implement the given
             SASL mechanism (choose one from
@@ -519,13 +519,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.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:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -546,21 +546,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <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>
+            namespace="imt1.Channel.Type">ServerAuthentication1</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>
+            namespace="imt1">Connection.Status</tp:dbus-ref> to Connected.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.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:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -587,7 +587,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           reason code.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The current state is either Succeeded or Client_Accepted.
           </tp:docstring>
@@ -694,7 +694,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <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>
+            namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
           to close the channel.
         </tp:docstring>
       </tp:enumvalue>
@@ -706,7 +706,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <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>
+            namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
           on the channel.
         </tp:docstring>
       </tp:enumvalue>
diff --git a/spec/Channel_Interface_SMS.xml b/spec/Channel_Interface_SMS1.xml
index 497e9451..f785c8b9 100644
--- a/spec/Channel_Interface_SMS.xml
+++ b/spec/Channel_Interface_SMS1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_SMS"
+<node name="/Channel_Interface_SMS1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2008–2010 Nokia Corporation</tp:copyright>
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -20,8 +20,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.SMS">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
+    name="im.telepathy1.Channel.Interface.SMS1">
+    <tp:requires interface="im.telepathy1.Channel.Type.Text"/>
     <tp:added version='0.19.12'>Imported from
       rtcom-telepathy-glib, with the unused properties removed and the
       documentation tidied up.</tp:added>
@@ -34,7 +34,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         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
+        <tp:dbus-ref namespace="imt1.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
@@ -47,16 +47,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <p>A handler for class 0 SMSes should advertise the following filter:</p>
 
       <blockquote><code>
-{ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
-      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
-  ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+{ ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+      ...<tp:dbus-ref namespace='imt1.Channel.Type'>Text</tp:dbus-ref>,<br/>
+  ...<tp:dbus-ref namespace='imt1.Channel'>TargetHandleType</tp:dbus-ref>:
       <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
-  ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
+  ...<tp:dbus-ref namespace='imt1.Channel.Interface'>SMS1.Flash</tp:dbus-ref>:
       True,<br/>
 }</code></blockquote>
 
       <p>It should also set its <tp:dbus-ref
-        namespace='ofdT.Client.Handler'>BypassApproval</tp:dbus-ref> property
+        namespace='imt1.Client.Handler'>BypassApproval</tp:dbus-ref> property
         to <code>True</code>, so that it is invoked immediately for new
         channels.</p>
 
@@ -71,22 +71,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <blockquote><code>
 [<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>:
+ ({ ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+     ...<tp:dbus-ref namespace='imt1.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='imt1.Channel'>TargetHandleType</tp:dbus-ref>:
        <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
   },<br/>
-  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
-    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref> ]),<br/>
+  [ ...<tp:dbus-ref namespace='imt1.Channel'>TargetHandle</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace='imt1.Channel'>TargetID</tp:dbus-ref> ]),<br/>
 <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>:
+ ({ ...<tp:dbus-ref namespace='imt1.Channel'>ChannelType</tp:dbus-ref>:
+       ...<tp:dbus-ref namespace='imt1.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='imt1.Channel'>TargetHandleType</tp:dbus-ref>:
        <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
     ...<tp:member-ref>SMSChannel</tp:member-ref>: True,<br/>
   },<br/>
-  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
-    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref> ]),<br/>
+  [ ...<tp:dbus-ref namespace='imt1.Channel'>TargetHandle</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace='imt1.Channel'>TargetID</tp:dbus-ref> ]),<br/>
 ]
       </code></blockquote>
     </tp:docstring>
@@ -96,13 +96,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If <code>True</code>, then this channel is exclusively for
           receiving class 0 SMSes (and no SMSes can be sent using <tp:dbus-ref
-          namespace='ofdT.Channel.Interface.Messages'>SendMessage</tp:dbus-ref>
+          namespace='imt1.Channel.Type.Text'>SendMessage</tp:dbus-ref>
           on this channel). If <code>False</code>, no incoming class 0 SMSes
           will appear on this channel.</p>
 
         <p>This property is immutable (cannot change), and therefore SHOULD
           appear wherever immutable properties are reported, e.g. <tp:dbus-ref
-            namespace="ofdT.Connection.Interface.Requests"
+            namespace="imt1.Connection.Interface.Requests"
           >NewChannels</tp:dbus-ref> signals.</p>
 
         <tp:rationale>
@@ -114,9 +114,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
           <p>Separating class 0 SMSes into their own channel with this
             immutable property allows them to be dispatched to a different
-            <tp:dbus-ref namespace='ofdT.Client'>Handler</tp:dbus-ref>—which
+            <tp:dbus-ref namespace='imt1.Client'>Handler</tp:dbus-ref>—which
             would include this property in its <tp:dbus-ref
-            namespace='ofdT.Client.Handler'
+            namespace='imt1.Client.Handler'
             >HandlerChannelFilter</tp:dbus-ref>—avoiding the normal Text
             channel handler having to decide for each message whether it should
             be displayed to the user immediately or handled normally.</p>
@@ -260,7 +260,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The estimated cost of sending this message. The currency and
             scale of this value are the same as the
-            <tp:dbus-ref namespace="ofdT.Connection.Interface">Balance.AccountBalance</tp:dbus-ref>
+            <tp:dbus-ref namespace="imt1.Connection.Interface">Balance1.AccountBalance</tp:dbus-ref>
             property.</p>
 
           <p>A value of <code>-1</code> indicates the cost could not be
@@ -270,13 +270,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised when the method is not available on this channel.
             Clients MAY choose to make their own estimation.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             Raised when the content cannot be encoded into a valid SMS.
           </tp:docstring>
diff --git a/spec/Channel_Interface_Securable.xml b/spec/Channel_Interface_Securable1.xml
index d9d97139..6a139a36 100644
--- a/spec/Channel_Interface_Securable.xml
+++ b/spec/Channel_Interface_Securable1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Securable"
+<node name="/Channel_Interface_Securable1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2010 Collabora Ltd.</tp:copyright>
 
@@ -20,24 +20,24 @@
       USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Securable">
+  <interface name="im.telepathy1.Channel.Interface.Securable1">
     <tp:added version="0.21.5">as stable API</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.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
+        <tp:dbus-ref namespace="imt1">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>
+        namespace="imt1.Channel.Type">ServerAuthentication1</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>
+        namespace="imt1.Channel.Interface">SASLAuthentication1</tp:dbus-ref>
         channel.</p>
     </tp:docstring>
 
diff --git a/spec/Channel_Interface_Service_Point.xml b/spec/Channel_Interface_Service_Point1.xml
index 787397b2..c2d37e6e 100644
--- a/spec/Channel_Interface_Service_Point.xml
+++ b/spec/Channel_Interface_Service_Point1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Service_Point" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Service_Point1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,7 +17,7 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.ServicePoint">
+  <interface name="im.telepathy1.Channel.Interface.ServicePoint1">
     <tp:added version="0.19.7">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Channel_Interface_Splittable.xml b/spec/Channel_Interface_Splittable1.xml
index 760c1340..52976ed6 100644
--- a/spec/Channel_Interface_Splittable.xml
+++ b/spec/Channel_Interface_Splittable1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Splittable"
+<node name="/Channel_Interface_Splittable1"
   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>
@@ -20,15 +20,15 @@
       02110-1301, USA.</p>
   </tp:license>
   <interface
-    name="org.freedesktop.Telepathy.Channel.Interface.Splittable.DRAFT"
+    name="im.telepathy1.Channel.Interface.Splittable1"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for channels that can be made conceptually part of a
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference</tp:dbus-ref>, and can then be detached from that
+        <tp:dbus-ref namespace="im.telepathy1.Channel.Interface"
+          >Conference1</tp:dbus-ref>, and can then be detached from that
         conference.</p>
 
       <tp:rationale>
@@ -44,8 +44,8 @@
       tp:name-for-bindings="Split">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request that this channel is removed from any
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-          >Conference</tp:dbus-ref> of which it is a part.</p>
+        <tp:dbus-ref namespace="im.telepathy1.Channel.Interface"
+          >Conference1</tp:dbus-ref> of which it is a part.</p>
 
         <p>This implies that the media streams within the conference are put on
           hold and the media streams within the member channel leaving the
@@ -53,12 +53,12 @@
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             This channel isn't in a conference.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             This channel is in a conference but can't currently be split away
             from it.
diff --git a/spec/Channel_Interface_Subject.xml b/spec/Channel_Interface_Subject1.xml
index fcaf3983..a5fee4fd 100644
--- a/spec/Channel_Interface_Subject.xml
+++ b/spec/Channel_Interface_Subject1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Subject"
+<node name="/Channel_Interface_Subject1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010–2011 Collabora Ltd.</tp:copyright>
@@ -20,8 +20,8 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Subject2">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Interface.Subject1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.24.0">(version 2)</tp:added>
     <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
                 value="true"/>
@@ -30,7 +30,7 @@
       <p>An interface channels can implement to support subjects. Most
         of the time this will be implemented by channels implementing
         the <tp:dbus-ref
-        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        namespace="imt1.Channel.Interface">Room1</tp:dbus-ref>
         interface, but some protocols support subjects in 1-to-1 chats
         (such as XMPP). Note that this interface is not restricted to
         Text channels, and can also be used on Call channels.</p>
@@ -51,8 +51,8 @@
           further changes by other users or the server.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Channel_Interface_Transfer.xml b/spec/Channel_Interface_Transfer.xml
deleted file mode 100644
index 02591c1d..00000000
--- a/spec/Channel_Interface_Transfer.xml
+++ /dev/null
@@ -1,53 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Interface_Transfer" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Transfer"
-    tp:causes-havoc='not well-tested'>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <method name="Transfer">
-      <arg direction="in" name="Member" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The handle of the member to transfer
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Destination" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The handle of the destination contact
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that the given channel member instead connects to a different
-        contact ID.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
-    <tp:docstring>
-      An interface for channels where you may request that one of the members
-    connects to somewhere else instead.
-    </tp:docstring>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Tube.xml b/spec/Channel_Interface_Tube1.xml
index 72f77945..cacc2533 100644
--- a/spec/Channel_Interface_Tube.xml
+++ b/spec/Channel_Interface_Tube1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Interface_Tube" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Interface_Tube1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2008-2009 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
   <tp:license>
@@ -17,17 +17,17 @@ You should have received a copy of the GNU Lesser General Public
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Tube">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Interface.Tube1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A <i>tube</i> is a mechanism for arbitrary data transfer between
       two or more IM users, used to allow applications on the users'
       systems to communicate without having to establish network
       connections themselves. Currently, two types of tube exist:
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-      >Channel.Type.DBusTube</tp:dbus-ref> and
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-      >Channel.Type.StreamTube</tp:dbus-ref>. This interface contains
+      <tp:dbus-ref namespace="im.telepathy1"
+      >Channel.Type.DBusTube1</tp:dbus-ref> and
+      <tp:dbus-ref namespace="im.telepathy1"
+      >Channel.Type.StreamTube1</tp:dbus-ref>. This interface contains
       the properties, signals and methods common to both types of tube;
       you can only create channels of a specific tube type, not of this
       type. A tube channel contains exactly one tube; if you need several
@@ -36,27 +36,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <p>Tube channels can be requested for <tp:type>Handle_Type</tp:type>
         Contact (for 1-1 communication) or Room (to communicate with others in
         the room simultaneously).</p>
-
-      <p>As an exception to the usual handling of capabilities, connection managers
-        for protocols with capability discovery (such as XMPP) SHOULD advertise the
-        capability representing each Tube type that they support
-       (<tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.DBusTube</tp:dbus-ref> and/or
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.StreamTube</tp:dbus-ref>)
-        even if no client has indicated via
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>
-        that such a tube is supported. They SHOULD also allow clients to offer tubes with any
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.StreamTube">Service</tp:dbus-ref> or
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.DBusTube">ServiceName</tp:dbus-ref>
-        to any contact which supports the corresponding tube capability.</p>
-
-      <tp:rationale>
-        <p>This lowers the barrier to entry for those writing new tube
-          applications, and preserves interoperability with older versions of
-          the Telepathy stack which did not support rich capabilities.</p>
-      </tp:rationale>
     </tp:docstring>
 
     <property name="Parameters" type="a{sv}" tp:type="String_Variant_Map"
@@ -77,7 +56,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           participants.</p>
 
         <p>For example, a stream tube for <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type.StreamTube">Service</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type.StreamTube1">Service</tp:dbus-ref>
           <tt>"smb"</tt> (<cite>Server Message Block over TCP/IP</cite>) might
           use the following properties, as defined in <a
           href="http://www.dns-sd.org/ServiceTypes.html">DNS SRV (RFC 2782)
@@ -91,18 +70,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <p>When requesting a tube with
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
+            namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
           this property MUST NOT be included in the request; instead, it is set
           when <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">StreamTube.Offer</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">StreamTube1.Offer</tp:dbus-ref>
           or <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">DBusTube.Offer</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">DBusTube1.Offer</tp:dbus-ref>
           (as appropriate) is called. Its value is undefined until the tube is
           offered; once set, its value MUST NOT change.</p>
 
         <p>When receiving an incoming tube, this property is immutable and so advertised in the
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </property>
@@ -114,7 +93,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <p>When requesting a tube with
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
+            namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
           this property MUST NOT be included in the request.</p>
       </tp:docstring>
     </property>
@@ -203,6 +182,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <tp:enum name="Socket_Access_Control" type="u"
       array-name="Socket_Access_Control_List">
+      <tp:changed version="0.99.1">The deprecated Netmask enum
+        value has been removed.</tp:changed>
       <tp:enumvalue suffix="Localhost" value="0">
         <tp:docstring>
           <p>The IP or Unix socket can be accessed by any local user (e.g.
@@ -230,28 +211,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           connections will be rejected.
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Netmask" value="2">
-        <tp:deprecated version="0.17.25">This has never been implemented.
-        If you want to share a service to your whole LAN, Telepathy is
-        not the way to do it.</tp:deprecated>
-        <tp:docstring>
-          May only be used on IP sockets. The associated variant must contain
-          a struct Socket_Netmask_IPv4 (or Socket_Netmask_IPv6) with
-          signature (sy), containing the string form of an
-          IP address of the appropriate version, and a prefix length "n".
-          The socket can only be accessed if the first n bits of the
-          connecting address match the first n bits of the given address.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Credentials" value="3">
+      <tp:enumvalue suffix="Credentials" value="2">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The high-level meaning of this access control type is that
             only the same user (e.g. same numeric Unix uid) is allowed to
             interact with the tube. Exactly how this is achieved varies by
             channel type.</p>
 
-          <p>For <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
-              >StreamTube</tp:dbus-ref> channels, this access control type
+          <p>For <tp:dbus-ref namespace="im.telepathy1.Channel.Type"
+              >StreamTube1</tp:dbus-ref> channels, this access control type
             may only be used on UNIX sockets.
             The connecting process must send a byte when
             it first connects, which is not considered to be part of the data
@@ -263,8 +231,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             in D-Bus the byte is always zero, whereas in Tubes it can be
             nonzero.)</p>
 
-          <p>For <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
-              >DBusTube</tp:dbus-ref> channels, this access control type
+          <p>For <tp:dbus-ref namespace="im.telepathy1.Channel.Type"
+              >DBusTube1</tp:dbus-ref> channels, this access control type
             may be used on any type of socket, and there is no extra byte
             added by Telepathy at the beginning of the stream: all bytes in
             the stream are part of the D-Bus tube connection. The connecting
diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml
index dd10049e..49a3e7bd 100644
--- a/spec/Channel_Request.xml
+++ b/spec/Channel_Request.xml
@@ -21,44 +21,45 @@
       MA 02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.ChannelRequest">
+  <interface name="im.telepathy1.ChannelRequest">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel request is an object in the <tp:dbus-ref
-        namespace='ofdT'>ChannelDispatcher</tp:dbus-ref> representing
+        namespace='imt1'>ChannelDispatcher</tp:dbus-ref> representing
         an ongoing request for some channels to be created or found. They are
         created by methods such as <tp:dbus-ref
-        namespace='ofdT.ChannelDispatcher'>CreateChannel</tp:dbus-ref>. There
+        namespace='imt1.ChannelDispatcher'>CreateChannel</tp:dbus-ref>. There
         can be any number of ChannelRequest objects at the same time.</p>
 
       <p>Its well-known bus name is the same as that of the ChannelDispatcher,
-        <code>"org.freedesktop.Telepathy.ChannelDispatcher"</code>.</p>
+        <code>"im.telepathy1.ChannelDispatcher"</code>.</p>
 
       <tp:rationale>
         <p>See
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatcher.CreateChannel</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">ChannelDispatcher.CreateChannel</tp:dbus-ref>
           for rationale for ChannelRequest being a separate object.</p>
       </tp:rationale>
 
       <p>A channel request can be cancelled by any client (not just the one
         that requested it). This means that the ChannelDispatcher will
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
         the resulting channel, or refrain from requesting it at all, rather
         than dispatching it to a handler.</p>
     </tp:docstring>
 
     <property name="Account" tp:name-for-bindings="Account"
-      type="o" access="read">
+      type="o" access="read" tp:immutable="yes">
       <tp:docstring>
         The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          namespace="im.telepathy1">Account</tp:dbus-ref>
         on which this request was made. This property cannot change.
       </tp:docstring>
     </property>
 
     <property name="UserActionTime" tp:name-for-bindings="User_Action_Time"
-      type="x" tp:type="User_Action_Timestamp" access="read">
+      type="x" tp:type="User_Action_Timestamp" access="read"
+      tp:immutable="yes">
       <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>
@@ -69,10 +70,10 @@
     </property>
 
     <property name="PreferredHandler" tp:name-for-bindings="Preferred_Handler"
-      type="s" tp:type="DBus_Well_Known_Name" access="read">
+      type="s" tp:type="DBus_Well_Known_Name" access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>Either the well-known bus name (starting with
-            <code>org.freedesktop.Telepathy.Client.</code>)
+            <code>im.telepathy1.Client.</code>)
             of the preferred handler for this
             channel, or an empty string to indicate that any handler would be
             acceptable.</p>
@@ -84,7 +85,7 @@
 
     <property name="Requests" tp:name-for-bindings="Requests" type="aa{sv}"
       tp:type="Qualified_Property_Value_Map[]"
-      access="read">
+      access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>An array of dictionaries containing desirable properties for
           the channel or channels to be created.</p>
@@ -100,7 +101,7 @@
     </property>
 
     <property name="Interfaces" tp:name-for-bindings="Interfaces"
-      type="as" access="read" tp:type="DBus_Interface[]">
+      type="as" access="read" tp:type="DBus_Interface[]" tp:immutable="yes">
       <tp:docstring>
         A list of the extra interfaces provided by this channel request.
         This property cannot change.
@@ -133,7 +134,7 @@
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             This method has already been called, so it is no longer
             available. Stop calling it.
@@ -153,7 +154,7 @@
 
         <p>If the connection manager has already been asked to create a
           channel but has not produced one yet (e.g. if <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+            namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
           has been called, but has not yet returned), then the
           ChannelDispatcher will remember that the request has been cancelled.
           When the channel appears, it will be closed (if it was newly
@@ -165,14 +166,14 @@
           then the channel dispatcher will not dispatch that
           channel to a handler. If the channel was newly created for this
           request, the channel dispatcher will close it with <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>;
+          namespace="im.telepathy1.Channel">Close</tp:dbus-ref>;
           otherwise, the channel dispatcher will ignore it. In either case,
           <tp:member-ref>Failed</tp:member-ref> will be emitted when processing
           has been completed.</p>
 
         <p>If <tp:member-ref>Failed</tp:member-ref> is emitted in response to
           this method, the error SHOULD be
-          <code>org.freedesktop.Telepathy.Error.Cancelled</code>.</p>
+          <code>im.telepathy1.Error.Cancelled</code>.</p>
 
         <p>If the channel has already been dispatched to a handler, then
           it's too late to call this method, and the channel request will
@@ -190,10 +191,10 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The name of a D-Bus error. This can come from various sources,
             including the error raised by <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
+              namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
             or an error generated
             to represent failure to establish the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.</p>
+              namespace="im.telepathy1">Connection</tp:dbus-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -205,15 +206,8 @@
       </arg>
     </signal>
 
-    <signal name="Succeeded" tp:name-for-bindings="Succeeded">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The channel request has succeeded. It is no longer present,
-          and further methods must not be called on it.</p>
-      </tp:docstring>
-    </signal>
-
     <property name="Hints" tp:name-for-bindings="Hints"
-      type="a{sv}" access="read">
+      type="a{sv}" access="read" tp:immutable="yes">
       <tp:added version="0.21.5"/>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A dictionary of metadata provided by the channel
@@ -239,24 +233,24 @@
           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
+          name (e.g. <code>im.telepathy1</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>
+          namespace="imt1.Client.Interface.Requests">AddRequest</tp:dbus-ref>
           by the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>.</p>
+          namespace="im.telepathy1">ChannelDispatcher</tp:dbus-ref>.</p>
         <p>The following standardised hints are defined:</p>
 
         <dl>
-          <dt>org.freedesktop.Telepathy.ChannelRequest.DelegateToPreferredHandler - b</dt>
+          <dt>im.telepathy1.ChannelRequest.DelegateToPreferredHandler - b</dt>
           <dd>If present and True the client currently handling the channel
             SHOULD pass the channel to the
             <tp:member-ref>PreferredHandler</tp:member-ref> using
-            <tp:dbus-ref namespace="ofdT.ChannelDispatcher">DelegateChannels</tp:dbus-ref>.
+            <tp:dbus-ref namespace="imt1.ChannelDispatcher">DelegateChannels</tp:dbus-ref>.
 
             <tp:rationale>
               This hint allows the user to request a channel in their
@@ -276,15 +270,15 @@
             </tp:rationale>
 
             The Handler should check each
-            <tp:dbus-ref namespace="ofdT">ChannelRequest</tp:dbus-ref>
+            <tp:dbus-ref namespace="imt1">ChannelRequest</tp:dbus-ref>
             of the Requests_Satisfied parameter of
-            <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+            <tp:dbus-ref namespace="imt1.Client.Handler">HandleChannels</tp:dbus-ref>
             for the hint. The first request containing the hint SHOULD be used
             and all further hints SHOULD be ignored.
 
             <tp:rationale>
               This covers the very unlikely case where
-              <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+              <tp:dbus-ref namespace="imt1.Client.Handler">HandleChannels</tp:dbus-ref>
               satisfies two separate requests which have different
               <tp:member-ref>PreferredHandler</tp:member-ref>s.
             </tp:rationale>
@@ -294,18 +288,13 @@
       </tp:docstring>
     </property>
 
-    <signal name="SucceededWithChannel" tp:name-for-bindings="Succeeded_With_Channel">
+    <signal name="Succeeded" tp:name-for-bindings="Succeeded">
       <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
+        <p>The channel request has succeeded. It is no longer present,
+          and further methods must not be called on it.</p>
+
+        <p>This signal MUST be emitted before
           the <tp:member-ref>Succeeded</tp:member-ref> signal.</p>
       </tp:docstring>
 
@@ -333,7 +322,7 @@
         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"
+            in a <tp:dbus-ref namespace="imt1.Connection.Interface.Requests"
               >NewChannels</tp:dbus-ref> signal.</p>
         </tp:docstring>
       </arg>
diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call1.xml
index eee38a95..5073d1fc 100644
--- a/spec/Channel_Type_Call.xml
+++ b/spec/Channel_Type_Call1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Call" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_Call1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2010 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
   <tp:license>
@@ -17,18 +17,17 @@ You should have received a copy of the GNU Lesser General Public
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.Call1">
+  <interface name="im.telepathy1.Channel.Type.Call1">
     <tp:added version="0.25.2">(as stable API)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:requires
-      interface="org.freedesktop.Telepathy.Call1.Interface.Mute"/>
+      interface="im.telepathy1.Call1.Interface.Mute"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <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>A channel type for making audio and video calls. Call channels
+        supersede the old StreamedMedia 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
@@ -41,8 +40,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         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>
+        namespace="imt1.Channel">TargetHandle</tp:dbus-ref> and
+        <tp:dbus-ref namespace="imt1.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
@@ -53,7 +52,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <h4>Contents</h4>
 
-      <p><tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>
+      <p><tp:dbus-ref namespace="imt1.Call1">Content</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
@@ -63,10 +62,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         as the Requestable Channel Classes will document.</p>
 
       <p><tp:dbus-ref
-        namespace="ofdT.Call1">Content</tp:dbus-ref> objects have
+        namespace="imt1.Call1">Content</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.Call1">Content</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Call1">Content</tp:dbus-ref>
         interface page.</p>
 
       <h4>Outgoing calls</h4>
@@ -76,27 +75,27 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <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">Call1</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="imt1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+  ...<tp:dbus-ref namespace="imt1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="imt1.Channel.Type">Call1</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+  ...<tp:dbus-ref namespace="imt1.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
+        namespace="imt1.Channel">TargetHandle</tp:dbus-ref> may be used
         in place of
-        <tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.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
+        namespace="imt1.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> =
+        namespace="imt1.Channel">TargetHandle</tp:dbus-ref>,
+        <tp:dbus-ref namespace="imt1.Channel">Requested</tp:dbus-ref> =
         <code>True</code> (indicating the call is outgoing).</p>
 
       <p>After a new Call channel is requested, the
@@ -150,26 +149,26 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:member-ref>CallStateReason</tp:member-ref> property
         changing to (remote contact,
         <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
-        "org.freedesktop.Telepathy.Error.Rejected").</p>
+        "im.telepathy1.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>
+        namespace="imt1.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="imt1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>([
+  /im/telepathy1/Connection/foo/bar/foo_40bar_2ecom/CallChannel,
   {
-    ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
-      namespace="ofdT.Channel.Type">Call1</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:dbus-ref namespace="imt1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="imt1.Channel.Type">Call1</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+    ...<tp:dbus-ref namespace="imt1.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
+    ...<tp:dbus-ref namespace="imt1.Channel">TargetHandle</tp:dbus-ref>: 42,
+    ...<tp:dbus-ref namespace="imt1.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",
@@ -192,7 +191,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         The new channel should also be given to telepathy-farstream to
         work out how the two participants will connect together.
         telepathy-farstream will call the appropriate methods on the call's
-        <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>s
+        <tp:dbus-ref namespace="imt1.Call1">Content</tp:dbus-ref>s
         to negotiate codecs and transports.</p>
 
       <p>To pick up the call, the handler should call
@@ -212,7 +211,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:member-ref>CallStateReason</tp:member-ref> property will
         change to (self handle,
         <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
-        "org.freedesktop.Telepathy.Error.Rejected").</p>
+        "im.telepathy1.Error.Rejected").</p>
 
       <h4>Ongoing calls</h4>
 
@@ -240,9 +239,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <p>A similar method is used for removing contents from a call,
         except that the <tp:dbus-ref
-        namespace="ofdT.Call1.Content">Remove</tp:dbus-ref> method
+        namespace="imt1.Call1.Content">Remove</tp:dbus-ref> method
         is on the <tp:dbus-ref
-        namespace="ofdT.Call1">Content</tp:dbus-ref> object.</p>
+        namespace="imt1.Call1">Content</tp:dbus-ref> object.</p>
 
       <h5>Ending the call</h5>
 
@@ -253,7 +252,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:member-ref>CallStateReason</tp:member-ref> will change
         to (self handle,
         <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
-        "org.freedesktop.Telepathy.Error.Cancelled").</p>
+        "im.telepathy1.Error.Cancelled").</p>
 
       <p>If the other participant hangs up first then the
         <tp:member-ref>CallState</tp:member-ref> property will change to
@@ -261,22 +260,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:member-ref>CallStateReason</tp:member-ref> will change
         to (remote contact,
         <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
-        "org.freedesktop.Telepathy.Error.Terminated").</p>
+        "im.telepathy1.Error.Terminated").</p>
 
       <h4>Multi-party calls</h4>
 
       <h4>Requestable channel classes</h4>
 
       <p>The <tp:dbus-ref
-        namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+        namespace="imt1.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
         for <tp:dbus-ref
-        namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channels
+        namespace="imt1.Channel.Type">Call1</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">Call1</tp:dbus-ref>,
-            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+[( Fixed = { ...<tp:dbus-ref namespace="imt1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="imt1.Channel.Type">Call1</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>: Contact,
             ...<tp:member-ref>InitialVideo</tp:member-ref>: True
           },
   Allowed = [ ...<tp:member-ref>InitialVideoName</tp:member-ref>,
@@ -284,8 +283,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
               ...<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">Call1</tp:dbus-ref>,
-            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+( Fixed = { ...<tp:dbus-ref namespace="imt1.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="imt1.Channel.Type">Call1</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>: Contact,
             ...<tp:member-ref>InitialAudio</tp:member-ref>: True
           },
   Allowed = [ ...<tp:member-ref>InitialAudioName</tp:member-ref>,
@@ -301,14 +300,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         class, and vice versa for CMs without audio support.</p>
 
       <p>Handlers should not close <tp:dbus-ref
-        namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channels
+        namespace="imt1.Channel.Type">Call1</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
+        namespace="imt1">ChannelDispatcher</tp:dbus-ref> will call
+        <tp:dbus-ref namespace="imt1.Channel">Close</tp:dbus-ref> on the
         channel which SHOULD also imply a call to
         <tp:member-ref>Hangup</tp:member-ref>(<tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
-        "org.freedesktop.Telepathy.Error.Terminated", "") before
+        "im.telepathy1.Error.Terminated", "") before
         actually closing the channel.</p>
 
     </tp:docstring>
@@ -320,7 +319,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           call.</p>
 
         <p>This method is only useful if the
-          channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
+          channel's <tp:dbus-ref namespace="imt1.Channel">Requested</tp:dbus-ref>
           property is False, and
           the <tp:member-ref>CallState</tp:member-ref> is
           <tp:value-ref type="Call_State">Initialised</tp:value-ref> (an incoming
@@ -336,13 +335,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
-            The call was <tp:dbus-ref namespace="ofdT.Channel"
+            The call was <tp:dbus-ref namespace="imt1.Channel"
             >Requested</tp:dbus-ref>, so ringing does not make sense.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The call is no longer in state
             <tp:value-ref type="Call_State">Initialised</tp:value-ref>.
@@ -358,7 +357,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           call has been put in a call-waiting style queue.</p>
 
         <p>This method is only useful if the
-          channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
+          channel's <tp:dbus-ref namespace="imt1.Channel">Requested</tp:dbus-ref>
           property is False, and
           the <tp:member-ref>CallState</tp:member-ref> is
           <tp:value-ref type="Call_State">Initialising</tp:value-ref> or
@@ -376,13 +375,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
-            The call was <tp:dbus-ref namespace="ofdT.Channel"
+            The call was <tp:dbus-ref namespace="imt1.Channel"
             >Requested</tp:dbus-ref>, so queueing does not make sense.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The call is no longer in state
             <tp:value-ref type="Call_State">Initialising</tp:value-ref> or
@@ -411,20 +410,20 @@ 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="ofdT.Call1" >Content</tp:dbus-ref> whose
-          <tp:dbus-ref namespace="ofdT.Call1.Content"
+          namespace="imt1.Call1" >Content</tp:dbus-ref> whose
+          <tp:dbus-ref namespace="imt1.Call1.Content"
           >Disposition</tp:dbus-ref> is
           <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref>, any
           streams where the <tp:dbus-ref
-          namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
+          namespace="imt1.Call1.Stream">LocalSendingState</tp:dbus-ref>
           is <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
           moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
-          <tp:dbus-ref namespace="ofdT.Call1.Stream"
+          <tp:dbus-ref namespace="imt1.Call1.Stream"
           >SetSending</tp:dbus-ref>(True) had been called.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The call is not in one of the states where this method makes sense.
           </tp:docstring>
@@ -467,7 +466,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The call has already been ended.
           </tp:docstring>
@@ -478,7 +477,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <method name="AddContent" tp:name-for-bindings="Add_Content">
       <tp:docstring>
         Request that a new <tp:dbus-ref
-        namespace="ofdT.Call1">Content</tp:dbus-ref> of type
+        namespace="imt1.Call1">Content</tp:dbus-ref> of type
         Content_Type is added to the Call1. 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
@@ -521,30 +520,30 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <arg direction="out" name="Content" type="o">
         <tp:docstring>
           Path to the newly-created <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy"
+            namespace="im.telepathy1"
             >Call1.Content</tp:dbus-ref> object.
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The media stream type given is invalid.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The media stream type requested is not implemented by the
             CM.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Media.UnsupportedType">
+        <tp:error name="im.telepathy1.Error.Media.UnsupportedType">
           <tp:docstring>
             The media stream type requested is not supported by either the
             local or remote side.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
+        <tp:error name="im.telepathy1.Error.NotCapable">
           <tp:docstring>
             The content type requested cannot be added to this
             call. Examples of why this might be the case include
@@ -559,12 +558,12 @@ 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="ofdT.Call1"
+        <p>Emitted when a new <tp:dbus-ref namespace="imt1.Call1"
           >Content</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="ofdT.Call1"
+          Path to the newly-created <tp:dbus-ref namespace="imt1.Call1"
           >Content</tp:dbus-ref> object.
         </tp:docstring>
       </arg>
@@ -572,12 +571,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <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="ofdT.Call1"
+        <p>Emitted when a <tp:dbus-ref namespace="imt1.Call1"
           >Content</tp:dbus-ref> is removed from the call.</p>
       </tp:docstring>
       <arg name="Content" type="o">
         <tp:docstring>
-          The <tp:dbus-ref namespace="ofdT.Call1"
+          The <tp:dbus-ref namespace="imt1.Call1"
           >Content</tp:dbus-ref> which was removed.
         </tp:docstring>
       </arg>
@@ -592,7 +591,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       tp:name-for-bindings="Contents">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The list of <tp:dbus-ref
-          namespace="ofdT.Call1">Content</tp:dbus-ref> objects that
+          namespace="imt1.Call1">Content</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.
@@ -600,6 +599,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
+    <tp:enum name="Media_Stream_Type" type="u"
+      array-name="Media_Stream_Type_List">
+      <tp:enumvalue suffix="Audio" value="0">
+        <tp:docstring>An audio stream</tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Video" value="1">
+        <tp:docstring>A video stream</tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
     <tp:enum type="u" name="Call_State">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The state of a call, as a whole.</p>
@@ -716,8 +725,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:flag suffix="Locally_Held" value="1">
         <tp:docstring>
           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
+          the <tp:dbus-ref namespace="imt1.Channel.Interface"
+          >Hold1</tp:dbus-ref> interface. This flag SHOULD only be set
           if there is at least one Content, and all Contents are
           locally held.
 
@@ -729,7 +738,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             hear them!
 
             This flag exists as a simplified proxy for <tp:dbus-ref
-            namespace="ofdT.Channel.Interface.Hold"
+            namespace="imt1.Channel.Interface.Hold1"
               >HoldStateChanged</tp:dbus-ref>,
             to reduce the number of signals that need to be
             listened to by a simple UI.
@@ -829,7 +838,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             there is <tp:error-ref>InsufficientBalance</tp:error-ref>,
             indicating what the required balance would be to place this call.
             The value of this key has the same units and scale as
-            <tp:dbus-ref namespace="ofdT.Connection.Interface.Balance">AccountBalance</tp:dbus-ref>.
+            <tp:dbus-ref namespace="imt1.Connection.Interface.Balance1">AccountBalance</tp:dbus-ref>.
             </dd>
 
           <dt>forwarded-to - u</dt>
@@ -1157,7 +1166,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <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="ofdT.Call1.Content.Interface"
+          will have the <tp:dbus-ref namespace="imt1.Call1.Content.Interface"
           >Media</tp:dbus-ref> interface, to communicate the necessary
           information to a streaming implementation. Connection managers SHOULD
           operate like this, if possible.</p>
@@ -1282,8 +1291,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <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
+          <tp:dbus-ref namespace="imt1.Channel.Interface"
+          >Group1</tp:dbus-ref> and the Group members are
           channel-specific handles, then this call SHOULD also use
           channel-specific handles.</p>
 
@@ -1327,7 +1336,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           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="ofdT.Channel.Type.Call1">AddContent</tp:dbus-ref>.</p>
+          namespace="imt1.Channel.Type.Call1">AddContent</tp:dbus-ref>.</p>
 
         <p>If this property, or InitialVideo, is passed to EnsureChannel
           (as opposed to CreateChannel), the connection manager SHOULD ignore
@@ -1342,14 +1351,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <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="ofdT.Channel.Type.Call1"
+          <tp:dbus-ref namespace="imt1.Channel.Type.Call1"
           >Contents</tp:dbus-ref>).</p>
 
         <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="ofdT.Connection.Interface">ContactCapabilities</tp:dbus-ref>
+          namespace="imt1.Connection.Interface">ContactCapabilities1</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
@@ -1367,12 +1376,12 @@ 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="ofdT.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>
+          namespace="imt1.Connection.Interface.ContactCapabilities1">UpdateCapabilities</tp:dbus-ref>
           (clients of a <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
+          namespace="im.telepathy1">ChannelDispatcher</tp:dbus-ref>
           SHOULD instead arrange for the ChannelDispatcher to do this,
           by including the filters in their <tp:dbus-ref
-          namespace="ofdT.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+          namespace="imt1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
           properties):</p>
 
         <ul>
@@ -1485,7 +1494,7 @@ 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="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          namespace="imt1.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
           property is <tp:value-ref type="Stream_Transport_Type">GTalk_P2P</tp:value-ref>.</p>
       </tp:docstring>
     </tp:hct>
@@ -1493,7 +1502,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          namespace="imt1.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
           property is <tp:value-ref type="Stream_Transport_Type">ICE</tp:value-ref>.</p>
       </tp:docstring>
     </tp:hct>
@@ -1501,7 +1510,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          namespace="imt1.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
           property is <tp:value-ref type="Stream_Transport_Type">WLM_2009</tp:value-ref>.</p>
       </tp:docstring>
     </tp:hct>
@@ -1509,7 +1518,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          namespace="imt1.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
           property is <tp:value-ref type="Stream_Transport_Type">SHM</tp:value-ref>.</p>
       </tp:docstring>
     </tp:hct>
@@ -1541,15 +1550,15 @@ 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="ofdT.Client.Handler">Capabilities</tp:dbus-ref>
+          namespace="imt1.Client.Handler">Capabilities</tp:dbus-ref>
           property:</p>
 
         <ul>
-          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio</code></li>
-          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio/speex</code></li>
-          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video</code></li>
-          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/theora</code></li>
-          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/h264</code></li>
+          <li><code>im.telepathy1.Channel.Type.Call1/audio</code></li>
+          <li><code>im.telepathy1.Channel.Type.Call1/audio/speex</code></li>
+          <li><code>im.telepathy1.Channel.Type.Call1/video</code></li>
+          <li><code>im.telepathy1.Channel.Type.Call1/video/theora</code></li>
+          <li><code>im.telepathy1.Channel.Type.Call1/video/h264</code></li>
         </ul>
 
         <p>Clients MAY have media signalling abilities without explicitly
diff --git a/spec/Channel_Type_Contact_List.xml b/spec/Channel_Type_Contact_List.xml
deleted file mode 100644
index 348d0bd4..00000000
--- a/spec/Channel_Type_Contact_List.xml
+++ /dev/null
@@ -1,107 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Type_Contact_List" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.ContactList">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
-    <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
-      </tp:deprecated>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A channel type for representing a list of people on the server which is
-    not used for communication. This is intended for use with the interface
-    <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy">Channel.Interface.Group</tp:dbus-ref>
-    for managing buddy lists and privacy lists
-    on the server. This channel type has no methods because all of the
-    functionality it represents is available via the group interface.</p>
-
-    <p>There are currently two types of contact list:
-    HANDLE_TYPE_LIST is a &quot;magic&quot; server-defined list, and
-    HANDLE_TYPE_GROUP is a user-defined contact group.</p>
-
-    <p>For server-defined lists like the subscribe list, singleton instances
-    of this channel type should be created by the connection manager at
-    connection time if the list exists on the server, or may be requested
-    by using the appropriate handle.  These handles can be obtained using
-    <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection">RequestHandles</tp:dbus-ref>
-    with a <tp:type>Handle_Type</tp:type> of HANDLE_TYPE_LIST and one of the
-    following identifiers:</p>
-
-    <ul>
-      <li>subscribe - the group of contacts for whom you receive presence</li>
-      <li>publish - the group of contacts who may receive your presence</li>
-      <li>hide - a group of contacts who are on the publish list but are temporarily disallowed from receiving your presence</li>
-      <li>allow - a group of contacts who may send you messages</li>
-      <li>deny - a group of contacts who may not send you messages</li>
-      <li>stored - on protocols where the user's contacts are stored, this
-      contact list contains all stored contacts regardless of subscription
-      status.</li>
-    </ul>
-
-    <p>A contact can be in several server-defined lists. All lists are optional
-    to implement. If <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection">RequestHandles</tp:dbus-ref>
-    or <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection">RequestChannel</tp:dbus-ref>
-    for a particular contact list raises an error, this indicates that the
-    connection manager makes no particular statement about the list's contents;
-    clients MUST NOT consider this to be fatal.</p>
-
-    <p>If a client wants to list all of a user's contacts, it is appropriate to
-    use the union of the subscribe, publish and stored lists, including the
-    local and remote pending members.</p>
-
-    <p>For example in XMPP, contacts who have the subscription type "none",
-    "from", "to" and "both" can be respectively in the lists:</p>
-
-    <ul>
-      <li>"none": stored</li>
-      <li>"from": stored and publish</li>
-      <li>"to": stored and subscribe</li>
-      <li>"both": stored, publish and subscribe</li>
-    </ul>
-
-    <p>These contact list channels may not be closed.</p>
-
-    <p>For user-defined contact groups, instances of this channel type should
-    be created by the connection manager at connection time for each group
-    that exists on the server. New, empty groups can be created by calling
-    <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection">RequestHandles</tp:dbus-ref>
-    with a <tp:type>Handle_Type</tp:type> of HANDLE_TYPE_GROUP and with the
-    name set to the human-readable UTF-8 name of the group.</p>
-
-    <p>User-defined groups may be deleted by calling <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> on the
-    channel, but only if
-    the group is already empty. Closing a channel to a non-empty group is
-    not allowed; its members must be set to the empty set first.</p>
-
-    <p>On some protocols (e.g. XMPP) empty groups are not represented on the
-    server, so disconnecting from the server and reconnecting might cause
-    empty groups to vanish.</p>
-    </tp:docstring>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Contact_Search.xml b/spec/Channel_Type_Contact_Search1.xml
index 98789ab4..8503cddd 100644
--- a/spec/Channel_Type_Contact_Search.xml
+++ b/spec/Channel_Type_Contact_Search1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Contact_Search" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_Contact_Search1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2006 INdT </tp:copyright>
@@ -18,14 +18,17 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.ContactSearch">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Type.ContactSearch1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.19.10">
       as stable API. Changes from draft 2:
       <tp:type>Contact_Search_Result_Map</tp:type> keys are now identifiers
       rather than handles; consequently, the values need not include
       <tt>x-telepathy-identifier</tt>.
     </tp:added>
+    <tp:changed version="0.99.1">
+      The requestable channel class now fixes TargetHandleType=NONE.
+    </tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel type for searching server-stored user directories. A new
@@ -34,31 +37,26 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         found.</p>
 
       <p>Connections that support contact search channels SHOULD have an entry
-        in <tp:dbus-ref namespace='ofdT.Connection.Interface.Requests'
+        in <tp:dbus-ref namespace='imt1.Connection.Interface.Requests'
           >RequestableChannelClasses</tp:dbus-ref> with the <tp:dbus-ref
-          namespace='ofdT.Channel'>ChannelType</tp:dbus-ref> fixed to this
-        interface, and no other fixed properties. That requestable
+          namespace='imt1.Channel'>ChannelType</tp:dbus-ref> fixed to this
+        interface,
+        <tp:dbus-ref namespace='imt1.Channel'>TargetHandleType</tp:dbus-ref>
+        fixed to Handle_Type_None, and no other fixed properties. That requestable
         channel class MAY also have the Server and Limit properties in its
         list of allowed properties, depending on the protocol.</p>
 
-      <tp:rationale>
-        <p>The requestable channel class would normally also have <tp:dbus-ref
-            namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref> fixed to
-          <code>None</code>, but the initial implementation of ContactSearch
-          (in telepathy-gabble) didn't do this.</p>
-      </tp:rationale>
-
       <p>All channels of this type should have <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
+        namespace='imt1.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>
+        namespace='imt1.Channel'>TargetHandle</tp:dbus-ref> <code>0</code> and
+        <tp:dbus-ref namespace='imt1.Channel'>TargetID</tp:dbus-ref>
         <code>""</code>).</p>
 
       <p>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>
+        namespace='imt1.Connection.Interface.Requests'>RequestableChannelClasses</tp:dbus-ref>).</p>
 
       <p>Before searching, the
         <tp:member-ref>AvailableSearchKeys</tp:member-ref> property should be
@@ -83,11 +81,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:member-ref>Limit</tp:member-ref> results. If allowed by the
         connection manager, clients may specify the "page size" by specifying
         <tp:member-ref>Limit</tp:member-ref> when calling
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+        <tp:dbus-ref namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
         </p>
 
       <p>The client should call the channel's <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
+        namespace="im.telepathy1.Channel">Close</tp:dbus-ref>
         method when it is finished with the channel.</p>
 
       <p>Each channel can only be used for a single search; a new channel
@@ -96,10 +94,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         to the same server, if applicable).</p>
 
       <p>It does not make sense to request this channel type using <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>;
+          namespace="im.telepathy1.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>;
         clients SHOULD request channels of this type using
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>
+          namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>
         instead.</p>
 
       <tp:rationale>
@@ -298,7 +296,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <tp:rationale>
           It can be in the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
           signal for round-trip reduction.
         </tp:rationale>
       </tp:docstring>
@@ -337,19 +335,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         with the state In_Progress.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The <tp:member-ref>SearchState</tp:member-ref> is no longer
             Not_Started, so this method is no longer available.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The search terms included something this connection manager cannot
             search for.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -360,7 +358,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         and continue listing up to <tp:member-ref>Limit</tp:member-ref> more results.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The <tp:member-ref>SearchState</tp:member-ref> is not
             <code>More_Available</code>.
@@ -376,7 +374,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.Error.<tp:error-ref>Cancelled</tp:error-ref></code>.</p>
+          <code>im.telepathy1.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>
@@ -394,7 +392,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           results.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The <tp:member-ref>SearchState</tp:member-ref> is Not_Started, so
             this method is not yet available.
@@ -427,9 +425,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>An array of fields representing information about this
             contact, in the same format used in the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface">ContactInfo</tp:dbus-ref>
+              namespace="im.telepathy1.Connection.Interface">ContactInfo1</tp:dbus-ref>
             interface. It is possible that a separate call to <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.ContactInfo">RequestContactInfo</tp:dbus-ref>
+              namespace="im.telepathy1.Connection.Interface.ContactInfo1">RequestContactInfo</tp:dbus-ref>
             would return more information than this signal provides.</p>
         </tp:docstring>
       </tp:member>
diff --git a/spec/Channel_Type_DBus_Tube.xml b/spec/Channel_Type_DBus_Tube1.xml
index e79ba5aa..a2cb8a7f 100644
--- a/spec/Channel_Type_DBus_Tube.xml
+++ b/spec/Channel_Type_DBus_Tube1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_DBus_Tube" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_DBus_Tube1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2008-2009 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
   <tp:license>
@@ -17,9 +17,9 @@ You should have received a copy of the GNU Lesser General Public
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.DBusTube">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Tube"/>
+  <interface name="im.telepathy1.Channel.Type.DBusTube1">
+    <tp:requires interface="im.telepathy1.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel.Interface.Tube1"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A D-Bus tube is an ordered reliable transport, for transporting D-Bus
         traffic.</p>
@@ -61,7 +61,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         tp:type="String_Variant_Map">
         <tp:docstring>
           The dictionary of arbitrary
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Tube">Parameters</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface.Tube1">Parameters</tp:dbus-ref>
           to send with the tube offer.
         </tp:docstring>
       </arg>
@@ -77,8 +77,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The contact associated with this channel doesn't have tubes
             capabilities.
@@ -92,7 +92,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         Accept a D-Bus tube that's in the "local pending" state. The
         connection manager will attempt to open the tube. The tube remains in
         the "local pending" state until the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Tube">TubeChannelStateChanged</tp:dbus-ref>
+          namespace="im.telepathy1.Channel.Interface.Tube1">TubeChannelStateChanged</tp:dbus-ref>
         signal is emitted.
       </tp:docstring>
       <arg direction="in" name="access_control" type="u" tp:type="Socket_Access_Control">
@@ -138,7 +138,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           other end.</p>
         <p>When requesting a channel with
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
+            namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>,
           this property MUST be included in the request.</p>
       </tp:docstring>
     </property>
@@ -190,7 +190,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:rationale>
 
         <p>When requesting a channel with
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
           this property MUST NOT be included in the request.</p>
 
       </tp:docstring>
diff --git a/spec/Channel_Type_File_Transfer.xml b/spec/Channel_Type_File_Transfer1.xml
index 493ac54f..50d59ff9 100644
--- a/spec/Channel_Type_File_Transfer.xml
+++ b/spec/Channel_Type_File_Transfer1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_File_Transfer" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_File_Transfer1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>
     Copyright © 2008-2009 Collabora Limited
   </tp:copyright>
@@ -18,8 +18,8 @@ Library General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.FileTransfer">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Type.FileTransfer1">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:added version="0.17.18">(as stable API)</tp:added>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel type for transferring files. The
@@ -70,7 +70,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </li></ul>
 
       <p>If something goes wrong with the transfer,
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>
+      <tp:dbus-ref namespace="im.telepathy1">Channel.Close</tp:dbus-ref>
       should be called on the channel.</p>
 
       <p>The File channel type may be requested for handles of type
@@ -80,7 +80,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>Connection managers SHOULD NOT advertise support for file transfer to
         other contacts unless it has been indicated by a call to
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>.
+          namespace="im.telepathy1.Connection.Interface.ContactCapabilities1">UpdateCapabilities</tp:dbus-ref>.
       </p>
       <tp:rationale>
         <p>People would send us files, and it would always fail. That would be silly.</p>
@@ -102,7 +102,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         been created.</p>
 
         <p>This property is mandatory when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. Protocols which do not have a content-type property with file
         transfers should set this value to application/octet-stream.</p>
       </tp:docstring>
@@ -120,7 +120,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         be set to monkey.pdf.</p>
 
         <p>This property is mandatory when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. This property cannot be empty and MUST be set to a sensible value.</p>
       </tp:docstring>
     </property>
@@ -138,7 +138,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         to the byte.</p>
 
         <p>This property is mandatory when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. If this information isn't provided in the protocol, connection managers MUST set it
         to UINT64_MAX.</p>
       </tp:docstring>
@@ -151,15 +151,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>The type of the <tp:member-ref>ContentHash</tp:member-ref> property.</p>
 
         <p>This property is optional when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. However, if you wish to include the <tp:member-ref>ContentHash</tp:member-ref>
         property you MUST also include this property. If you omit this property from a
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method call then its value will be assumed to be File_Hash_Type_None.</p>
 
         <p>For each supported hash type, implementations SHOULD include an entry
           in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
           with this property fixed to that hash type. If the protocol supports
           offering a file without a content hash, implementations SHOULD list
           this property in Allowed in a requestable channel class, mapping hash
@@ -177,7 +177,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         property.</p>
 
         <p>This property is optional when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. Its value MUST correspond to the appropriate type of the
         <tp:member-ref>ContentHashType</tp:member-ref> property. If the
         ContentHashType property is not set, or set to File_Hash_Type_None,
@@ -192,7 +192,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         channel has been created.</p>
 
         <p>This property is optional when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method. If this property was not provided by the remote party, connection managers MUST set it to
         the empty string.</p>
       </tp:docstring>
@@ -206,7 +206,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         cannot change once the channel has been created</p>
 
         <p>This property is optional when requesting the channel with the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
         method.</p>
       </tp:docstring>
     </property>
@@ -440,18 +440,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The given address type or access-control mechanism is not supported.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
           <tp:docstring>
             Your address type, access control, access control parameter,
             offset, or a combination of all four is invalid.
           </tp:docstring>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The file transfer is not in the Pending state, there isn't
             or there is a local error with acquiring a socket.
@@ -492,17 +492,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The given address type or access-control mechanism is not supported.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
           <tp:docstring>
             Your address type, access control, access control parameter, or
             a combination of all three is invalid.
           </tp:docstring>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             Channel is not an outgoing transfer, ProvideFile has already been called,
             or there was a local error acquiring the socket.
diff --git a/spec/Channel_Type_Room_List.xml b/spec/Channel_Type_Room_List1.xml
index 7347a1fc..66604fb4 100644
--- a/spec/Channel_Type_Room_List.xml
+++ b/spec/Channel_Type_Room_List1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Room_List" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_Room_List1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2006 INdT </tp:copyright>
@@ -18,8 +18,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.RoomList">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+  <interface name="im.telepathy1.Channel.Type.RoomList1">
+    <tp:requires interface="im.telepathy1.Channel"/>
 
     <tp:struct name="Room_Info" array-name="Room_Info_List">
       <tp:member type="u" tp:type="Room_Handle" name="Handle"/>
@@ -63,19 +63,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when information about rooms on the server becomes available.
-        The array contains the room handle (as can be passed to the
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection">RequestChannel</tp:dbus-ref>
-        method with HANDLE_TYPE_ROOM), the channel
-        type, and a dictionary containing further information about the
-        room as available. The following well-known keys and types are
-        recommended for use where appropriate:</p>
+        <p>Emitted when information about rooms on the server becomes
+          available.  The array contains the room handle (as can be
+          passed to the <tp:dbus-ref
+          namespace="imt1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>
+          method with <tp:dbus-ref
+          namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>=
+          HANDLE_TYPE_ROOM), the channel type, and a dictionary
+          containing further information about the room as
+          available. The following well-known keys and types are
+          recommended for use where appropriate:</p>
 
         <dl>
           <dt>handle-name (s)</dt>
-          <dd>The identifier of the room (as would be returned by
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>).
+          <dd>The identifier of the room.
             This property is mandatory.</dd>
 
           <dt>name (s)</dt>
@@ -87,7 +88,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dt>subject (s)</dt>
           <dd>The current subject of conversation in the room (as would
             be returned by getting the string part of the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Subject2"
+            namespace="im.telepathy1.Channel.Interface.Subject1"
             >Subject</tp:dbus-ref> property)</dd>
 
           <dt>members (u)</dt>
@@ -102,13 +103,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dt>room-id (s)</dt>
           <dd>The human-readable identifier of a chat room (as would be
             returned by getting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Room2"
+            namespace="im.telepathy1.Channel.Interface.Room1"
             >RoomName</tp:dbus-ref> property)</dd>
 
           <dt>server (s)</dt>
           <dd>The DNS name of the server hosting these channels (as would be
             returned by getting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Room2"
+            namespace="im.telepathy1.Channel.Interface.Room1"
             >Server</tp:dbus-ref> property)</dd>
         </dl>
       </tp:docstring>
@@ -123,10 +124,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         the request is complete.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
     <method name="StopListing" tp:name-for-bindings="Stop_Listing">
@@ -149,7 +150,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>A channel type for listing named channels available on the server. Once the
     <tp:member-ref>ListRooms</tp:member-ref> method is called, it emits signals for rooms present on the
     server, until you <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> this
+    namespace="im.telepathy1.Channel">Close</tp:dbus-ref> this
     channel. In some cases, it may not be possible
     to stop the deluge of information from the server. This channel should be
     closed when the room information is no longer being displayed, so that the
diff --git a/spec/Channel_Type_Server_Authentication.xml b/spec/Channel_Type_Server_Authentication1.xml
index 76599aa3..461cef02 100644
--- a/spec/Channel_Type_Server_Authentication.xml
+++ b/spec/Channel_Type_Server_Authentication1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Server_Authentication" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_Server_Authentication1" 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
@@ -16,17 +16,17 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerAuthentication">
+  <interface name="im.telepathy1.Channel.Type.ServerAuthentication1">
     <tp:added version="0.21.5">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.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>
+        such as <tp:dbus-ref namespace="imt1"
+          >Channel.Interface.SASLAuthentication1</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
@@ -35,7 +35,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <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>
+        while the <tp:dbus-ref namespace="imt1">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>
@@ -46,24 +46,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
       <p>Channels of this type cannot be requested with methods such as
         <tp:dbus-ref
-          namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+          namespace="imt1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
         They always have <tp:dbus-ref
-          namespace="ofdT.Channel">Requested</tp:dbus-ref> = False,
+          namespace="imt1.Channel">Requested</tp:dbus-ref> = False,
         <tp:dbus-ref
-          namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = None
+          namespace="imt1.Channel">TargetHandleType</tp:dbus-ref> = None
         and <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+          namespace="im.telepathy1.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>
+        <tp:dbus-ref namespace="imt1.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"
+          namespace="imt1.Channel.Interface.SASLAuthentication1"
           >AcceptSASL</tp:dbus-ref> method), or closed with the <tp:dbus-ref
-          namespace="ofdT.Channel">Close</tp:dbus-ref> method.</p>
+          namespace="imt1.Channel">Close</tp:dbus-ref> method.</p>
 
       <tp:rationale>
         <p>ServerAuthentication channels normally represent the client
@@ -75,7 +75,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </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
+            namespace="imt1.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>
@@ -83,16 +83,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <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>,
+          namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>,
         for instance from the <tp:dbus-ref
-          namespace="ofdT">Account.Parameters</tp:dbus-ref>). If this fails
+          namespace="imt1">Account.Parameters</tp:dbus-ref>). If this fails
         or has already been tried, the <tp:dbus-ref
-          namespace="ofdT">Connection</tp:dbus-ref> will
+          namespace="imt1">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
+            namespace="imt1">ChannelDispatcher</tp:dbus-ref> will close the
           channel if it cannot find a handler.</p>
       </tp:rationale>
 
@@ -108,11 +108,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <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>
+          <tp:dbus-ref namespace="imt1.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:dbus-ref namespace="imt1"
+            >Channel.Interface.SASLAuthentication1</tp:dbus-ref>.</p>
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Type_Server_TLS_Connection.xml b/spec/Channel_Type_Server_TLS_Connection1.xml
index 97efd1b3..89fe43c6 100644
--- a/spec/Channel_Type_Server_TLS_Connection.xml
+++ b/spec/Channel_Type_Server_TLS_Connection1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Server_TLS_Connection"
+<node name="/Channel_Type_Server_TLS_Connection1"
     xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2010 Collabora Limited </tp:copyright>
   <tp:license>
@@ -18,26 +18,26 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Type.ServerTLSConnection">
+  <interface name="im.telepathy1.Channel.Type.ServerTLSConnection1">
     <tp:added version="0.19.13">(as stable API)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel type that carries a TLS certificate between a server
       and a client connecting to it.</p>
       <p>Channels of this kind always have <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref> = False,
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
-      = None and <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+      namespace="im.telepathy1.Channel">Requested</tp:dbus-ref> = False,
+      <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandleType</tp:dbus-ref>
+      = None and <tp:dbus-ref namespace="im.telepathy1.Channel">TargetHandle</tp:dbus-ref>
       = 0, and cannot be requested with methods such as <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+      namespace="im.telepathy1.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
       Also, they SHOULD be dispatched while the
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+      <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>
       owning them is in the CONNECTING state.</p>
       <p>In this case, handlers SHOULD accept or reject the certificate, using
       the relevant methods on the provided object, or MAY just <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref> the channel before doing so, to fall
+      namespace="im.telepathy1.Channel">Close</tp:dbus-ref> the channel before doing so, to fall
       back to a non-interactive verification process done inside the CM.</p>
       <p>For example, channels of this kind can pop up while a client is
       connecting to an XMPP server.</p>
@@ -48,7 +48,7 @@
               tp:immutable='yeah'>
       <tp:docstring>
         <p>A <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Authentication">TLSCertificate</tp:dbus-ref>
+        namespace="im.telepathy1.Authentication">TLSCertificate</tp:dbus-ref>
         containing the certificate chain as sent by the server,
         and other relevant information.</p>
       </tp:docstring>
@@ -87,9 +87,9 @@
         contain the value of the <tp:member-ref>Hostname</tp:member-ref>
         property. All other identities included in this property MUST be derived from
         explicit user input or choices, such as <tp:dbus-ref
-        namespace='ofdT.Account'>Parameters</tp:dbus-ref> passed to
+        namespace='imt1.Account'>Parameters</tp:dbus-ref> passed to
         <tp:dbus-ref
-        namespace='ofdT.ConnectionManager'>RequestConnection</tp:dbus-ref>.</p>
+        namespace='imt1.ConnectionManager'>RequestConnection</tp:dbus-ref>.</p>
 
         <tp:rationale>
           <p>The primary use for this property is for XMPP services hosted by
diff --git a/spec/Channel_Type_Stream_Tube.xml b/spec/Channel_Type_Stream_Tube1.xml
index 83655c39..51337978 100644
--- a/spec/Channel_Type_Stream_Tube.xml
+++ b/spec/Channel_Type_Stream_Tube1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Channel_Type_Stream_Tube" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Channel_Type_Stream_Tube1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2008-2009 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
   <tp:license>
@@ -17,9 +17,9 @@ You should have received a copy of the GNU Lesser General Public
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.StreamTube">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Tube"/>
+  <interface name="im.telepathy1.Channel.Type.StreamTube1">
+    <tp:requires interface="im.telepathy1.Channel"/>
+    <tp:requires interface="im.telepathy1.Channel.Interface.Tube1"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A stream tube is a transport for ordered, reliable data transfer,
         similar to SOCK_STREAM sockets.</p>
@@ -63,19 +63,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         tp:type="String_Variant_Map">
         <tp:docstring>
           The dictionary of arbitrary
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Tube">Parameters</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface.Tube1">Parameters</tp:dbus-ref>
           to send with the tube offer.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The contact associated with this channel doesn't have tube
             capabilities.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The connection manager doesn't support the given address type
             or access-control type.
@@ -89,7 +89,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         Accept a stream tube that's in the "local pending" state. The
         connection manager will attempt to open the tube. The tube remains in
         the "local pending" state until the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Tube">TubeChannelStateChanged</tp:dbus-ref>
+          namespace="im.telepathy1.Channel.Interface.Tube1">TubeChannelStateChanged</tp:dbus-ref>
         signal is emitted.
       </tp:docstring>
       <arg direction="in" name="address_type" type="u" tp:type="Socket_Address_Type">
@@ -123,12 +123,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The access_control_param is invalid with the given access_control.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The given address type or access-control mechanism is not supported.
           </tp:docstring>
@@ -149,6 +149,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The handle of the participant who opened the new connection
         </tp:docstring>
       </arg>
+      <arg name="Identifier" type="s">
+        <tp:docstring>
+          The identifier of the participant who opened the new connection
+        </tp:docstring>
+      </arg>
       <arg name="Connection_Param" type="v">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A parameter which can be used by the listening process to identify
@@ -210,11 +215,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
           <p>The following errors can be used:</p>
           <ul>
-            <li><code>org.freedesktop.Telepathy.Error.Cancelled</code>:
+            <li><code>im.telepathy1.Error.Cancelled</code>:
                user closed the socket or the tube.</li>
-            <li><code>org.freedesktop.Telepathy.Error.ConnectionLost</code>:
+            <li><code>im.telepathy1.Error.ConnectionLost</code>:
                the bytestream relaying connection's data has been broken.</li>
-            <li><code>org.freedesktop.Telepathy.Error.ConnectionRefused</code>:
+            <li><code>im.telepathy1.Error.ConnectionRefused</code>:
                the tube offer refused the connection.</li>
           </ul>
         </tp:docstring>
@@ -241,11 +246,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>When the tube is offered, the service name is transmitted to the
           other end.</p>
         <p>When requesting a channel with
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
           this property MUST be included in the request.</p>
       </tp:docstring>
     </property>
 
+    <tp:mapping name="Supported_Socket_Map">
+      <tp:docstring>The supported socket address and access-control types
+        for tubes. See GetAvailableStreamTubeTypes.</tp:docstring>
+      <tp:member name="Address_Type" type="u" tp:type="Socket_Address_Type"/>
+      <tp:member name="Access_Control" type="au"
+        tp:type="Socket_Access_Control[]"/>
+    </tp:mapping>
+
     <property name="SupportedSocketTypes" type="a{uau}"
               tp:type="Supported_Socket_Map" access="read"
               tp:name-for-bindings="Supported_Socket_Types"
@@ -273,7 +286,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           access control.</p>
 
         <p>When requesting a channel with
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
           this property MUST NOT be included in the request.</p>
 
       </tp:docstring>
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
deleted file mode 100644
index aa2b9034..00000000
--- a/spec/Channel_Type_Streamed_Media.xml
+++ /dev/null
@@ -1,853 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Type_Streamed_Media" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright © 2006 INdT </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.StreamedMedia">
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
-
-    <tp:enum name="Media_Stream_Type" type="u"
-      array-name="Media_Stream_Type_List">
-      <tp:enumvalue suffix="Audio" value="0">
-        <tp:docstring>An audio stream</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Video" value="1">
-        <tp:docstring>A video stream</tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:enum name="Media_Stream_State" type="u">
-      <tp:enumvalue suffix="Disconnected" value="0">
-        <tp:docstring>The stream is disconnected.</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Connecting" value="1">
-        <tp:docstring>The stream is trying to connect.</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Connected" value="2">
-        <tp:docstring>The stream is connected.</tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:enum name="Media_Stream_Direction" type="u">
-      <tp:enumvalue suffix="None" value="0">
-        <tp:docstring>Media are not being sent or received</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Send" value="1">
-        <tp:docstring>Media are being sent, but not received</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Receive" value="2">
-        <tp:docstring>Media are being received, but not sent</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Bidirectional" value="3">
-        <tp:docstring>Media are being sent and received</tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:flags name="Media_Stream_Pending_Send" value-prefix="Media_Stream_Pending" type="u">
-      <tp:flag suffix="Local_Send" value="1">
-        <tp:docstring>
-            The local user has been asked to send media by the remote user.
-            Call <tp:member-ref>RequestStreamDirection</tp:member-ref> to
-            indicate whether or not this is acceptable.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Remote_Send" value="2">
-        <tp:docstring>
-            The remote user has been asked to send media by the local user.
-            The <tp:member-ref>StreamDirectionChanged</tp:member-ref> signal
-            will be emitted when the remote user accepts or rejects this
-            change.
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-    <tp:struct name="Media_Stream_Info" array-name="Media_Stream_Info_List">
-      <tp:member type="u" tp:type="Stream_ID" name="Identifier"/>
-      <tp:member type="u" tp:type="Contact_Handle" name="Contact"/>
-      <tp:member type="u" tp:type="Media_Stream_Type" name="Type"/>
-      <tp:member type="u" tp:type="Media_Stream_State" name="State"/>
-      <tp:member type="u" tp:type="Media_Stream_Direction" name="Direction"/>
-      <tp:member type="u" tp:type="Media_Stream_Pending_Send"
-        name="Pending_Send_Flags"/>
-    </tp:struct>
-
-    <tp:simple-type name="Stream_ID" type="u"
-      array-name="Stream_ID_List">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>An unsigned integer identifying a stream within a channel.</p>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <method name="ListStreams" tp:name-for-bindings="List_Streams">
-      <arg direction="out" type="a(uuuuuu)" tp:type="Media_Stream_Info[]"
-        name="Streams">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structs containing:
-          <ul>
-          <li>the stream identifier</li>
-          <li>the contact handle who the stream is with (or 0 if the stream
-            represents more than a single member)</li>
-          <li>the type of the stream</li>
-          <li>the current stream state</li>
-          <li>the current direction of the stream</li>
-          <li>the current pending send flags</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns an array of structs representing the streams currently active
-        within this channel. Each stream is identified by an unsigned integer
-        which is unique for each stream within the channel.
-      </tp:docstring>
-    </method>
-
-    <method name="RemoveStreams" tp:name-for-bindings="Remove_Streams">
-      <arg direction="in" name="Streams" type="au" tp:type="Stream_ID[]">
-        <tp:docstring>
-          An array of stream identifiers (as defined in
-          <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request that the given streams are removed. If all streams are
-          removed, the channel MAY close.</p>
-
-        <p>Clients SHOULD NOT attempt to terminate calls by removing all the
-          streams; instead, clients SHOULD terminate calls by removing the
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref>
-          from the channel, using either
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembers</tp:dbus-ref>
-          or
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>.
-          </p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            A stream identifier is unknown
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="RequestStreamDirection"
-      tp:name-for-bindings="Request_Stream_Direction">
-      <arg direction="in" name="Stream_ID" type="u">
-        <tp:docstring>
-          The stream identifier (as defined in
-          <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Stream_Direction" type="u" tp:type="Media_Stream_Direction">
-        <tp:docstring>
-          The desired stream direction (a value of MediaStreamDirection)
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request a change in the direction of an existing stream. In particular,
-        this might be useful to stop sending media of a particular type,
-        or inform the peer that you are no longer using media that is being
-        sent to you.</p>
-
-        <p>Depending on the protocol, streams which are no longer sending in
-        either direction should be removed and a
-        <tp:member-ref>StreamRemoved</tp:member-ref> signal emitted.
-        Some direction changes can be enforced locally (for example,
-        BIDIRECTIONAL -&gt; RECEIVE can be achieved by merely stopping sending),
-        others may not be possible on some protocols, and some need agreement
-        from the remote end. In this case, the MEDIA_STREAM_PENDING_REMOTE_SEND
-        flag will be set in the
-        <tp:member-ref>StreamDirectionChanged</tp:member-ref> signal, and the
-        signal
-        emitted again without the flag to indicate the resulting direction when
-        the remote end has accepted or rejected the change.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            A stream identifier is unknown
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The requested direction is not available on this stream
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="RequestStreams" tp:name-for-bindings="Request_Streams">
-      <arg direction="in" name="Contact_Handle" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          A contact handle with whom to establish the streams
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Types" type="au" tp:type="Media_Stream_Type[]">
-        <tp:docstring>
-          An array of stream types (values of MediaStreamType)
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a(uuuuuu)" tp:type="Media_Stream_Info[]"
-        name="Streams">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structs (in the same order as the given stream types)
-          containing:
-          <ul>
-            <li>the stream identifier</li>
-            <li>the contact handle who the stream is with (or 0 if the stream
-              represents more than a single member)</li>
-            <li>the type of the stream</li>
-            <li>the current stream state</li>
-            <li>the current direction of the stream</li>
-            <li>the current pending send flags</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request that streams be established to exchange the given types of
-        media with the given member. In general this will try and establish a
-        bidirectional stream, but on some protocols it may not be possible to
-        indicate to the peer that you would like to receive media, so a
-        send-only stream will be created initially. In the cases where the
-        stream requires remote agreement (eg you wish to receive media from
-        them), the <tp:member-ref>StreamDirectionChanged</tp:member-ref> signal
-        will be emitted with the
-        MEDIA_STREAM_PENDING_REMOTE_SEND flag set, and the signal emitted again
-        with the flag cleared when the remote end has replied.</p>
-
-        <p>If streams of the requested types already exist, calling this
-          method results in the creation of additional streams. Accordingly,
-          clients wishing to have exactly one audio stream or exactly one
-          video stream SHOULD check for the current streams using
-          <tp:member-ref>ListStreams</tp:member-ref> before calling this
-          method.</p>
-      </tp:docstring>
-      <tp:changed version="0.17.2">
-        <p>It is valid to use a handle which is neither
-          a current nor pending member in this channel's <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">Group</tp:dbus-ref>
-          interface. If
-          so, that handle will be added to the remote-pending set only when
-          an attempt has actually been made to contact them. For further
-          call-state notification, use the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">CallState</tp:dbus-ref>
-          interface, if
-          supported. This usage was not allowed in spec versions below
-          0.17.2.</p>
-      </tp:changed>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            A stream type given is invalid.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            A stream type given is not implemented by the connection manager.
-            Since 0.17.23, connection managers SHOULD raise this error
-            in preference to InvalidArgument.
-            <tp:rationale>
-              Connection managers can't know whether an unknown number
-              is a valid stream type that was introduced in a later spec
-              version.
-            </tp:rationale>
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            That contact's client does not implement one of the given stream
-            types. For this method, clients SHOULD consider this error and
-            NotCapable to be equivalent.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
-          <tp:docstring>
-            That contact's client does not implement one of the given stream
-            types. Since 0.17.23, connection managers SHOULD raise
-            this in preference to NotAvailable.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="StreamAdded" tp:name-for-bindings="Stream_Added">
-      <arg name="Stream_ID" type="u">
-        <tp:docstring>
-          The stream identifier (as defined in
-          <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <arg name="Contact_Handle" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The contact handle who the stream is with (or 0 if it
-          represents more than a single member)
-        </tp:docstring>
-      </arg>
-      <arg name="Stream_Type" type="u" tp:type="Media_Stream_Type">
-        <tp:docstring>
-          The stream type (a value from MediaStreamType)
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when a new stream has been added to this channel.
-          Clients SHOULD assume that the stream's
-          <tp:type>Media_Stream_State</tp:type> is initially Disconnected.</p>
-
-        <p>If a connection manager needs to represent the addition of a stream
-          whose state is already Connecting or Connected, it MUST do this
-          by emitting StreamAdded, closely followed by
-          <tp:member-ref>StreamStateChanged</tp:member-ref> indicating a
-          change to the appropriate state.</p>
-
-        <tp:rationale>
-          <p>Historically, it was not clear from the StreamAdded signal what
-            the state of the stream was. telepathy-spec 0.17.22
-            clarified this.</p>
-        </tp:rationale>
-
-        <p>Similarly, clients SHOULD assume that the initial
-          <tp:type>Media_Stream_Direction</tp:type> of a newly added stream
-          is Receive, and that the initial
-          <tp:type>Media_Stream_Pending_Send</tp:type> is
-          Pending_Local_Send.</p>
-
-        <p>If a connection manager needs to represent the addition of a stream
-          whose direction or pending-send differs from those initial values,
-          it MUST do so by emitting StreamAdded, closely followed by
-          <tp:member-ref>StreamDirectionChanged</tp:member-ref> indicating a
-          change to the appropriate direction and pending-send state.</p>
-
-        <tp:rationale>
-          <p>StreamAdded doesn't itself indicate the stream's direction; this
-            is unfortunate, but is preserved for compatibility.</p>
-
-          <p>This is the appropriate direction for streams added by a remote
-            contact on existing connection managers, and does not violate
-            user privacy by automatically sending audio or video (audio streams
-            start off muted, video streams start off not sending). For
-            streams added by the local user using the client receiving the
-            signal, the true direction can also be determined from the return
-            value of the <tp:member-ref>RequestStreams</tp:member-ref>
-            method.</p>
-
-          <p>Existing clients typically operate by maintaining a separate
-            idea of the directions that they would like the streams to have,
-            and enforcing these intended directions by calling
-            <tp:member-ref>RequestStreamDirection</tp:member-ref> whenever
-            needed.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </signal>
-
-    <signal name="StreamDirectionChanged"
-      tp:name-for-bindings="Stream_Direction_Changed">
-      <arg name="Stream_ID" type="u">
-        <tp:docstring>
-        The stream identifier (as defined in <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <arg name="Stream_Direction" type="u" tp:type="Media_Stream_Direction">
-        <tp:docstring>
-        The new stream direction (as defined in ListStreams)
-        </tp:docstring>
-      </arg>
-      <arg name="Pending_Flags" type="u" tp:type="Media_Stream_Pending_Send">
-        <tp:docstring>
-        The new pending send flags (as defined in ListStreams)
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when the direction or pending flags of a stream are
-          changed.</p>
-
-        <p>If the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user
-          has requested that we begin sending on this stream.
-          <tp:member-ref>RequestStreamDirection</tp:member-ref>
-          should be called to indicate whether or not this change is
-          acceptable.</p>
-
-        <tp:rationale>
-          <p>This allows for a MSN-style user interface, "Fred has asked you
-            to enable your webcam. (Accept | Reject)", if desired.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </signal>
-
-    <signal name="StreamError" tp:name-for-bindings="Stream_Error">
-      <arg name="Stream_ID" type="u">
-        <tp:docstring>
-        The stream identifier (as defined in
-        <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <arg name="Error_Code" type="u" tp:type="Media_Stream_Error">
-        <tp:docstring>
-          A stream error number, one of the values of MediaStreamError
-        </tp:docstring>
-      </arg>
-      <arg name="Message" type="s">
-        <tp:docstring>
-          A string describing the error (for debugging purposes only)
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when a stream encounters an error.
-      </tp:docstring>
-    </signal>
-
-    <signal name="StreamRemoved" tp:name-for-bindings="Stream_Removed">
-      <arg name="Stream_ID" type="u">
-        <tp:docstring>
-        stream_id - the stream identifier (as defined in
-        <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when a stream has been removed from this channel.
-      </tp:docstring>
-    </signal>
-
-    <signal name="StreamStateChanged"
-      tp:name-for-bindings="Stream_State_Changed">
-      <arg name="Stream_ID" type="u">
-        <tp:docstring>
-          The stream identifier (as defined in
-          <tp:member-ref>ListStreams</tp:member-ref>)
-        </tp:docstring>
-      </arg>
-      <arg name="Stream_State" type="u" tp:type="Media_Stream_State">
-        <tp:docstring>
-          The new stream state (as defined in ListStreams)
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when a member's stream's state changes.
-      </tp:docstring>
-    </signal>
-
-    <property name="InitialAudio" tp:name-for-bindings="Initial_Audio"
-      type="b" access="read">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <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.StreamedMedia">RequestStreams</tp:dbus-ref>.</p>
-
-        <p>If this property, or InitialVideo, is passed to EnsureChannel
-          (as opposed to CreateChannel), the connection manager SHOULD ignore
-          these properties when checking whether it can return an existing
-          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
-          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
-          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.StreamedMedia">ListStreams</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>Connection managers capable of signalling audio calls to contacts
-          SHOULD include a channel class in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
-          with <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>
-          = <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-          and <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
-          = Contact in the fixed properties dictionary, and InitialAudio
-          (and also InitialVideo, if applicable) in the allowed properties
-          list. Clients wishing to discover whether a connection manager
-          can signal audio and/or video calls SHOULD use this information.</p>
-
-        <tp:rationale>
-          <p>Not all protocols support signalling video calls, and it would be
-            possible (although unlikely) to have a protocol where only video,
-            and not audio, could be signalled.</p>
-        </tp:rationale>
-
-        <p>Connection managers that support the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.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 = StreamedMedia
-          in the fixed properties dictionary, and InitialAudio and/or
-          InitialVideo in the allowed properties list. Clients wishing to
-          discover whether a particular contact is likely to be able to
-          receive audio and/or video calls SHOULD use this information.</p>
-
-        <tp:rationale>
-          <p>Not all clients support video calls, and it would also be
-            possible (although unlikely) to have a client which could only
-            stream video, not audio.</p>
-        </tp:rationale>
-
-        <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>
-          (clients of a <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>
-          properties):</p>
-
-        <ul>
-          <li>{ ChannelType = StreamedMedia }</li>
-          <li>{ ChannelType = StreamedMedia, InitialAudio = true }
-            if receiving calls with audio is supported</li>
-          <li>{ ChannelType = StreamedMedia, InitialVideo = true }
-            if receiving calls with video is supported</li>
-        </ul>
-
-        <tp:rationale>
-          <p>Connection managers for protocols with capability discovery,
-            like XMPP, need this information to advertise the appropriate
-            capabilities for their protocol.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-    <property name="InitialVideo" tp:name-for-bindings="Initial_Video"
-      type="b" access="read">
-      <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
-          imply that an active video stream has not been added, only that no
-          video stream was active at the time the channel appeared.</p>
-
-        <p>This property is the correct way to discover whether connection
-          managers, contacts etc. support video calls; it appears in
-          capabilities structures in the same way as InitialAudio.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="ImmutableStreams" tp:name-for-bindings="Immutable_Streams"
-      type="b" access="read">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If <tt>True</tt>, once streams have been requested for this channel
-          (either by setting <tp:member-ref>InitialAudio</tp:member-ref> or
-          <tp:member-ref>InitialVideo</tp:member-ref> when the channel is
-          requested, or by calling
-          <tp:member-ref>RequestStreams</tp:member-ref> on a channel with no
-          streams), a stream of a different content type cannot be added;
-          subsequent calls to <tp:member-ref>RequestStreams</tp:member-ref>
-          that attempt to do so will fail.</p>
-
-        <p>If this property is missing, clients SHOULD assume that it is false,
-          and thus that the channel's streams can be changed once the call has
-          started.</p>
-
-        <p>If this property is present in the "allowed" set in all of the
-          StreamedMedia entries in a contact's capabilities, then user
-          interfaces MAY choose to show a separate "call" option for each
-          class of call.</p>
-
-          <tp:rationale>
-            <p>For example, once an audio-only Google Talk call has started,
-              it is not possible to add a video stream; both audio and video
-              must be requested at the start of the call if video is desired.
-              User interfaces may use this pseudo-capability as a hint to
-              display separate "Audio call" and "Video call" buttons, rather
-              than a single "Call" button with the option to add and remove
-              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>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A channel that can send and receive streamed media such as audio or
-        video.  Provides a number of methods for listing and requesting new
-        streams, and signals to indicate when streams have been added, removed
-        and changed status. The state of the call (ringing remotely, ringing
-        locally, answered, missed, etc.) are represented using the properties
-        and signals of the Group interface.</p>
-
-      <p>In general this should be used in conjunction with the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
-        interface to exchange connection candidates and codec choices with
-        whichever component is responsible for the streams. However, in certain
-        applications where no candidate exchange is necessary (eg the streams
-        are handled by specialised hardware which is controlled directly by the
-        connection manager), the signalling interface can be omitted and this
-        channel type used simply to control the streams.</p>
-
-      <h4>Outgoing calls</h4>
-
-      <p>To make an audio-only call to a contact <tt>foo@example.com</tt>,
-        clients should call:</p>
-
-      <blockquote>
-        <pre>
-<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>: <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>,
-  <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Contact,
-  <tp:dbus-ref
-    namespace="org.freedesktop.Telepathy.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="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
-        may be used in place of TargetID if the contact's handle is already
-        known. To make an audio-and-video call, the client 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 that the call is outgoing); the <tp:dbus-ref
-          namespace='ofdT.Channel.Interface'>Group</tp:dbus-ref> interface should
-        initially have the local user in <tp:dbus-ref
-          namespace='ofdT.Channel.Interface.Group'>Members</tp:dbus-ref> and the remote
-        contact in <tp:dbus-ref
-          namespace='ofdT.Channel.Interface.Group'>RemotePendingMembers</tp:dbus-ref>, to
-        indicate that we are awaiting their response.</p>
-
-      <p>The contact answering the call is represented by the CM signalling
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Group">MembersChanged</tp:dbus-ref>,
-        moving the remote contact to Members, with the remote contact as the
-        <var>Actor</var> and <var>Reason</var> <code>None</code>. The contact
-        rejecting the call is represented by both contacts being removed from
-        the group, with the remote contact as the <var>Actor</var> and
-        <var>Reason</var> set appropriately. The local user may hang up at any
-        time by calling
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>
-        to remove themself, with an appropriate reason; the CM SHOULD relay the
-        reason to the remote contact, and emit MembersChanged removing both
-        contacts from the group with the self handle as the <var>Actor</var>.</p>
-
-      <p>(In the past, several other patterns have been used to place outgoing
-        calls; see
-        <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
-        for the details.)</p>
-
-      <h4>Incoming calls</h4>
-
-      <p>Incoming calls' immutable properties should contain <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
-        = Contact, both <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref> and
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">InitiatorHandle</tp:dbus-ref>
-        set to the remote contact, <tp:dbus-ref
-        namespace='ofdT.Channel'>Requested</tp:dbus-ref> = <code>False</code>
-        (indicating that this is an incoming call), and appropriate values of
-        <tp:member-ref>InitialAudio</tp:member-ref> and
-        <tp:member-ref>InitialVideo</tp:member-ref>; the Group interface should
-        initially have the local user in <tp:dbus-ref
-        namespace="ofdT.Channel.Interface.Group">LocalPendingMembers</tp:dbus-ref>
-        and the remote contact in <tp:dbus-ref
-        namespace="ofdT.Channel.Interface.Group">Members</tp:dbus-ref>,
-        indicating that the contact is awaiting our response.</p>
-
-      <p>To accept the call, use <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Group">AddMembers</tp:dbus-ref>
-        to move the local user to the group's members. To reject the call, use
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>
-        to remove the local member from the group, with an appropriate reason.
-        If the remote user ends the call before it is answered, this is
-        represented by <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface.Group">MembersChanged</tp:dbus-ref>
-        removing both parties from the group with the remote contact as the
-        <var>Actor</var>, and <var>Reason</var> set appropriately.</p>
-
-      <p>Note that the call may end with the self handle as the
-        <var>Actor</var> without the user having chosen to reject the call, as
-        indicated by the nature of the <var>Reason</var>. Specifically, some
-        local component may time out the call (indicating this with reason
-        <code>No_Answer</code>; for example, the CM may have forwarded the call
-        to another number, as configured using <tp:dbus-ref
-        namespace='ofdT.Connection.Interface'>Forwarding.DRAFT</tp:dbus-ref>),
-        or something may have gone wrong with the call
-        (indicated by reason <code>Error</code>). Such calls SHOULD be
-        considered missed, just as if the remote contact had hung up before the
-        local user answered the call.</p>
-
-      <tp:rationale>
-        <p>This is a bit awkward, but these are the best ways we can represent
-          these situations. It's important to document which calls should be
-          considered missed, to ensure that the user can be notified.</p>
-      </tp:rationale>
-
-      <p>When the local user accepts an incoming call, the connection manager
-        SHOULD change the direction of any streams with pending local send
-        to be sending, without altering whether those streams are
-        receiving.</p>
-
-      <tp:rationale>
-        <p>This matches existing practice, and means that a client
-          can answer incoming calls and get an unmuted microphone/activated
-          webcam without having to take additional action to accept the
-          stream directions.</p>
-
-        <p>It does, however, introduce a race condition: a client believing
-          that it is accepting an audio-only call by calling AddMembers
-          can inadvertantly accept an audio + video call (and hence activate
-          sending from a webcam without the user's permission) if a video
-          stream is added just before AddMembers is processed. This race
-          should be removed when this specification is revised.</p>
-      </tp:rationale>
-
-    <h4>During a call</h4>
-
-    <p>If <tp:member-ref>ImmutableStreams</tp:member-ref> is
-      <code>False</code>, new streams may be requested using
-      <tp:member-ref>RequestStreams</tp:member-ref> (to add video to an
-      audio-only call, for instance), and existing streams may be removed using
-      <tp:member-ref>RemoveStreams</tp:member-ref> (for example, to downgrade
-      an audio-video call to audio-only). The call may be ended by calling
-      <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembers</tp:dbus-ref>
-      or <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>; the call ending is signalled by the CM emitting <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface.Group">MembersChanged</tp:dbus-ref>,
-      removing both parties from the group.</p>
-
-    <h4>Handler filters</h4>
-
-    <p>For historical reasons, handlers must specify more than one filter if
-      they want to correctly advertise support for audio and/or video calls. If
-      they can handle channels using the <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
-      interface, they should also advertise various
-      <tp:type>Handler_Capability_Token</tp:type>s to indicate which codecs and
-      transports they support. See <tp:member-ref>InitialAudio</tp:member-ref>
-      and <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling/video/h264</tp:dbus-ref>
-      for the gory details. In summary:</p>
-
-    <dl>
-      <dt>To advertise support for streamed media in general, include the
-        following filter in <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>:</dt>
-      <dd><pre>
-{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
-  '...Channel.TargetHandleType': Contact,
-}</pre></dd>
-
-      <dt>To advertise support for audio calls, also include the following
-        filter:</dt>
-      <dd><pre>
-{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
-  '...Channel.TargetHandleType': Contact,
-  '...Channel.Type.StreamedMedia.InitialAudio': True,
-}</pre></dd>
-
-      <dt>To advertise support for video calls, also include the following
-        filter:</dt>
-      <dd><pre>
-{ '...Channel.ChannelType': '...Channel.Type.StreamedMedia' ,
-  '...Channel.TargetHandleType': Contact,
-  '...Channel.Type.StreamedMedia.InitialVideo': True,
-}</pre></dd>
-
-      <dt>If you use telepathy-farsight, and have H.264 support, you probably
-        want these <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref>:</dt>
-      <dd><pre>
-[ "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp",
-  "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/gtalk-p2p",
-  "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264",
-]</pre></dd>
-    </dl>
-    </tp:docstring>
-
-    <tp:flags name="Channel_Media_Capabilities" value-prefix="Channel_Media_Capability" type="u">
-      <tp:docstring>
-        The channel-type-specific capability flags used for
-        Channel.Type.StreamedMedia in the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection.Interface.Capabilities</tp:dbus-ref>
-        interface. See the <tp:member-ref>InitialAudio</tp:member-ref>
-        property for details of the mechanisms that will replace this.
-      </tp:docstring>
-      <tp:flag suffix="Audio" value="1">
-        <tp:docstring>
-          The handle is capable of using audio streams within a media channel.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Video" value="2">
-        <tp:docstring>
-          The handle is capable of using video streams within a media channel.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="NAT_Traversal_STUN" value="4">
-        <tp:docstring>
-          The handle is capable of performing STUN to traverse NATs.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="NAT_Traversal_GTalk_P2P" value="8">
-        <tp:docstring>
-          The handle is capable of establishing Google Talk peer-to-peer
-          connections (as implemented in libjingle 0.3) to traverse NATs.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="NAT_Traversal_ICE_UDP" value="16">
-        <tp:docstring>
-          The handle is capable of establishing ICE UDP peer-to-peer
-          connections (as defined by the IETF MMUSIC working group) to traverse
-          NATs.
-        </tp:docstring>
-      </tp:flag>
-
-      <tp:flag suffix="Immutable_Streams" value="32">
-        <tp:docstring>
-          Channels whose target handle is this contact will have
-          <tp:member-ref>ImmutableStreams</tp:member-ref> = <tt>True</tt>.
-        </tp:docstring>
-      </tp:flag>
-
-    </tp:flags>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index 76123293..b848bf09 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -1,6 +1,6 @@
 <?xml version="1.0" ?>
 <node name="/Channel_Type_Text" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
+  <tp:copyright> Copyright © 2005-2011 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2006 INdT </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -18,20 +18,19 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.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>
+  <interface name="im.telepathy1.Channel.Type.Text">
+    <tp:requires interface="im.telepathy1.Channel"/>
     <tp:changed version="0.24.0">This interface used to have a bunch of
-      clunky <tp:dbus-ref
-      namespace='org.freedesktop'>Telepathy.Properties</tp:dbus-ref>. They have
-      been removed in favour of D-Bus properties on the <tp:dbus-ref
-      namespace='ofdT.Channel.Interface'>Room2</tp:dbus-ref>, <tp:dbus-ref
-      namespace='ofdT.Channel.Interface'>Subject2</tp:dbus-ref> and
-      <tp:dbus-ref namespace='ofdT.Channel.Interface'>RoomConfig1</tp:dbus-ref>
+      clunky Telepathy.Properties. They have been removed in favour of
+      D-Bus properties on the <tp:dbus-ref
+      namespace='imt1.Channel.Interface'>Room1</tp:dbus-ref>, <tp:dbus-ref
+      namespace='imt1.Channel.Interface'>Subject1</tp:dbus-ref> and
+      <tp:dbus-ref namespace='imt1.Channel.Interface'>RoomConfig1</tp:dbus-ref>
       interfaces.</tp:changed>
+    <tp:changed version="0.99.1">Deprecated methods and types have
+      removed from this interface. Additionally, this interface has
+      been merged with the old, now-removed, Messages interface as it
+      was a requirement since version 0.21.5.</tp:changed>
 
     <tp:simple-type name="Message_ID" type="u" array-name="Message_ID_List">
       <tp:docstring>
@@ -42,24 +41,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </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
-        <tp:member-ref>ListPendingMessages</tp:member-ref>.  The arguments of
-        the <tp:member-ref>Received</tp:member-ref> signal also match this
-        struct's signature.</tp:docstring>
-      <tp:member type="u" tp:type="Message_ID" name="Identifier"/>
-      <tp:member type="u" tp:type="Unix_Timestamp" name="Unix_Timestamp"/>
-      <tp:member type="u" tp:type="Contact_Handle" name="Sender"/>
-      <tp:member type="u" tp:type="Channel_Text_Message_Type"
-                 name="Message_Type"/>
-      <tp:member type="u" tp:type="Channel_Text_Message_Flags" name="Flags"/>
-      <tp:member type="s" name="Text"/>
-    </tp:struct>
-
     <method name="AcknowledgePendingMessages"
       tp:name-for-bindings="Acknowledge_Pending_Messages">
       <arg direction="in" name="IDs" type="au" tp:type="Message_ID[]">
@@ -72,7 +53,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         the user (or equivalent), so they can be removed from the pending queue.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             A given message ID was not found, so no action was taken
           </tp:docstring>
@@ -80,448 +61,1421 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:possible-errors>
     </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>
-          An array of integer message types (ChannelTextMessageType)
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Return an array indicating which types of message may be sent on this
-        channel.
-      </tp:docstring>
-    </method>
-
-    <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
-          <tp:member-ref>AcknowledgePendingMessages</tp:member-ref> had also
-          been called.
-        </tp:docstring>
-        <tp:deprecated version="0.17.3">
-          Setting this to true is NOT RECOMMENDED for clients that
-          have some sort of persistent message storage - clients SHOULD only
-          acknowledge messages after they have actually stored them, which is
-          impossible if this flag is true.</tp:deprecated>
-      </arg>
-      <arg direction="out" type="a(uuuuus)" tp:type="Pending_Text_Message[]"
-        name="Pending_Messages">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structs representing the pending queue. Each contains:
-          <ul>
-            <li>a numeric identifier</li>
-            <li>a Unix timestamp indicating when the message was received</li>
-            <li>the contact handle for the contact who sent the message</li>
-            <li>the message type, taken from ChannelTextMessageType</li>
-            <li>the bitwise-OR of the message flags from ChannelTextMessageFlags</li>
-            <li>the text of the message</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        List the messages currently in the pending queue, and optionally
-        remove then all.
-      </tp:docstring>
-    </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
-        due to lack of memory.
-      </tp:docstring>
-    </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:enum name="Channel_Text_Send_Error" type="u">
+      <tp:enumvalue suffix="Unknown" value="0">
         <tp:docstring>
-          A numeric identifier for acknowledging the message
+        An unknown error occurred
         </tp:docstring>
-      </arg>
-      <arg name="Timestamp" type="u" tp:type="Unix_Timestamp">
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Offline" value="1">
         <tp:docstring>
-          A Unix timestamp indicating when the message was received
+        The requested contact was offline
         </tp:docstring>
-      </arg>
-      <arg name="Sender" type="u" tp:type="Contact_Handle">
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Invalid_Contact" value="2">
         <tp:docstring>
-          The handle of the contact who sent the message
+        The requested contact is not valid
         </tp:docstring>
-      </arg>
-      <arg name="Type" type="u" tp:type="Channel_Text_Message_Type">
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Permission_Denied" value="3">
         <tp:docstring>
-          The type of the message (normal, action, notice, etc.)
+        The user does not have permission to speak on this channel
         </tp:docstring>
-      </arg>
-      <arg name="Flags" type="u" tp:type="Channel_Text_Message_Flags">
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Too_Long" value="4">
         <tp:docstring>
-          A bitwise OR of the message flags
+        The outgoing message was too long and was rejected by the server
         </tp:docstring>
-      </arg>
-      <arg name="Text" type="s">
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Not_Implemented" value="5">
         <tp:docstring>
-          The text of the message
+        The channel doesn't support sending text messages to the requested
+        contact
         </tp:docstring>
-      </arg>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:enum name="Channel_Text_Message_Type" type="u"
+      array-name="Channel_Text_Message_Type_List">
       <tp:docstring>
-        Signals that a message with the given id, timestamp, sender, type
-        and text has been received on this channel. Applications that catch
-        this signal and reliably inform the user of the message should
-        acknowledge that they have dealt with the message with the
-        <tp:member-ref>AcknowledgePendingMessages</tp:member-ref> method.
+        The type of message.
       </tp:docstring>
-    </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:enumvalue suffix="Normal" value="0">
         <tp:docstring>
-          An integer indicating the type of the message
+        An ordinary chat message. Unknown types SHOULD be treated like this.
         </tp:docstring>
-      </arg>
-      <arg direction="in" name="Text" type="s">
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Action" value="1">
         <tp:docstring>
-          The message to send
+        An action which might be presented to the user as
+        "* &lt;sender&gt; &lt;action&gt;", such as an IRC CTCP
+        ACTION (typically selected by the "/me" command). For example, the
+        text of the message might be "drinks more coffee".
         </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request that a message be sent on this channel. When the message has
-          been submitted for delivery, this method will return and the
-          <tp:member-ref>Sent</tp:member-ref> signal will be emitted. If the
-          message cannot be submitted for delivery, the method returns an error
-          and no signal is emitted.</p>
-
-        <p>This method SHOULD return before the Sent signal is
-          emitted.</p>
-
-        <tp:rationale>
-          <p>When a Text channel implements the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Interface">Messages</tp:dbus-ref>
-            interface, that "SHOULD" becomes a "MUST".</p>
-        </tp:rationale>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
+      </tp:enumvalue>
 
-    <tp:enum name="Channel_Text_Send_Error" type="u">
-      <tp:enumvalue suffix="Unknown" value="0">
+      <tp:enumvalue suffix="Notice" value="2">
         <tp:docstring>
-        An unknown error occurred
+        A one-off or automated message not necessarily expecting a reply
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Offline" value="1">
+
+      <tp:enumvalue suffix="Auto_Reply" value="3">
         <tp:docstring>
-        The requested contact was offline
+        An automatically-generated reply message.
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Invalid_Contact" value="2">
+
+      <tp:enumvalue suffix="Delivery_Report" value="4">
         <tp:docstring>
-        The requested contact is not valid
+          A delivery report. See <tp:type>Message_Part</tp:type> for
+          the format that delivery reports must take.
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Permission_Denied" value="3">
+
+    </tp:enum>
+
+    <property name="SupportedContentTypes" type="as" access="read"
+      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 "*/*"
+          to indicate that attachments with arbitrary MIME types can be sent.
+          This list MUST NOT be empty, since all 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>
+
+        <dl>
+          <dt>A simple IM implementation: only plain text messages are
+            allowed</dt>
+          <dd>SupportedContentTypes = ['text/plain'],
+            MessagePartSupportFlags = 0</dd>
+
+          <dt>Formatted text with a plain text alternative is allowed (see the
+            HTML interface draft)</dt>
+          <dd>SupportedContentTypes = ['text/html', 'text/plain'],
+            MessagePartSupportFlags = 0</dd>
+
+          <dt>JPEG or PNG images may be sent, but without any attached
+            text</dt>
+          <dd>SupportedContentTypes = ['text/plain', 'image/jpeg',
+            'image/png'], MessagePartSupportFlags = 0</dd>
+
+          <dt>Unformatted text to which an optional JPEG or PNG image may be
+            attached</dt>
+          <dd>SupportedContentTypes = ['text/plain', 'image/jpeg',
+            'image/png'], MessagePartSupportFlags = One_Attachment</dd>
+
+          <dt>Formatted text to which arbitrarily many images may be
+            attached</dt>
+          <dd>SupportedContentTypes = ['text/html', 'text/plain', 'image/jpeg',
+            'image/png', 'image/x-ms-bmp'], MessagePartSupportFlags =
+            One_Attachment | Multiple_Attachments</dd>
+
+          <dt>A full SIP implementation: arbitrary MIME messages are
+            allowed</dt>
+          <dd>SupportedContentTypes = ['*/*'], MessagePartSupportFlags =
+            One_Attachment | Multiple_Attachments</dd>
+        </dl>
+      </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"/>
+      <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:immutable="yes">
+      <tp:docstring>
+        Flags indicating the level of support for message parts on this
+        channel.
+      </tp:docstring>
+    </property>
+
+    <tp:flags name="Message_Part_Support_Flags"
+      value-prefix="Message_Part_Support_Flag" type="u">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Flags indicating the level of support for message parts on this
+          channel. They are designed such that setting more flags always
+          implies that the channel has more capabilities.</p>
+
+        <p>If no flags are set, this indicates that messages may contain
+          a single message part whose content-type is any of the types
+          from SupportedContentTypes, possibly with some alternatives.</p>
+
+        <p>There is no flag indicating support for alternatives. This is
+          because the SendMessage implementation can always accept messages
+          containing alternatives, even if the underlying protocol does not,
+          by deleting all alternatives except the first (most preferred)
+          that is supported.</p>
+
+        <tp:rationale>
+          Each of the flags so far implies the previous flag, so we could
+          have used a simple enumeration here; however, we've defined
+          the message-part support indicator as a flag set for future
+          expansion.
+        </tp:rationale>
+
+        <p>See <tp:member-ref>SupportedContentTypes</tp:member-ref> for some
+          examples.</p>
+      </tp:docstring>
+
+      <tp:flag suffix="One_Attachment" value="1">
         <tp:docstring>
-        The user does not have permission to speak on this channel
+          <tp:member-ref>SendMessage</tp:member-ref> will accept messages
+          containing a textual message body,
+          plus a single attachment of any type listed in the
+          SupportedContentTypes property. It does not make sense for this
+          flag to be set if Message_Part_Support_Flag_Data_Only is not also set
+          (because the connection manager can trivially provide an empty text
+          part if necessary).
         </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Too_Long" value="4">
+      </tp:flag>
+      <tp:flag suffix="Multiple_Attachments" value="2">
         <tp:docstring>
-        The outgoing message was too long and was rejected by the server
+          SendMessage will accept messages containing a textual message body,
+          plus an arbitrary number of attachments of any type listed in the
+          SupportedContentTypes property. It does not make sense for this
+          flag to be set if Message_Part_Support_Flag_One_Attachment is not
+          also set.
         </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Not_Implemented" value="5">
+      </tp:flag>
+    </tp:flags>
+
+    <tp:mapping name="Message_Part" array-name="Message_Part_List"
+      array-depth="2">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Part of a message's content. In practice, this mapping never
+          appears in isolation: incoming messages are represented by a list of
+          <tp:type>Message_Part</tp:type> mappings in the
+          <tp:member-ref>MessageReceived</tp:member-ref> signal, and outgoing
+          messages are passed to <tp:member-ref>SendMessage</tp:member-ref> as
+          a list of these mappings.</p>
+
+        <p>The first part of the message contains "headers", which refer
+          to the entire message. The second and subsequent parts contain the
+          message's content, including plain text, formatted text and/or
+          attached files. Well-known keys for the header and body parts are
+          defined by the <tp:type>Message_Header_Key</tp:type> and
+          <tp:type>Message_Body_Key</tp:type> types, respectively.  It is an
+          error for a connection manager to put keys referring to the message
+          as a whole in the second or subsequent Message_Part, or keys intended
+          for body parts in the first Message_Part; clients MUST recover from
+          this error by ignoring these mis-placed keys.</p>
+
+        <tp:rationale>
+          <p>Instead of representing messages as aa{sv} where the first
+            dictionary is special (a dictionary of headers), we could have
+            used a signature like (a{sv}aa{sv}) to separate out the headers
+            and the body parts.</p>
+
+          <p>However, this would make access to the messages more awkward.
+            In Python, the syntax for access to a header field would remain
+            <code>message[0]['message-type']</code>, but access to a body
+            field in the second body part would change from
+            <code>message[2]['content'] to message[1][1]['content']</code>. In
+            GLib, the message would change from being a
+            <code>GPtrArray(GHashTable)</code> to being a
+            <code>GValueArray(GHashTable, GPtrArray(GHashTable))</code> which
+            is rather inconvenient to dereference.</p>
+        </tp:rationale>
+
+        <p>In any group of parts with the same non-empty value for the
+          <tt>alternative</tt> key (which represent alternative versions of the
+          same content), more faithful versions of the intended message MUST
+          come before less faithful versions (note that this order is the
+          opposite of MIME <tt>multipart/alternative</tt> parts). Clients
+          SHOULD display the first alternative that they understand.</p>
+
+        <tp:rationale>
+          <p>Specifying the preference order means that if the underlying
+            protocol doesn't support alternatives, the CM can safely delete
+            everything apart from the first supported alternative when
+            sending messages.</p>
+
+          <p>The order is the reverse of MIME because MIME's rationale for
+            placing the "plainest" part first (legibility in pre-MIME UAs)
+            does not apply to us, and placing the most preferred part
+            first simplifies display (a client can iterate the message
+            in order, display the first alternative that it understands,
+            and skip displaying all subsequent parts with the same
+            "alternative" key).</p>
+        </tp:rationale>
+
+        <p>Clients SHOULD present all parts that are not redundant
+          alternatives in the order they appear in this array, possibly
+          excluding parts that are referenced by another displayed part.
+          It is implementation-specific how the parts are presented to the
+          user.</p>
+
+        <tp:rationale>
+          <p>This allows CMs to assume that all parts are actually shown to
+            the user, even if they are not explicitly referenced - we do
+            not yet recommend formatted text, and there is no way for
+            plain text to reference an attachment since it has no concept of
+            markup or references. This also forces clients to do something
+            sensible with messages that consist entirely of "attachments",
+            with no "body" at all.</p>
+
+          <p>For instance, when displaying the above example, a client that
+            understands the HTML part should display the JPEG image once,
+            between the two lines "Here is a photo of my cat:" and
+            "Isn't it cute?"; it may additionally present the image in some
+            way for a second time, after "Isn't it cute?", or may choose
+            not to.</p>
+
+          <p>A client that does not understand HTML, displaying the same
+            message, should display the plain-text part, followed by the JPEG
+            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
+          as:</p>
+
+          <pre>
+[
+  {
+    'message-token': '9de9546a-3400-4419-a505-3ea270cb834c',
+    'message-sender': 42,
+    'message-sent': 1210067943,
+    'message-received': 1210067947,
+    'message-type': 0,              # = Channel_Text_Message_Type_Normal
+    'pending-message-id': 437,
+  },
+  { 'alternative': 'main',
+    'content-type': 'text/html',
+    'content': 'Here is a photo of my cat:&lt;br /&gt;' +
+               '&lt;img src="cid:catphoto" alt="lol!" /&gt;' +
+               '&lt;br /&gt;Isn't it cute?',
+  },
+  { 'alternative': 'main',
+    'content-type': 'text/plain',
+    'content': 'Here is a photo of my cat:\n[IMG: lol!]\nIsn't it cute?',
+  },
+  { 'identifier': 'catphoto',
+    'content-type': 'image/jpeg',
+    'size': 101000,
+    'needs-retrieval': True,
+  },
+]</pre>
+
+        <p>telepathy-ring, Nokia's GSM connection manager, represents vCards
+          sent via SMS as:</p>
+
+        <pre>
+[
+  {
+    'message-token': '9de9546a-3400-4419-a505-3ea270cb834c',
+    'message-sender': 42,
+    'message-sent': 1210067943,
+    'message-received': 1210067947,
+    'message-type': 0,              # = Channel_Text_Message_Type_Normal
+    'pending-message-id': 437,
+  },
+  { 'content-type': 'text/x-vcard',
+    'content': [ 0x66, 0x69, 0x71, ...], # vCard data as an array of bytes
+  },
+]</pre>
+
+        <h3>Delivery reports</h3>
+
+        <div>
+          <p>Delivery reports are also represented as messages with the
+            <tt>message-type</tt> header mapping to
+            <tp:type>Channel_Text_Message_Type</tp:type> Delivery_Report.
+            Delivery reports SHOULD contain the <tt>message-sender</tt> header,
+            mapping to the intended recipient of the original message, if
+            possible; other headers specific to delivery reports are defined by
+            the <tp:type>Delivery_Report_Header_Key</tp:type> type. The second
+            and subsequent parts, if present, are a human-readable report from
+            the IM service.</p>
+
+          <p>The result of attempting to send delivery reports using
+            <tp:member-ref>SendMessage</tp:member-ref> is currently
+            undefined.</p>
+
+          <h4>Example delivery reports</h4>
+
+          <dl>
+            <dt>A minimal delivery report indicating permanent failure of the
+              sent message whose token was
+              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code> for an unknown
+              reason</dt>
+            <dd><pre>
+[{
+# header
+'message-sender': 123,
+'message-type': Channel_Text_Message_Type_Delivery_Report,
+'delivery-status': Delivery_Status_Permanently_Failed,
+'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
+}
+# no body
+]</pre></dd>
+
+            <dt>A delivery report where the failed message is echoed back to the
+              sender rather than being referenced by ID, and the failure reason
+              is that this protocol cannot send messages to offline contacts
+              such as the contact with handle 123</dt>
+            <dd><pre>
+[{ # header
+'message-sender': 123,
+'message-type': Channel_Text_Message_Type_Delivery_Report,
+'delivery-status': Delivery_Status_Temporarily_Failed,
+'delivery-error': Channel_Text_Send_Error_Offline,
+'delivery-echo':
+    [{ # header of original message
+    'message-sender': 1,
+    'message-sent': 1210067943,
+    },
+    { # body of original message
+    'content-type': 'text/plain',
+    'content': 'Hello, world!',
+    }]
+  ],
+
+# no body
+]</pre></dd>
+
+            <dt>A maximally complex delivery report: the server reports a
+              bilingual human-readable failure message because the user sent
+              a message "Hello, world!" with token
+              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code> to a contact
+              with handle 123, but that handle represents a contact who does not
+              actually exist</dt>
+            <dd><pre>
+[{ # header
+'message-sender': 123,
+'message-type': Channel_Text_Message_Type_Delivery_Report,
+'delivery-status': Delivery_Status_Permanently_Failed,
+'delivery-error': Channel_Text_Send_Error_Invalid_Contact,
+'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
+'delivery-echo':
+    [{ # header of original message
+    'message-sender': 1,
+    'message-sent': 1210067943,
+    },
+    { # body of original message
+    'content-type': 'text/plain',
+    'content': 'Hello, world!',
+    }]
+  ],
+},
+{ # message from server (alternative in English)
+'alternative': '404',
+'content-type': 'text/plain',
+'lang': 'en',
+'content': 'I have no contact with that name',
+},
+{ # message from server (alternative in German)
+'alternative': '404'.
+'content-type': 'text/plain',
+'lang': 'de',
+'content', 'Ich habe keinen Kontakt mit diesem Namen',
+}
+]</pre></dd>
+
+            <dt>A minimal delivery report indicating successful delivery
+              of the sent message whose token was
+              <code>b9a991bd-8845-4d7f-a704-215186f43bb4</code></dt>
+            <dd><pre>
+[{
+# header
+'message-sender': 123,
+'message-type': Channel_Text_Message_Type_Delivery_Report,
+'delivery-status': Delivery_Status_Delivered,
+'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4',
+}
+# no body
+]</pre></dd>
+
+          </dl>
+
+        </div>
+      </tp:docstring>
+
+      <tp:member name="Key" type="s">
         <tp:docstring>
-        The channel doesn't support sending text messages to the requested
-        contact
+          A key, which SHOULD be one of the well-known keys specified by
+          <tp:type>Message_Header_Key</tp:type>,
+          <tp:type>Message_Body_Key</tp:type> or
+          <tp:type>Delivery_Report_Header_Key</tp:type> if possible.
         </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
+      </tp:member>
 
-    <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:member name="Value" type="v">
         <tp:docstring>
-          The error that occurred
+          The value corresponding to the given key, which SHOULD be one of the
+          specified types for well-known keys.
         </tp:docstring>
-      </arg>
-      <arg name="Timestamp" type="u" tp:type="Unix_Timestamp">
+      </tp:member>
+    </tp:mapping>
+
+    <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
+          with the corresponding value types. Some keys make sense for both
+          incoming and outgoing messages, while others are only meaningful for
+          one or the other.</p>
+
+          <dl>
+            <dt>message-token (s -
+              <tp:type>Protocol_Message_Token</tp:type>)
+            </dt>
+            <dd>
+              <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, 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>
+
+            <dt>message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The time the message was sent (if unavailable, the time
+              it arrived at a central server MAY be used). Omitted if no
+              reasonable approximation is available; SHOULD always be present
+              on outgoing messages.</dd>
+
+            <dt>message-received (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The time the message was received locally. SHOULD always
+              be present.</dd>
+
+            <dt>message-sender (u - <tp:type>Contact_Handle</tp:type>)</dt>
+            <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. If empty or
+              omitted, the contact who sent the message could not be
+              determined.</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>
+
+            <dt>message-type (u - <tp:type>Channel_Text_Message_Type</tp:type>)
+            </dt>
+            <dd>The type of message; if omitted,
+              Channel_Text_Message_Type_Normal MUST be assumed. MAY
+              be omitted for normal chat messages.</dd>
+
+            <dt>supersedes (s – <tp:type>Protocol_Message_Token</tp:type>)</dt>
+            <dd>If present, this message supersedes a previous message,
+              identified by its <tt>message-token</tt> header. The user
+              interface MAY, for example, choose to replace the superseded
+              message with this message, or grey out the superseded message.
+
+              <tp:rationale>Skype, for example, allows the user to amend
+                messages they have already sent (to correct typos,
+                etc.).</tp:rationale>
+
+              Connection Managers SHOULD represent repeatedly edited messages
+              in the following form:
+              <pre>
+                message {token = a};
+                message {token = b, supersedes = a};
+                message {token = c, supersedes = a};
+              </pre>
+
+              <tp:rationale>The alternative form is:
+                <pre>
+                  message {token = a};
+                  message {token = b, supersedes = a};
+                  message {token = c, supersedes = b};
+                </pre>
+                but it is more difficult to implement in UIs/loggers, and it
+                breaks irrecoverably if message b is lost. If a CM is forced
+                to use this form, it should be tested extensively for
+                interoperability with existing clients.
+                </tp:rationale>
+
+              Clients should deal gracefully if the original message gets
+              lost, but one or more corrections to it get through:
+              <pre>
+                message {token = x} gets lost;
+                message {token = y, supersedes = x};
+                message {token = z, supersedes = x};
+              </pre>
+
+              <tp:rationale>This is the form that CMs will use to mean "I know
+                that this message was edited, but I don't know what it
+                originally said." It is often in the interests of the
+                remote side for message x to be lost (e.g. to hide
+                embarassing mistakes or sensitive information) so it might not
+                be possible to retrieve it (even on protocols with reliable
+                message-delivery guarantees).</tp:rationale></dd>
+
+            <dt>original-message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The <tt>message-sent</tt> header of the message that this
+              one supersedes.
+              This key should only be present if <tt>supersedes</tt> is also
+              present. It MAY be used as a hint to help clients locate the
+              original message in its logs. If present, comparing the tuple
+              (original-message-sent, supersedes) with (message-sent,
+              message-token) SHOULD be enough to uniquely
+              identify the original message.</dd>
+
+            <dt>original-message-received (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The <tt>message-received</tt> header of the message that this
+              one supersedes.
+              This key should only be present if <tt>supersedes</tt> is also
+              present. It MAY be used as a hint in a similar way to
+              <tt>original-message-sent</tt>.</dd>
+
+            <dt>pending-message-id (u - <tp:type>Message_ID</tp:type>)</dt>
+            <dd>The incoming message ID. This MUST NOT be present on outgoing
+              messages. Clients SHOULD NOT store this key - it is only valid
+              for as long as the message remains unacknowledged.</dd>
+
+            <dt>interface (s - <tp:type>DBus_Interface</tp:type>)</dt>
+            <dd>This message is specific to the given interface, which
+              is not Text. It SHOULD be ignored if that interface is
+              not supported. (Note that an 'interface' key can also
+              appear on the second and subsequent parts, where it
+              indicates that that part (only) should be ignored if
+              unsupported.)</dd>
+
+            <dt>scrollback (b)</dt>
+            <dd>If present and true, the incoming message was part of
+              a replay of message history. This flag does not make sense
+              on outgoing messages and SHOULD NOT appear there.</dd>
+
+            <dt>rescued (b)</dt>
+            <dd>If present and true, the incoming message has been seen in
+              a previous channel during the lifetime of the Connection,
+              but had not been acknowledged when that channel closed, causing
+              an identical channel (in which the message now appears) to open.
+              It does not make sense on outgoing messages, and SHOULD NOT
+              appear there.</dd>
+          </dl>
+
+      </tp:docstring>
+    </tp:simple-type>
+
+    <tp:simple-type type="s" name="Message_Body_Key">
+      <tp:added version="0.19.8"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Well-known keys for the second and subsequent
+          <tp:type>Message_Part</tp:type>s of a message, which contain the
+          message content, along with the corresponding value types.</p>
+
+          <dl>
+            <dt>identifier (s —
+              <tp:type>Protocol_Content_Identifier</tp:type>)</dt>
+            <dd>An opaque identifier for this part.
+              Parts of a message MAY reference other parts by treating
+              this identifier as if it were a MIME Content-ID and using
+              the cid: URI scheme.</dd>
+
+            <dt>alternative (s)</dt>
+            <dd>
+              <p>If present, this part of the message is an alternative for
+                all other parts with the same value for "alternative".
+                Clients SHOULD only display one of them (this is expected to
+                be used for XHTML messages in a future version of this
+                specification).</p>
+
+              <p>If omitted, this part is not an alternative for any other
+                part.</p>
+
+              <p>Parts of a message MAY reference the group of alternatives
+                as a whole (i.e. a reference to whichever of them is chosen)
+                by treating this identifier as if it were the MIME Content-ID
+                of a multipart/alternative part, and using the cid: URI
+                scheme.</p>
+            </dd>
+
+            <dt>content-type (s)</dt>
+            <dd>
+              <p>The MIME type of this part. See the documentation
+                for <tp:member-ref>MessageReceived</tp:member-ref> and
+                <tp:member-ref>MessageSent</tp:member-ref> for notes on the
+                special status of "text/plain" parts.</p>
+
+              <p>Connection managers MUST NOT signal parts without a
+                'content-type' key; if a protocol provides no way to determine
+                the MIME type, the connection manager is responsible for
+                guessing it, but MAY fall back to "text/plain" for text and
+                "application/octet-stream" for non-text.</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>
+            <dd>The natural language of this part, identified by a
+              RFC 3066 language tag.
+
+              <tp:rationale>
+                XMPP allows alternative-selection by language as well as
+                by content-type.
+              </tp:rationale>
+            </dd>
+
+            <dt>size (u)</dt>
+            <dd>The size in bytes (if needs-retrieval is true, this MAY be an
+              estimated or approximate size). SHOULD be omitted if 'content'
+              is provided.
+
+              <tp:rationale>
+                There's no point in providing the size if you're already
+                providing all the content.
+              </tp:rationale>
+            </dd>
+
+            <dt>thumbnail (b)</dt>
+            <dd>
+              <p>This part is a thumbnail. To represent an image together with
+                its thumbnail in a single message, there should be one part for
+                the full image followed by a part for the thumbnail (following
+                the “more complete versions first” requirement), with the same
+                'alternative' value. For example:</p>
+
+              <pre>
+[ ... ,
+  { 'alternative': 'catphoto',
+    'content-type': 'image/jpeg',
+    'size': 150000,
+    'content': [0xFF, 0xD8, ... 0xFF 0xD9],
+  },
+  { 'alternative': 'catphoto',
+    'content-type': 'image/jpeg'
+    'size': 1024,
+    'thumbnail': True,
+    'content': [0xFF, 0xD8, ... 0xFF 0xD9],
+  },
+  ...
+]</pre>
+            </dd>
+
+            <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 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 the now-deprecated
+                GetPendingMessageContent, 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 has been truncated
+              by the server or connection manager (equivalent to
+              Channel_Text_Message_Flag_Truncated in the Text interface).
+            </dd>
+
+            <dt>content (s or ay)</dt>
+            <dd>The part's content, if it is available and
+              sufficiently small to include here (implies that
+              'needs-retrieval' is false or omitted). Otherwise, omitted.
+              If the part is human-readable text or HTML, the value for this
+              key MUST be a UTF-8 string (D-Bus signature 's').
+              If the part is not text, the value MUST be a byte-array
+              (D-Bus signature 'ay'). If the part is a text-based format
+              that is not the main body of the message (e.g. an iCalendar
+              or an attached XML document), the value SHOULD be a UTF-8 string,
+              transcoding from another charset to UTF-8 if necessary, but
+              MAY be a byte-array (of unspecified character set) if
+              transcoding fails or the source charset is not known.</dd>
+
+              <!-- FIXME: "sufficiently small to include" is not currently
+              defined; we should add some API so clients can tell the
+                CM how large a message it should emit in the signal.-->
+
+            <dt>interface (s - <tp:type>DBus_Interface</tp:type>)</dt>
+            <dd>This part is specific to the given interface, which is
+              not Text. It SHOULD be ignored if that interface is not
+              supported. (Note that an 'interface' key can also appear
+              on the first part, where it indicates that the entire
+              message should be ignored if unsupported.)</dd>
+          </dl>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <tp:simple-type type="s" name="Delivery_Report_Header_Key">
+      <tp:added version="0.19.8"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Well-known keys for the first <tp:type>Message_Part</tp:type> of a
+          delivery report, along with the corresponding value types. Some of
+          these are special-cases of headers defined by
+          <tp:type>Message_Header_Key</tp:type>.</p>
+
+          <dl>
+            <dt>message-sender (u - <tp:type>Contact_Handle</tp:type>, as
+              defined by <tp:type>Message_Header_Key</tp:type>)</dt>
+            <dd>MUST be the intended recipient of the original message, if
+              available (zero or omitted if the intended recipient is
+              unavailable or is not a contact, e.g. a chatroom), even if the
+              delivery report actually came from an intermediate server.</dd>
+
+            <dt>message-type (u - <tp:type>Channel_Text_Message_Type</tp:type>,
+              as defined by <tp:type>Message_Header_Key</tp:type>)</dt>
+            <dd>MUST be Channel_Text_Message_Type_Delivery_Report.</dd>
+
+            <dt>delivery-status (u - <tp:type>Delivery_Status</tp:type>)</dt>
+            <dd>The status of the message. All delivery reports MUST contain
+              this key in the first Message_Part.</dd>
+
+            <dt>delivery-token (s - <tp:type>Protocol_Message_Token</tp:type>)</dt>
+
+            <dd>
+              <p>An identifier for the message to which this delivery report
+                refers. MUST NOT be an empty string. Omitted if not
+                available.</p>
+
+              <p>Clients may match this against the token produced by the
+                SendMessage method and MessageSent signal. A status report
+                with no token could match any sent message, and a sent
+                message with an empty token could match any status report.
+                If multiple sent messages match, clients SHOULD use some
+                reasonable heuristic.</p>
+
+              <tp:rationale>
+                In an ideal world, we could unambiguously match reports
+                against messages; however, deployed protocols are not ideal,
+                and not all reports and messages can be matched.
+              </tp:rationale>
+            </dd>
+
+            <dt>delivery-error (u -
+              <tp:type>Channel_Text_Send_Error</tp:type>)</dt>
+            <dd>
+              The reason for the failure. MUST be omitted if this was a
+              successful delivery; SHOULD be omitted if it would be
+              Channel_Text_Send_Error_Unknown.
+            </dd>
+
+            <dt>delivery-dbus-error (s -
+              <tp:type>DBus_Error_Name</tp:type>)</dt>
+            <dd>
+              The reason for the failure, specified as a (possibly
+              implementation-specific) D-Bus error. MUST be omitted if this was
+              a successful delivery. If set, the 'delivery-error' key SHOULD be
+              set to the closest available value.
+            </dd>
+
+            <dt>delivery-error-message (s)</dt>
+            <dd>
+              Debugging information on why the message could not be delivered.
+              MUST be omitted if this was a successful delivery; MAY always be
+              omitted.
+            </dd>
+
+            <dt>delivery-echo (aa{sv} - <tp:type>Message_Part[]</tp:type>)</dt>
+            <dd>
+              <p>The message content which can be omitted if no content
+                is available. Content MAY have been truncated, message
+                parts MAY have been removed, and message parts MAY
+                have had their content removed (i.e. the message part
+                metadata is present, but the 'content' key is
+                not).</p>
+
+              <tp:rationale>
+                Some protocols, like XMPP, echo the failing message back to
+                the sender. This is sometimes the only way to match it
+                against the sent message, so we include it here.
+              </tp:rationale>
+            </dd>
+
+          </dl>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <tp:simple-type type="s" name="Protocol_Message_Token"
+                    array-name="Protocol_Message_Token_List">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>An opaque token used to identify messages in the underlying.
+          protocol. As a special case, the empty string indicates that there
+          is no particular identification for a message.</p>
+
+        <p>CM implementations SHOULD use an identifier expected to be unique,
+          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
+          byte), and some implementations send non-unique identifiers (some
+          XMPP clients use very simple message IDs, such as an incrementing
+          integer that resets to 1 at the beginning of each connection). As a
+          result, clients MUST NOT assume that protocol tokens will not be
+          re-used.</p>
+
+        <p>In particular, clients SHOULD use a heuristic to assign delivery
+          reports to messages, such as matching on message content or
+          timestamp (if available), or assuming that the delivery report
+          refers to the most recent message with that ID.</p>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <tp:simple-type name="Protocol_Content_Identifier" type="s">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A protocol-specific identifier for a blob of content, as used for
+          the <tt>identifier</tt> key in a <tp:type>Message_Part</tp:type>. The
+          same identifier MAY be re-used if the same content, byte-for-byte,
+          appears as a part of several messages.</p>
+
+        <tp:rationale>
+          <p>On XMPP, these identifiers might be Content-IDs for custom
+            smileys implemented using <a
+              href="http://xmpp.org/extensions/xep-0231.html">XEP-0232 Bits of
+            Binary</a>; the same smiley might well appear in multiple
+            messages.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </tp:simple-type>
+
+    <method name="SendMessage" tp:name-for-bindings="Send_Message">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Submit a message to the server for sending.
+          If this method returns successfully, the message has been submitted
+          to the server and the <tp:member-ref>MessageSent</tp:member-ref>
+          signal is emitted.</p>
+
+        <p>This method MUST return before the MessageSent signal is
+          emitted.</p>
+
+        <tp:rationale>
+          <p>This means that the process sending the message is the first
+            to see the <tp:type>Protocol_Message_Token</tp:type>, and can
+            relate the message to the corresponding
+            <tp:member-ref>MessageSent</tp:member-ref> signal by comparing
+            message tokens (if supported by the protocol).</p>
+        </tp:rationale>
+
+        <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:value-ref type="Channel_Text_Message_Type">Delivery_Report</tp:value-ref>.
+          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 Unix timestamp indicating when the message was sent
+          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 name="Type" type="u" tp:type="Channel_Text_Message_Type">
+      <arg direction="in" name="Flags" type="u"
+        tp:type="Message_Sending_Flags">
         <tp:docstring>
-          The message type
+          Flags affecting how the message is sent. The channel MAY ignore some
+          or all flags, depending on
+          <tp:member-ref>DeliveryReportingSupport</tp:member-ref>; the flags
+          that were handled by the CM are provided in
+          <tp:member-ref>MessageSent</tp:member-ref>.
         </tp:docstring>
       </arg>
-      <arg name="Text" type="s">
+
+      <arg direction="out" type="s" tp:type="Protocol_Message_Token"
+        name="Token">
         <tp:docstring>
-          The text of the message
+          An opaque token used to match any incoming delivery or failure
+          reports against this message, or an empty string if the message
+          is not readily identifiable.
         </tp:docstring>
       </arg>
+
+      <tp:possible-errors>
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
+          <tp:docstring>
+            The requested message is malformed and cannot be sent.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+      </tp:possible-errors>
+    </method>
+
+    <tp:flags name="Message_Sending_Flags" value-prefix="Message_Sending_Flag"
+      type="u">
+      <tp:docstring>
+        Flags altering the way a message is sent. The "most usual" action
+        should always be to have these flags unset. Some indication of which
+        flags are supported is provided by the
+        <tp:member-ref>DeliveryReportingSupport</tp:member-ref> property.
+      </tp:docstring>
+
+      <tp:flag suffix="Report_Delivery" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Provide a successful delivery report if possible, even if this is
+            not the default for this protocol. Ignored if delivery reports are
+            not possible on this protocol.</p>
+
+          <tp:rationale>
+            <p>In some protocols, like XMPP, it is not conventional to request
+              or send positive delivery notifications.</p>
+          </tp:rationale>
+
+          <p>Delivery failure reports SHOULD always be sent, but if this flag
+            is present, the connection manager MAY also try harder to obtain
+            failed delivery reports or allow them to be matched to outgoing
+            messages.</p>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Report_Read" value="2">
+        <tp:added version="0.19.9"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Provide a delivery report when the message is read by the
+            recipient, even if this is not the default for this protocol.
+            Ignored if read reports are not possible on this protocol.</p>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Report_Deleted" value="4">
+        <tp:added version="0.19.9"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Provide a delivery report when the message is deleted by the
+            recipient, even if this is not the default for this protocol.
+            Ignored if such reports are not possible on this protocol.</p>
+        </tp:docstring>
+      </tp:flag>
+    </tp:flags>
+
+    <signal name="MessageSent" tp:name-for-bindings="Message_Sent">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Signals that an outgoing message has failed to send. The error
-          will be one of the values from ChannelTextSendError.</p>
+        <p>Signals that a message has been submitted for sending.</p>
 
-        <p>This signal should only be emitted for messages for which
-          <tp:member-ref>Sent</tp:member-ref> has already been emitted and
-          <tp:member-ref>Send</tp:member-ref> has already returned success.</p>
+        <p>This SHOULD be emitted as soon as the CM determines it's
+          theoretically possible to send the message (e.g. the parameters are
+          supported and correct).</p>
+
+        <tp:rationale>
+          <p>This signal allows a process that is not the caller of
+            SendMessage to log sent messages.</p>
+        </tp:rationale>
       </tp:docstring>
-      <tp:changed version="0.17.3">older spec versions claimed that SendError
-        was emitted <em>instead of</em> Sent, rather than <em>in addition
-        to</em> Sent. However, the 0.17.3+ semantics were what we'd always
-        actually implemented.</tp:changed>
-    </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
+      <arg type="aa{sv}" tp:type="Message_Part[]" name="Content">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The message content (see <tp:type>Message_Part</tp:type> for full
+            details). If the message that was passed to
+            <tp:member-ref>SendMessage</tp:member-ref> has a formatted text
+            part that the connection manager recognises, but no
+            <tt>text/plain</tt> alternative, the CM MUST use the formatted text
+            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
+            argument to SendMessage (if the message is truncated,
+            formatting or alternatives are dropped, etc., then the edited
+            version SHOULD appear in this signal).</p>
         </tp:docstring>
       </arg>
-      <arg name="Type" type="u" tp:type="Channel_Text_Message_Type">
+
+      <arg name="Flags" type="u" tp:type="Message_Sending_Flags">
         <tp:docstring>
-          The message type (normal, action, notice, etc) from
-          ChannelTextMessageType
+          <p>Flags affecting how the message was sent.  The flags might be a
+            subset of those passed to SendMessage if the caller requested
+            unsupported flags.</p>
         </tp:docstring>
       </arg>
-      <arg name="Text" type="s">
+
+      <arg name="Message_Token" type="s" tp:type="Protocol_Message_Token">
         <tp:docstring>
-          The text of the message. If the message was, or will be, altered
-          during transmission, this argument SHOULD reflect what other
-          contacts will receive rather than being a copy of the argument
-          to <tp:member-ref>Send</tp:member-ref>.
+          An opaque token used to match any incoming delivery or failure
+          reports against this message, or an empty string if the message
+          is not readily identifiable.
         </tp:docstring>
       </arg>
+    </signal>
+
+    <property name="PendingMessages" type="aaa{sv}" access="read"
+      tp:type="Message_Part[][]" tp:name-for-bindings="Pending_Messages">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Signals that a message has been submitted for sending.</p>
+        <p>A list of incoming messages that have neither been acknowledged nor
+          rejected. Its items can be removed using
+          <tp:member-ref>AcknowledgePendingMessages</tp:member-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>
+
+    <signal name="PendingMessagesRemoved"
+      tp:name-for-bindings="Pending_Messages_Removed">
+      <tp:docstring>
+        The messages with the given IDs have been removed from the
+        <tp:member-ref>PendingMessages</tp:member-ref> list. Clients SHOULD NOT
+        attempt to acknowledge those messages.
+
+        <tp:rationale>
+          This completes change notification for the PendingMessages property
+          (previously, there was change notification when pending messages
+          were added, but not when they were removed).
+        </tp:rationale>
       </tp:docstring>
+
+      <arg name="Message_IDs" type="au" tp:type="Message_ID[]">
+        <tp:docstring>
+          The messages that have been removed from the pending message list.
+        </tp:docstring>
+      </arg>
     </signal>
 
-    <tp:enum name="Channel_Text_Message_Type" type="u"
-      array-name="Channel_Text_Message_Type_List">
+    <signal name="MessageReceived" tp:name-for-bindings="Message_Received">
       <tp:docstring>
-        The type of message.
+        Signals that a message has been received and added to the pending
+        messages queue.
       </tp:docstring>
 
-      <tp:enumvalue suffix="Normal" value="0">
+      <arg type="aa{sv}" tp:type="Message_Part[]" name="Message">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The message content, including any attachments or alternatives. If
+            the incoming message contains formatted text without a plain text
+            alternative, the connection manager MUST generate a
+            <tt>text/plain</tt> alternative from the formatted text, and
+            include it in this message (both here, and in the
+            <tp:member-ref>PendingMessages</tp:member-ref> property).</p>
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:enum name="Delivery_Status" value-prefix="Delivery_Status"
+      plural="Delivery_Statuses" type="u">
+      <tp:docstring>
+        <p>The status of a message as indicated by a delivery report.</p>
+
+        <p>If this enum is extended in future specifications, this should
+          only be to add new, non-overlapping conditions (i.e. all failures
+          should still be signalled as either Temporarily_Failed
+          or Permanently_Failed). If additional detail is required (e.g.
+          distinguishing between the various types of permanent failure) this
+          will be done using additional
+          <tp:type>Delivery_Report_Header_Key</tp:type>s.</p>
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value="0">
         <tp:docstring>
-        An ordinary chat message. Unknown types SHOULD be treated like this.
+          The message's disposition is unknown.
+          Clients SHOULD consider all messages to have status
+          Delivery_Status_Unknown unless otherwise specified; connection
+          managers SHOULD NOT signal this delivery status explicitly.
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Action" value="1">
+      <tp:enumvalue suffix="Delivered" value="1">
         <tp:docstring>
-        An action which might be presented to the user as
-        "* &lt;sender&gt; &lt;action&gt;", such as an IRC CTCP
-        ACTION (typically selected by the "/me" command). For example, the
-        text of the message might be "drinks more coffee".
+          The message has been delivered to the intended recipient.
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Notice" value="2">
+      <tp:enumvalue suffix="Temporarily_Failed" value="2">
         <tp:docstring>
-        A one-off or automated message not necessarily expecting a reply
+          Delivery of the message has failed. Clients SHOULD notify the user,
+          but MAY automatically try sending another copy of the message.
+
+          <tp:rationale>
+            Similar to errors with type="wait" in XMPP; analogous to
+            4xx errors in SMTP.
+          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Auto_Reply" value="3">
+      <tp:enumvalue suffix="Permanently_Failed" value="3">
         <tp:docstring>
-        An automatically-generated reply message.
+          Delivery of the message has failed. Clients SHOULD NOT try again
+          unless by specific user action. If the user does not modify the
+          message or alter configuration before re-sending, this error is
+          likely to happen again.
+
+          <tp:rationale>
+            Similar to errors with type="cancel", type="modify"
+            or type="auth" in XMPP; analogous to 5xx errors in SMTP.
+          </tp:rationale>
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Delivery_Report" value="4">
+      <tp:enumvalue suffix="Accepted" value="4">
         <tp:docstring>
-          A delivery report. This message type MUST NOT appear unless the
-          channel supports the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Messages</tp:dbus-ref>
-          interface; see <tp:type>Message_Part</tp:type> for the format that
-          delivery reports must take.
+          An intermediate server has accepted the message but the message
+          has not been yet delivered to the ultimate recipient. The
+          connection manager might send a Failed report or Delivered report
+          later.
+
+          <tp:rationale>
+            Similar to "202 Accepted" success code in SIP; analogous to
+            251 and 252 responses in SMTP.
+          </tp:rationale>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Read" value="5">
+        <tp:added version="0.19.9"/>
+        <tp:docstring>
+          The message has been read by the intended recipient.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Deleted" value="6">
+        <tp:added version="0.19.9"/>
+        <tp:docstring>
+          The message has been deleted by the intended recipient. This MAY be
+          signalled on its own if the message is deleted without being read, or
+          after <code>Read</code> if the message was read before being deleted.
         </tp:docstring>
       </tp:enumvalue>
     </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:flags name="Delivery_Reporting_Support_Flags"
+      value-prefix="Delivery_Reporting_Support_Flag" type="u">
+      <tp:docstring>
+        Flags indicating the level of support for delivery reporting on this
+        channel, as found on the
+        <tp:member-ref>DeliveryReportingSupport</tp:member-ref> property. Any
+        future flags added to this set will conform to the
+        convention that the presence of an extra flag implies that
+        more operations will succeed. Note that CMs may always provide more
+        reports than are requested in the
+        <tp:type>Message_Sending_Flags</tp:type> passed to
+        <tp:member-ref>SendMessage</tp:member-ref>.
+
+        <tp:rationale>
+          If senders want delivery reports, they should ask for them.  If they
+          don't want delivery reports, they can just ignore them, so there's no
+          need to have capability discovery for what will happen if a delivery
+          report isn't requested.
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:flag suffix="Receive_Failures" value="1">
         <tp:docstring>
-        The incoming message was truncated to a shorter length by the
-        server or the connection manager.
+          Clients MAY expect to receive negative delivery reports if
+          Message_Sending_Flag_Report_Delivery is specified when sending.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Non_Text_Content" value="2">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The incoming message contained non-text content which cannot be
-            represented by this interface, but has been signalled
-            in the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">Messages</tp:dbus-ref>
-            interface.</p>
-
-          <p>Connection managers SHOULD only set this flag if the non-text
-            content appears to be relatively significant (exactly how
-            significant is up to the implementor). The intention is that
-            if this flag is set, clients using this interface SHOULD inform
-            the user that part of the message was not understood.</p>
+      <tp:flag suffix="Receive_Successes" value="2">
+        <tp:docstring>
+          Clients MAY expect to receive positive delivery reports if
+          Message_Sending_Flag_Report_Delivery is specified when sending.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Scrollback" value="4">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The incoming message was part of a replay of message history.</p>
-
-          <tp:rationale>
-            <p>In XMPP multi-user chat, a few past messages are replayed
-              when you join a chatroom. A sufficiently capable IRC connection
-              manager could also set this flag on historical messages when
-              connected to a proxy like bip or irssi-proxy. The existence
-              of this flag allows loggers and UIs to use better heuristics
-              when eliminating duplicates (a simple implementation made
-              possible by this flag would be to avoid logging scrollback
-              at all).</p>
-          </tp:rationale>
+      <tp:flag suffix="Receive_Read" value="4">
+        <tp:added version="0.19.9"/>
+        <tp:docstring>
+          Clients MAY expect to receive <tp:type>Delivery_Status</tp:type>
+          <code>Read</code> reports if Message_Sending_Flag_Report_Read
+          is specified when sending.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Rescued" value="8">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The incoming message has been seen in a previous channel during
-            the lifetime of the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>, but
-            had not been acknowledged
-            when that channel closed, causing an identical channel (the
-            channel in which the message now appears) to open.</p>
-
-          <tp:rationale>
-            <p>This means that a logger (which should already have seen the
-              message in the previous channel) is able to recognise and ignore
-              these replayed messages.</p>
-          </tp:rationale>
+      <tp:flag suffix="Receive_Deleted" value="8">
+        <tp:added version="0.19.9"/>
+        <tp:docstring>
+          Clients MAY expect to receive <tp:type>Delivery_Status</tp:type>
+          <code>Deleted</code> reports if Message_Sending_Flag_Report_Deleted
+          is specified when sending.
         </tp:docstring>
       </tp:flag>
     </tp:flags>
 
+    <property name="DeliveryReportingSupport" access="read"
+      tp:type="Delivery_Reporting_Support_Flags" type="u"
+      tp:name-for-bindings="Delivery_Reporting_Support"
+      tp:immutable="yes">
+      <tp:docstring>
+        A bitfield indicating features supported by this channel.
+      </tp:docstring>
+    </property>
+
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <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>
+        more general messages, including:</p>
+
+      <ul>
+        <li>messages with attachments (like MIME multipart/mixed)</li>
+        <li>groups of alternatives (like MIME multipart/alternative)</li>
+        <li>delivery reports, adding support for protocols where the
+          message content is not echoed back to the sender on failure
+          and for receiving positive acknowledgements, as well as
+          ensuring that incoming delivery reports are not lost if no
+          client is handling the channel yet;</li>
+        <li>any extra types of message we need in future</li>
+      </ul>
 
-      <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>Incoming messages, outgoing messages, and delivery reports are all
+        represented as lists of <tp:type>Message_Part</tp:type> structures,
+        with a format reminiscent of e-mail.</p>
 
       <p>When a message is received, an identifier is assigned and a
-        <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.
+        <tp:member-ref>MessageReceived</tp:member-ref> signal emitted,
+        and the message is placed in a pending queue represented by the
+        <tp:member-ref>PendingMessages</tp:member-ref> property.
         When the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+          namespace="im.telepathy1.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>
+        lifetime of the channel. Only the <tp:dbus-ref
+          namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
+        for a channel should acknowledge messages; <tp:dbus-ref
+          namespace="im.telepathy1.Client">Observer</tp:dbus-ref>s
+        (such as loggers) and <tp:dbus-ref
+          namespace="im.telepathy1.Client">Approver</tp:dbus-ref>s
+        for the channel may listen for incoming messages, and send
+        messages of their own, but SHOULD NOT acknowledge messages.</p>
+
+      <tp:rationale>
+        <p>If observers were allowed to acknowledge messages, then messages
+          might have been acknowledged before the handler even got to see the
+          channel, and hence could not be shown to the user.</p>
+      </tp:rationale>
 
       <p>Sending messages can be requested using the
-        <tp:dbus-ref namespace="ofdT.Channel.Interface.Messages"
-          >SendMessage</tp:dbus-ref> method, which will return
+        <tp:member-ref>SendMessage</tp:member-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>
+        is received in the same way as an incoming message. Outgoing
+        messages are announced to other clients which may be
+        interested in the channel by the
+        <tp:member-ref>MessageSent</tp:member-ref> signal.</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>
+        <tp:dbus-ref namespace="imt1.Channel">TargetHandleType</tp:dbus-ref>
         is <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. The
         expected way to request such a channel is to set the <tp:dbus-ref
-        namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>, <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>,
+        namespace='imt1.Channel'>ChannelType</tp:dbus-ref>, <tp:dbus-ref
+        namespace='imt1.Channel'>TargetHandleType</tp:dbus-ref>,
         and either <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref> or <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetID</tp:dbus-ref> in a call to
+        namespace='imt1.Channel'>TargetHandle</tp:dbus-ref> or <tp:dbus-ref
+        namespace='imt1.Channel'>TargetID</tp:dbus-ref> in a call to
         <tp:dbus-ref
-        namespace='ofdT.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>.</p>
+        namespace='imt1.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>.</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:dbus-ref
-        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
+        namespace="imt1.Channel">TargetHandleType</tp:dbus-ref> =
         <tp:value-ref type="Handle_Type">Room</tp:value-ref> and the
-        <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Channel.Interface">Group1</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>
+        <tp:dbus-ref namespace="imt1.Channel.Interface">Conference1</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 <tp:dbus-ref
-        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = <tp:value-ref
+        namespace="imt1.Channel">TargetHandleType</tp:dbus-ref> = <tp:value-ref
         type="Handle_Type">None</tp:value-ref> (and hence <tp:dbus-ref
-        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> = 0),
-        <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        namespace="imt1.Channel">TargetHandle</tp:dbus-ref> = 0),
+        <tp:dbus-ref namespace="imt1.Channel.Interface">Group1</tp:dbus-ref>
         interface, and optionally the
-        <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Channel.Interface">Conference1</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 <tp:dbus-ref
-        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
+        namespace="imt1.Channel">TargetHandleType</tp:dbus-ref> =
         <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. 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
+          namespace="imt1.Channel.Interface">Conference1</tp:dbus-ref> channel
         with the one-to-one channel in its <tp:dbus-ref
-          namespace="ofdT.Channel.Interface.Conference"
+          namespace="imt1.Channel.Interface.Conference1"
           >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
@@ -540,12 +1494,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         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>
+          namespace="imt1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
         signal. The new channel should resemble the old channel, but have
-        <tp:dbus-ref namespace='ofdT.Channel'>Requested</tp:dbus-ref> = FALSE
+        <tp:dbus-ref namespace='imt1.Channel'>Requested</tp:dbus-ref> = FALSE
         regardless of its previous value; the <tp:dbus-ref
-        namespace='ofdT.Channel'>InitiatorHandle</tp:dbus-ref>
-        and <tp:dbus-ref namespace='ofdT.Channel'>InitiatorID</tp:dbus-ref>
+        namespace='imt1.Channel'>InitiatorHandle</tp:dbus-ref>
+        and <tp:dbus-ref namespace='imt1.Channel'>InitiatorID</tp:dbus-ref>
         should correspond to the sender of one of the pending
         messages.</p>
 
@@ -584,7 +1538,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:rationale>
 
       <p>As a result, Text channels SHOULD implement <tp:dbus-ref
-          namespace="ofdT">Channel.Interface.Destroyable</tp:dbus-ref>.</p>
+          namespace="imt1">Channel.Interface.Destroyable1</tp:dbus-ref>.</p>
 
       <tp:rationale>
         <p>This "respawning" behaviour becomes problematic if there is no
@@ -604,10 +1558,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
       <p>Opaquely-named rejoinable chatrooms (such as Skype rooms) are
         represented using the properties in the <tp:dbus-ref
-        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        namespace="imt1.Channel.Interface">Room1</tp:dbus-ref>
         interface. Instructions and examples of how to request
         such channels are given in said interface's description.</p>
 
+      <p>Although this specification supports formatted (rich-text)
+        messages with unformatted alternatives, implementations SHOULD NOT
+        attempt to send formatted messages until the Telepathy specification
+        has also been extended to cover capability discovery for message
+        formatting.</p>
+
+      <tp:rationale>
+        We intend to expose all rich-text messages as XHTML-IM, but on some
+        protocols, formatting is an extremely limited subset of that format
+        (e.g. there are protocols where foreground/background colours, font
+        and size can be set, but only for entire messages).
+        Until we can tell UIs what controls to offer to the user, it's
+        unfriendly to offer the user controls that may have no effect.
+      </tp:rationale>
     </tp:docstring>
   </interface>
 </node>
diff --git a/spec/Channel_Type_Tubes.xml b/spec/Channel_Type_Tubes.xml
deleted file mode 100644
index c0a973fa..00000000
--- a/spec/Channel_Type_Tubes.xml
+++ /dev/null
@@ -1,615 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Type_Tubes" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>
-    Copyright © 2007-2009 Collabora Limited
-  </tp:copyright>
-  <tp:license>
-    This library is free software; you can redistribute it and/or
-modify it under the terms of the GNU Lesser General Public
-License as published by the Free Software Foundation; either
-version 2.1 of the License, or (at your option) any later version.
-
-This library is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-Lesser General Public License for more details.
-
-You should have received a copy of the GNU Lesser General Public
-License along with this library; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-  </tp:license>
-  <interface name="org.freedesktop.Telepathy.Channel.Type.Tubes">
-
-    <tp:deprecated version="0.17.25">Client implementations
-      SHOULD use <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Type">StreamTube</tp:dbus-ref> and
-        <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Type">DBusTube</tp:dbus-ref>
-      instead.</tp:deprecated>
-
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A "tube" is a mechanism for arbitrary data transfer. Two types of
-        data transfer are currently specified: D-Bus messages, and streams of
-        bytes. Each tube has a service name, which is a string specifying the
-        kind of communication that takes place over it, and a dictionary of
-        arbitrary parameters. Tube parameters are commonly used for bootstrap
-        information such as usernames and passwords. Each tube is identified
-        by a locally unique identifier.</p>
-
-       <p>The Tubes channel type may be requested for handles of type
-         HANDLE_TYPE_CONTACT and HANDLE_TYPE_ROOM.</p>
-
-       <p>Stream tubes specify listening addresses using pairs of parameters
-         with signature 'u', 'v', where the integer 'u' is a member of
-         Socket_Address_Type and the v is dependent on the type of address.</p>
-    </tp:docstring>
-
-    <tp:simple-type name="Tube_ID" type="u">
-      <tp:docstring>An identifier for a tube. These are local to a Tubes
-        channel, and may not be assumed to be the same as the other
-        participants' idea of the tube identifier.</tp:docstring>
-    </tp:simple-type>
-
-    <tp:struct name="Tube_Info" array-name="Tube_Info_List">
-      <tp:docstring>A struct (tube ID, initiator handle, tube type,
-        service name, parameters, state) representing a tube, as returned
-        by ListTubes on the Tubes channel type.</tp:docstring>
-      <tp:member type="u" tp:type="Tube_ID" name="Identifier"/>
-      <tp:member type="u" tp:type="Contact_Handle" name="Initiator"/>
-      <tp:member type="u" tp:type="Tube_Type" name="Type"/>
-      <tp:member type="s" name="Service"/>
-      <tp:member type="a{sv}" tp:type="String_Variant_Map" name="Parameters"/>
-      <tp:member type="u" tp:type="Tube_State" name="State"/>
-    </tp:struct>
-
-    <tp:struct name="DBus_Tube_Member" array-name="DBus_Tube_Member_List">
-      <tp:docstring>Represents a participant in a multi-user D-Bus tube, as
-        returned by <tp:member-ref>GetDBusNames</tp:member-ref> and seen in the
-        <tp:member-ref>DBusNamesChanged</tp:member-ref> signal.</tp:docstring>
-      <tp:member type="u" tp:type="Contact_Handle" name="Handle">
-        <tp:docstring>
-          The handle of a participant in this D-Bus tube.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" tp:type="DBus_Unique_Name" name="Unique_Name">
-        <tp:docstring>
-          That participant's unique name.
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:enum name="Tube_Type" type="u" array-name="Tube_Type_List">
-      <tp:enumvalue suffix="DBus" value="0">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The tube is D-Bus tube as described by the
-            org.freedesktop.Telepathy.Channel.Type.DBusTube interface.</p>
-        </tp:docstring>
-      </tp:enumvalue>
-
-      <tp:enumvalue suffix="Stream" value="1">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The tube is stream tube as described by the
-            org.freedesktop.Telepathy.Channel.Type.StreamTube interface.</p>
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:enum name="Tube_State" type="u">
-      <tp:enumvalue suffix="Local_Pending" value="0">
-        <tp:docstring>
-          The tube is waiting to be accepted/closed locally.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Remote_Pending" value="1">
-        <tp:docstring>
-          The tube is waiting to be accepted/closed remotely.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Open" value="2">
-        <tp:docstring>
-          The tube is open for traffic.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <tp:mapping name="Supported_Socket_Map">
-      <tp:docstring>The supported socket address and access-control types
-        for tubes. See GetAvailableStreamTubeTypes.</tp:docstring>
-      <tp:member name="Address_Type" type="u" tp:type="Socket_Address_Type"/>
-      <tp:member name="Access_Control" type="au"
-        tp:type="Socket_Access_Control[]"/>
-    </tp:mapping>
-
-    <method name="GetAvailableStreamTubeTypes"
-      tp:name-for-bindings="Get_Available_Stream_Tube_Types">
-      <tp:docstring>List the available address types and access-control types
-        for stream tubes.</tp:docstring>
-      <arg direction="out" type="a{uau}" tp:type="Supported_Socket_Map"
-        name="Available_Stream_Tube_Types">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>A mapping from address types (members of Socket_Address_Type) to
-          arrays of access-control type (members of Socket_Access_Control)
-          that the connection manager supports for stream tubes with that
-          address type. For simplicity, if a CM supports offering a
-          particular type of tube, it is assumed to support accepting it.</p>
-
-          <p>A typical value for a host without IPv6 support:</p>
-
-          <pre>
-            {
-              Socket_Address_Type_IPv4:
-                [Socket_Access_Control_Localhost, Socket_Access_Control_Port,
-                 Socket_Access_Control_Netmask],
-              Socket_Address_Type_Unix:
-                [Socket_Access_Control_Localhost, Socket_Access_Control_Credentials]
-            }
-          </pre>
-
-          <p>If stream tubes are not supported, this will be an empty
-            dictionary.</p>
-        </tp:docstring>
-      </arg>
-    </method>
-
-    <method name="GetAvailableTubeTypes"
-      tp:name-for-bindings="Get_Available_Tube_Types">
-      <arg direction="out" type="au" tp:type="Tube_Type[]"
-        name="Available_Tube_Types">
-        <tp:docstring>
-          An array of the available tube types, as defined by the Tube_Type
-          enum.
-        </tp:docstring>
-      </arg>
-    </method>
-
-    <method name="ListTubes" tp:name-for-bindings="List_Tubes">
-      <arg direction="out" type="a(uuusa{sv}u)" tp:type="Tube_Info[]"
-        name="Tubes">
-        <tp:docstring>
-         Return an array of tuples, each representing a tube, with the
-         following members:
-
-         <ul>
-           <li>the tube's ID</li>
-           <li>the tube's initiator</li>
-           <li>the tube's type</li>
-           <li>the tube's service</li>
-           <li>the tube's parameters</li>
-           <li>the tube's state</li>
-         </ul>
-        </tp:docstring>
-      </arg>
-    </method>
-
-    <!-- this tp:name-for-bindings is ugly, but compatible with
-    the code generation in telepathy-glib versions that did not use
-    tp:name-for-bindings -->
-    <method name="OfferDBusTube" tp:name-for-bindings="Offer_D_Bus_Tube">
-      <tp:docstring>
-        Offers a D-Bus tube providing the service specified.
-      </tp:docstring>
-      <arg direction="in" name="Service" type="s">
-        <tp:docstring>
-          A string representing the service name that will be used over the
-          tube.
-          It should be a well-known D-Bus service name, of the form
-          com.example.ServiceName.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Parameters" type="a{sv}"
-        tp:type="String_Variant_Map">
-        <tp:docstring>
-          A dictionary of properties for the new tube; the allowable keys,
-          types and values are defined by the service. Connection managers
-          must support the value being any primitive (non-container)
-          D-Bus type, or a byte array 'ay'.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="u" tp:type="Tube_ID" name="Tube_ID">
-        <tp:docstring>
-          The ID of the new tube.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The contact associated with this channel doesn't have tubes
-            capabilities.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The connection manager doesn't support D-Bus tubes.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="OfferStreamTube" tp:name-for-bindings="Offer_Stream_Tube">
-      <tp:docstring>
-        Offer a stream tube exporting the local socket specified.
-      </tp:docstring>
-      <arg direction="in" name="Service" type="s">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          A string representing the service name that will be used over the
-          tube.
-          It should be a well-known TCP service name as defined by
-          <a href="http://www.iana.org/assignments/port-numbers">
-            http://www.iana.org/assignments/port-numbers</a> or
-          <a href="http://www.dns-sd.org/ServiceTypes.html">
-            http://www.dns-sd.org/ServiceTypes.html</a>, for instance
-          "rsync" or "daap".
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Parameters" type="a{sv}"
-        tp:type="String_Variant_Map">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>A dictionary of properties for the new tube; the allowable keys,
-          types and values are defined by the service. Connection managers
-          must support the value being any primitive (non-container)
-          D-Bus type, or a byte array 'ay'.</p>
-          <p>These should usually be the same key-value pairs specified for
-          use in the DNS-SD TXT record for that service.</p>
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Address_Type" type="u" tp:type="Socket_Address_Type">
-        <tp:docstring>
-          The type of the listening address of the local service, as a member of
-          Socket_Address_Type.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Address" type="v">
-        <tp:docstring>
-          The listening address of the local service, as indicated by the
-          address_type.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Access_Control" type="u" tp:type="Socket_Access_Control">
-        <tp:docstring>
-          The access control the local service applies to the local socket,
-          specified so the connection manager can behave appropriately
-          when it connects.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Access_Control_Param" type="v">
-        <tp:docstring>
-          A parameter for the access control type, to be interpreted as
-          specified in the documentation for the Socket_Access_Control enum.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="u" tp:type="Tube_ID" name="Tube_ID">
-        <tp:docstring>
-          The ID of the new tube.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The contact associated with this channel doesn't have tube
-            capabilities.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The connection manager doesn't support stream tubes, or
-            does not support the given address type or access-control type.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="NewTube" tp:name-for-bindings="New_Tube">
-      <tp:docstring>
-        Emitted when a tube is created.
-      </tp:docstring>
-      <arg name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the new tube.
-        </tp:docstring>
-      </arg>
-      <arg name="Initiator" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The handle of the contact who initiated the tube.
-        </tp:docstring>
-      </arg>
-      <arg name="Type" type="u" tp:type="Tube_Type">
-        <tp:docstring>
-          The tube type, as defined by the Tube_Type enum.
-        </tp:docstring>
-      </arg>
-      <arg name="Service" type="s">
-        <tp:docstring>
-          A string representing the service that will be used over the tube.
-        </tp:docstring>
-      </arg>
-      <arg name="Parameters" type="a{sv}" tp:type="String_Variant_Map">
-        <tp:docstring>
-          The new tube's properties.
-        </tp:docstring>
-      </arg>
-      <arg name="State" type="u" tp:type="Tube_State">
-        <tp:docstring>
-          The new tube's state.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <!-- this tp:name-for-bindings is ugly, but compatible with
-    the code generation in telepathy-glib versions that did not use
-    tp:name-for-bindings -->
-    <method name="AcceptDBusTube" tp:name-for-bindings="Accept_D_Bus_Tube">
-      <tp:docstring>
-        Accept a D-Bus tube that's in the "local pending" state. The
-        connection manager will attempt to open the tube. The tube remains in
-        the "local pending" state until the TubeStateChanged signal is
-        emitted.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube to accept.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Address" type="s">
-        <tp:docstring>
-          The string describing the address of the private bus. The client
-          should not attempt to connect to the address until the tube is open.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The given tube ID is invalid or does not refer to a D-Bus
-            tube.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="AcceptStreamTube" tp:name-for-bindings="Accept_Stream_Tube">
-      <tp:docstring>
-        Accept a stream tube that's in the "local pending" state. The
-        connection manager will attempt to open the tube. The tube remains in
-        the "local pending" state until the TubeStateChanged signal is
-        emitted.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube to accept.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Address_Type" type="u" tp:type="Socket_Address_Type">
-        <tp:docstring>
-          The type of address the connection manager should listen on.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Access_Control" type="u" tp:type="Socket_Access_Control">
-        <tp:docstring>
-          The type of access control the connection manager should apply to
-          the socket.
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Access_Control_Param" type="v">
-        <tp:docstring>
-          A parameter for the access control type, to be interpreted as
-          specified in the documentation for the Socket_Access_Control enum.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Address" type="v">
-        <tp:docstring>
-          The address on which the connection manager will listen for
-          connections to this tube. The client should not attempt to connect
-          to the address until the tube is open.
-        </tp:docstring>
-      </arg>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The given tube ID is invalid or does not refer to a stream
-            tube.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The given address type or access-control mechanism is not supported.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="TubeStateChanged" tp:name-for-bindings="Tube_State_Changed">
-      <tp:docstring>
-        Emitted when the state of a tube changes.
-      </tp:docstring>
-      <arg name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube that changed state.
-        </tp:docstring>
-      </arg>
-      <arg name="State" type="u" tp:type="Tube_State">
-        <tp:docstring>
-          The new state of the tube; see the Tube_State enumeration.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <method name="CloseTube" tp:name-for-bindings="Close_Tube">
-      <tp:docstring>
-        Close a tube.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube to close.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument" />
-      </tp:possible-errors>
-    </method>
-
-    <signal name="TubeClosed" tp:name-for-bindings="Tube_Closed">
-      <tp:docstring>
-       Emitted when a tube has been closed. The ID of a closed tube is no
-       longer valid. The ID may later be reused for a new tube.
-      </tp:docstring>
-      <arg name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube that was closed.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <!-- this tp:name-for-bindings is ugly, but compatible with
-    the code generation in telepathy-glib versions that did not use
-    tp:name-for-bindings -->
-    <method name="GetDBusTubeAddress"
-      tp:name-for-bindings="Get_D_Bus_Tube_Address">
-      <tp:docstring>
-        For a D-Bus tube, return a string describing the address of the
-        private bus.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube to get an address for.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="s" name="Address">
-        <tp:docstring>
-          The bus address.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The tube is not a D-Bus tube.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            This tube is not in the "open" state.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <!-- this tp:name-for-bindings is ugly, but compatible with
-    the code generation in telepathy-glib versions that did not use
-    tp:name-for-bindings -->
-    <method name="GetDBusNames" tp:name-for-bindings="Get_D_Bus_Names">
-      <tp:docstring>
-        For a multi-user (i.e. Handle_Type_Room) D-Bus tube, obtain a mapping
-        between contact handles and their unique bus names on this tube.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube to get names for.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a(us)" tp:type="DBus_Tube_Member[]"
-        name="DBus_Names">
-        <tp:docstring>
-          An array of structures, each containing a contact handle and a D-Bus
-          bus name.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The tube is not a multi-user D-Bus tube.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            This tube is not in the "open" state.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <!-- this tp:name-for-bindings is ugly, but compatible with
-    the code generation in telepathy-glib versions that did not use
-    tp:name-for-bindings -->
-    <signal name="DBusNamesChanged" tp:name-for-bindings="D_Bus_Names_Changed">
-      <tp:docstring>
-        Emitted on a multi-user (i.e. Handle_Type_Room) D-Bus tube when a
-        participant opens or closes the tube.
-      </tp:docstring>
-      <arg name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube whose names have changed.
-        </tp:docstring>
-      </arg>
-      <arg name="Added" type="a(us)" tp:type="DBus_Tube_Member[]">
-        <tp:docstring>
-          Array of handles and D-Bus names of new participants.
-        </tp:docstring>
-      </arg>
-      <arg name="Removed" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          Array of handles of former participants.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <method name="GetStreamTubeSocketAddress"
-      tp:name-for-bindings="Get_Stream_Tube_Socket_Address">
-      <tp:docstring>
-        For a stream tube, obtain the address of the socket used to
-        communicate over this tube.
-      </tp:docstring>
-      <arg direction="in" name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the stream tube to get the socket for.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Address_Type" type="u" tp:type="Socket_Address_Type">
-        <tp:docstring>
-          The type of the listening address of the socket, as a member of
-          Socket_Address_Type.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Address" type="v">
-        <tp:docstring>
-          The listening address of the socket, as indicated by the
-          address_type.
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The tube is not a stream tube.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            This tube is not in the "open" state.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="StreamTubeNewConnection"
-      tp:name-for-bindings="Stream_Tube_New_Connection">
-      <tp:docstring>
-        Emitted on a stream tube when a participant opens a new connection
-        to its socket.
-      </tp:docstring>
-      <arg name="ID" type="u" tp:type="Tube_ID">
-        <tp:docstring>
-          The ID of the tube
-        </tp:docstring>
-      </arg>
-      <arg name="Handle" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          The handle of the participant who opened the new connection
-        </tp:docstring>
-      </arg>
-    </signal>
-
-  </interface>
-
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Client.xml b/spec/Client.xml
index 19f69149..3d591480 100644
--- a/spec/Client.xml
+++ b/spec/Client.xml
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client">
+  <interface name="im.telepathy1.Client">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -33,7 +33,7 @@
         address-book synchronization.</p>
 
       <p>Every running or activatable process with a well-known
-        name of the form org.freedesktop.Telepathy.Client.<em>clientname</em>
+        name of the form im.telepathy1.Client.<em>clientname</em>
         should be probed by the channel dispatcher to discover its
         capabilities. Each client is either an <em>observer</em>, an
         <em>approver</em>, a <em>channel handler</em>, or some combination
@@ -54,7 +54,7 @@
 
       <p>The client name, <em>clientname</em>, MUST be a non-empty string of
         ASCII digits, letters, dots and/or underscores, starting with a
-        letter, and without sets of two consecutive dots or a dot
+        letter or underscore, and without sets of two consecutive dots or a dot
         followed by a digit. For non-activatable services, it MAY contain a
         part that is generated per instance at runtime.</p>
 
@@ -62,7 +62,7 @@
         <p>If each of a client Foo's instances should be able to manipulate
           channels separately, the instance with unique name
           <code>:1.25</code> might request a well-known name like
-          <code>org.freedesktop.Telepathy.Client.Foo._1._25</code>.</p>
+          <code>im.telepathy1.Client.Foo._1._25</code>.</p>
 
         <p>(Note that well-known bus-name components may not start with a
           digit, so o.f.T.Client.Foo.1.25 would not be acceptable.)</p>
@@ -75,7 +75,7 @@
         its properties when appropriate.</p>
 
       <p>As an optimization, activatable clients SHOULD install a file
-        <code><a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">$XDG_DATA_DIRS</a>/telepathy/clients/<em>clientname</em>.client</code>
+        <code><a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">$XDG_DATA_DIRS</a>/telepathy-1/clients/<em>clientname</em>.client</code>
         containing a cached version of its immutable properties,
         so that for most clients, the channel dispatcher can
         just read a file to discover capabilities, instead of
@@ -104,9 +104,9 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of the extra interfaces provided by this client.
           This SHOULD include at least one of
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer</tp:dbus-ref>,
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver</tp:dbus-ref> or
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>.</p>
+          <tp:dbus-ref namespace="im.telepathy1">Client.Observer</tp:dbus-ref>,
+          <tp:dbus-ref namespace="im.telepathy1">Client.Approver</tp:dbus-ref> or
+          <tp:dbus-ref namespace="im.telepathy1">Client.Handler</tp:dbus-ref>.</p>
 
         <p>In the <code>.client</code> file, this is represented by key
           "<code>Interfaces</code>" in the group named after this interface.
diff --git a/spec/Client_Approver.xml b/spec/Client_Approver.xml
index 12cbc76a..82806678 100644
--- a/spec/Client_Approver.xml
+++ b/spec/Client_Approver.xml
@@ -20,16 +20,16 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client.Approver">
+  <interface name="im.telepathy1.Client.Approver">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Client"/>
+    <tp:requires interface="im.telepathy1.Client"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Approvers are clients that notify the user that new channels have
         been created by a contact, and allow the user to accept or reject
         those channels. The new channels are represented by a <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
+          namespace="im.telepathy1">ChannelDispatchOperation</tp:dbus-ref>
         object, which is passed to the
         <tp:member-ref>AddDispatchOperation</tp:member-ref> method.</p>
 
@@ -59,9 +59,9 @@
 
       <p>Any approver can approve the handling of a channel dispatch operation
         with a particular channel handler by calling the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
+          namespace="im.telepathy1.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
         method. Approvers can also attempt to <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
+          namespace="im.telepathy1.ChannelDispatchOperation">Claim</tp:dbus-ref>
         channels; if this succeeds, the approver may handle the channels
         itself (if it is also a Handler), or close the channels in order to
         reject them.</p>
@@ -79,7 +79,7 @@
         straight away.</p>
 
       <p>Non-interactive approvers can also be implemented as
-        <tp:dbus-ref namespace="ofdT.Client">Observer</tp:dbus-ref>s as
+        <tp:dbus-ref namespace="imt1.Client">Observer</tp:dbus-ref>s as
         described in the interface description.</p>
     </tp:docstring>
 
@@ -94,7 +94,7 @@
           description.</p>
 
         <p>This property works in exactly the same way as the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
           property. In particular, it cannot change while the approver process
           continues to own the corresponding Client bus name.</p>
 
@@ -134,9 +134,9 @@
         type="a(oa{sv})" tp:type="Channel_Details[]">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The initial value of the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Channels</tp:dbus-ref>
+              namespace="im.telepathy1">ChannelDispatchOperation.Channels</tp:dbus-ref>
             property, containing the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s
+              namespace="im.telepathy1">Channel</tp:dbus-ref>s
             to be dispatched and their properties.</p>
 
           <tp:rationale>
@@ -158,11 +158,11 @@
 
           <p>The actual channels to be dispatched may reduce as channels are
             closed: this is signalled by <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.ChannelLost</tp:dbus-ref>.
+              namespace="im.telepathy1">ChannelDispatchOperation.ChannelLost</tp:dbus-ref>.
           </p>
 
           <p>Approvers SHOULD connect to ChannelLost and <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Finished</tp:dbus-ref>.
+              namespace="im.telepathy1">ChannelDispatchOperation.Finished</tp:dbus-ref>.
             (if desired) before returning from AddDispatchOperation, since
             those signals are guaranteed not to be emitted until after all
             AddDispatchOperation calls have returned (with success or failure)
@@ -173,7 +173,7 @@
       <arg name="DispatchOperation" type="o" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">ChannelDispatchOperation</tp:dbus-ref>
             to be processed.</p>
         </tp:docstring>
       </arg>
@@ -186,11 +186,11 @@
             properties that could change, SHOULD include as many properties as
             possible given that constraint, and MUST include at least the
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Account</tp:dbus-ref>,
+              namespace="im.telepathy1.ChannelDispatchOperation">Account</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Connection</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelDispatchOperation">Connection</tp:dbus-ref>
             and <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">PossibleHandlers</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelDispatchOperation">PossibleHandlers</tp:dbus-ref>
             properties.</p>
         </tp:docstring>
       </arg>
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index 3a922e8c..f1ff37d3 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -20,10 +20,10 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client.Handler">
+  <interface name="im.telepathy1.Client.Handler">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Client"/>
+    <tp:requires interface="im.telepathy1.Client"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Handlers are the user interface for a channel. They turn an abstract
@@ -36,19 +36,17 @@
 
       <p>Because each channel is only handled by one Handler, handlers may
         perform actions that only make sense to do once, such as acknowledging
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>
         messages, doing the actual streaming for <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
-        channels with the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
-        interface, or transferring the file in <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type">FileTransfer</tp:dbus-ref>
+          namespace="im.telepathy1.Channel.Type">Call1</tp:dbus-ref>
+        channels, or transferring the file in <tp:dbus-ref
+          namespace="im.telepathy1.Channel.Type">FileTransfer1</tp:dbus-ref>
         channels.</p>
 
       <p>When a new incoming channel (one with
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">Requested</tp:dbus-ref>
         = FALSE) is offered to
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
+        <tp:dbus-ref namespace="im.telepathy1.Client">Approver</tp:dbus-ref>s
         by the channel dispatcher, it also offers the Approvers a list of all
         the running or activatable handlers whose
         <tp:member-ref>HandlerChannelFilter</tp:member-ref> property
@@ -57,7 +55,7 @@
         those channel handlers to handle the channel.</p>
 
       <p>When a new outgoing channel (one with
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
+        <tp:dbus-ref namespace="im.telepathy1.Channel">Requested</tp:dbus-ref>
         = TRUE) appears, the channel dispatcher passes it to an appropriate
         channel handler automatically.
       </p>
@@ -69,12 +67,10 @@
       type="aa{sv}" access="read" tp:type="Channel_Class[]">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A specification of the channels that this channel handler can
-          deal with. It will be offered to approvers as a potential
-          channel handler for bundles that contain only suitable channels,
-          or for suitable channels that must be handled separately.</p>
+          deal with.</p>
 
         <p>This property works in exactly the same way as the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
           property. In particular, it cannot change while the handler process
           continues to own the corresponding Client bus name.</p>
 
@@ -91,26 +87,11 @@
         <p>If true, channels destined for this handler are automatically
           handled, without invoking approvers.</p>
 
-        <tp:rationale>
-          <p>The intended usage is to allow a client handling one channel to
-            pick up closely related channels. Suppose a client capable of
-            handling both Text and StreamedMedia,
-            <code>org.freedesktop.Telepathy.Client.Empathy</code>, is
-            handling a StreamedMedia channel. That client can take a second
-            well-known bus name, say
-            <code>org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1</code>,
-            and configure an object at
-            <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.</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]
+[im.telepathy1.Client.Handler]
 BypassApproval=true
 </pre>
       </tp:docstring>
@@ -133,7 +114,7 @@ BypassApproval=true
         </tp:rationale>
 
         <p>So far, all client capabilities are defined by the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">Call1</tp:dbus-ref>
           interface.</p>
       </tp:docstring>
     </tp:simple-type>
@@ -148,7 +129,7 @@ BypassApproval=true
 
         <p>For handlers that have a <code>.client</code> file, the
           channel dispatcher may discover this property from the
-          <code>org.freedesktop.Telepathy.Client.Handler.Capabilities</code>
+          <code>im.telepathy1.Client.Handler.Capabilities</code>
           group; for each capability, that group contains a key
           whose name is the capability, with value <code>true</code>.
           Keys with other values SHOULD NOT appear in this group.</p>
@@ -158,11 +139,11 @@ BypassApproval=true
           and Theora and H264 video might contain this group:</p>
 
 <pre>
-[org.freedesktop.Telepathy.Client.Handler.Capabilities]
-org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp=true
-org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex=true
-org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora=true
-org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
+[im.telepathy1.Client.Handler.Capabilities]
+im.telepathy1.Channel.Interface.MediaSignalling/ice-udp=true
+im.telepathy1.Channel.Interface.MediaSignalling/audio/speex=true
+im.telepathy1.Channel.Interface.MediaSignalling/video/theora=true
+im.telepathy1.Channel.Interface.MediaSignalling/video/h264=true
 </pre>
 
         <p>Like the <tp:member-ref>HandlerChannelFilter</tp:member-ref>
@@ -203,10 +184,10 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
         <p>If closing the channels, it is RECOMMENDED that the channel
           dispatcher attempts to close the channels using
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>,
+            namespace="im.telepathy1">Channel.Close</tp:dbus-ref>,
           but resorts to calling
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref>
+            namespace="im.telepathy1">Channel.Interface.Destroyable1.Destroy</tp:dbus-ref>
           (if available) or ignoring the channel (if not) if the same handler
           repeatedly fails to handle channels.</p>
 
@@ -225,10 +206,10 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
       <arg name="Account" type="o" direction="in">
         <tp:docstring>
           The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Account</tp:dbus-ref>
           with which the channels are associated. The
           well-known bus name to use is that of the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>.
+          <tp:dbus-ref namespace="im.telepathy1">AccountManager</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
@@ -256,7 +237,7 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
           <tp:rationale>
             <p>If the handler implements Requests, this tells it
               that these channels match previous <tp:dbus-ref
-                namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref>
+                namespace="im.telepathy1.Client.Interface.Requests">AddRequest</tp:dbus-ref>
               calls that it may have received.</p>
 
             <p>There can be more than one, if they were EnsureChannel
@@ -284,7 +265,7 @@ org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
           <dl>
             <dt><code>request-properties</code> - a{oa{sv}}</dt>
             <dd>A map from <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
               paths listed in <var>Requests_Satisfied</var> to
               <tp:type>Qualified_Property_Value_Map</tp:type>s containing
               namespaced immutable properties of each request.</dd>
diff --git a/spec/Client_Handler_Future.xml b/spec/Client_Handler_Future.xml
index 4c1a8b76..dbb9b348 100644
--- a/spec/Client_Handler_Future.xml
+++ b/spec/Client_Handler_Future.xml
@@ -20,14 +20,14 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client.Handler.FUTURE"
+  <interface name="im.telepathy1.Client.Handler.FUTURE"
     tp:causes-havoc="a staging area for future Handler functionality">
-    <tp:requires interface="org.freedesktop.Telepathy.Client.Handler"/>
+    <tp:requires interface="im.telepathy1.Client.Handler"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface contains functionality which we intend to incorporate
         into the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+          namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
         interface in future. It should be considered to
         be conceptually part of the core Handler interface, but without
         API or ABI guarantees.</p>
@@ -50,7 +50,7 @@
           in the handler's <tt>.client</tt> file as follows:</p>
 
 <pre>
-[org.freedesktop.Telepathy.Client.Handler]
+[im.telepathy1.Client.Handler]
 BypassObservers=true
 </pre>
       </tp:docstring>
@@ -61,13 +61,13 @@ BypassObservers=true
       type="b" access="read">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, channels destined for this handler that have the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface"
-            >Conference</tp:dbus-ref> interface, with a channel that
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface"
+            >Conference1</tp:dbus-ref> interface, with a channel that
           was previously handled by the same client process in their
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Conference"
+          <tp:dbus-ref namespace="im.telepathy1.Channel.Interface.Conference1"
             >InitialChannels</tp:dbus-ref> property, should bypass the
           approval stage. In effect, this is a weaker form of
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler"
+          <tp:dbus-ref namespace="im.telepathy1.Client.Handler"
             >BypassApproval</tp:dbus-ref>.</p>
 
         <tp:rationale>
diff --git a/spec/Client_Interface_Requests.xml b/spec/Client_Interface_Requests.xml
index 3cecfce4..609e1bb3 100644
--- a/spec/Client_Interface_Requests.xml
+++ b/spec/Client_Interface_Requests.xml
@@ -20,11 +20,11 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client.Interface.Requests">
+  <interface name="im.telepathy1.Client.Interface.Requests">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Client"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Client.Handler"/>
+    <tp:requires interface="im.telepathy1.Client"/>
+    <tp:requires interface="im.telepathy1.Client.Handler"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface can be implemented by a Handler to be notified about
@@ -47,14 +47,14 @@
             a channel request which handler will handle particular channels.
             A reasonable heuristic would be to match the request against the
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>,
+              namespace="im.telepathy1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>,
             and respect the preferred handler (if any).</p>
         </tp:rationale>
 
         <p>If the request succeeds and is given to the expected Handler,
           the Requests_Satisfied parameter to
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
           can be used to match the channel to a previous AddRequest call.</p>
 
         <tp:rationale>
@@ -74,7 +74,7 @@
           and if the channel request succeeds, it SHOULD dispatch the channels
           to the expected handler, unless the channels do not match that
           handler's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>.
+            namespace="im.telepathy1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>.
           If the channels are not dispatched to the expected handler, the
           handler that was expected is notified by the channel dispatcher
           calling its <tp:member-ref>RemoveRequest</tp:member-ref> method
@@ -97,11 +97,11 @@
       <arg name="Request" type="o" direction="in">
         <tp:docstring>
           The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+            namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
           object, which MUST have been returned by <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ChannelDispatcher">CreateChannel</tp:dbus-ref>
+            namespace="im.telepathy1.ChannelDispatcher">CreateChannel</tp:dbus-ref>
           or <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
+            namespace="im.telepathy1.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
           before this method is called.
 
           <tp:rationale>
@@ -119,13 +119,13 @@
             properties as possible, given that constraint.</p>
 
           <p>In particular, the properties <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelRequest">Requests</tp:dbus-ref>,
+              namespace="im.telepathy1.ChannelRequest">Requests</tp:dbus-ref>,
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelRequest">UserActionTime</tp:dbus-ref>
             and <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelRequest">Account</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelRequest">Account</tp:dbus-ref>
             MUST be included, and <tp:dbus-ref
-              namespace="ofdT.ChannelRequest">Hints</tp:dbus-ref>
+              namespace="imt1.ChannelRequest">Hints</tp:dbus-ref>
             MUST be included if implemented.</p>
         </tp:docstring>
       </arg>
@@ -157,7 +157,7 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The name of the D-Bus error with which the request failed.</p>
 
-          <p>If this is <code>org.freedesktop.Telepathy.Error.NotYours</code>,
+          <p>If this is <code>im.telepathy1.Error.NotYours</code>,
             this indicates that the request succeeded, but all the resulting
             channels were given to some other handler.</p>
         </tp:docstring>
diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml
index b42b3b1d..8be9e4f5 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -20,10 +20,10 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Client.Observer">
+  <interface name="im.telepathy1.Client.Observer">
     <tp:added version="0.17.26">(as a stable interface)</tp:added>
 
-    <tp:requires interface="org.freedesktop.Telepathy.Client"/>
+    <tp:requires interface="im.telepathy1.Client"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Observers monitor the creation of new channels. This
@@ -48,14 +48,14 @@
           each channel, it would not make sense for observers to do things
           that can only be done by one process (acknowledging
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>
           messages, carrying out streaming for
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Type">Call1</tp:dbus-ref>
           channels, doing the actual data transfer for file transfers,
           setting up the out-of-band connection for Tubes). The
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+            namespace="im.telepathy1.Client">Handler</tp:dbus-ref>
           is responsible for such tasks.</p>
 
         <p>Handlers MAY, of course, delegate responsibility for these
@@ -75,7 +75,7 @@
         although of course the ObserverChannelFilter property can be set
         to filter on the
         <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
+          namespace="im.telepathy1.Channel">Requested</tp:dbus-ref>
         property.</p>
 
       <p>Because it might take time for an observer to become ready (for
@@ -96,12 +96,12 @@
         <li><tp:member-ref>ObserveChannels</tp:member-ref>() is called
           on the observer.</li>
         <li>The observer calls <tp:dbus-ref
-          namespace="ofdT.ChannelDispatchOperation">Claim</tp:dbus-ref>()
+          namespace="imt1.ChannelDispatchOperation">Claim</tp:dbus-ref>()
           on the CDO.</li>
         <li>The observer then returns from
           <tp:member-ref>ObserveChannels</tp:member-ref>().</li>
         <li><tp:dbus-ref
-          namespace="ofdT.ChannelDispatchOperation">Claim</tp:dbus-ref>
+          namespace="imt1.ChannelDispatchOperation">Claim</tp:dbus-ref>
           will return successfully if the channels were successfully
           claimed, or failure if someone else got there first.</li>
       </ol>
@@ -122,7 +122,7 @@
           interested. The <tp:member-ref>ObserveChannels</tp:member-ref> method
           should be called by the channel dispatcher whenever any of the new
           channels in a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
           signal match this description.</p>
 
         <p>Only certain D-Bus types have useful semantics for matching like this,
@@ -161,9 +161,9 @@
 
           <p>If an Observer wants to add extra channels to its list of
             interests at runtime, it can register an additional Client bus name
-            (for instance, the org.freedesktop.Telepathy.Client.Empathy process
+            (for instance, the im.telepathy1.Client.Empathy process
             with unique name :1.42 could additionally register
-            org.freedesktop.Telepathy.Client.Empathy._1_42) with additional
+            im.telepathy1.Client.Empathy._1_42) with additional
             filters. To remove those filters, it can release the bus name;
             it could even re-claim the bus name immediately, with different
             filters.</p>
@@ -180,7 +180,7 @@
 
         <p>Values in the .client file are encoded in exactly the same way as
           the <code>default-<em>p</em></code> keys in .manager files, as
-          described in the <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          described in the <tp:dbus-ref namespace="im.telepathy1"
             >ConnectionManager</tp:dbus-ref> interface (but note that not all
           types supported in .manager files can appear in .client files).</p>
 
@@ -189,18 +189,18 @@
           a local client:</p>
 
 <pre>
-[org.freedesktop.Telepathy.Client]
-Interfaces=org.freedesktop.Telepathy.Client.Observer;
-
-[org.freedesktop.Telepathy.Client.Observer.ObserverChannelFilter 0]
-org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
-org.freedesktop.Telepathy.Channel.TargetHandleType u=1
-org.freedesktop.Telepathy.Channel.Requested b=true
-
-[org.freedesktop.Telepathy.Client.Observer.ObserverChannelFilter 1]
-org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
-org.freedesktop.Telepathy.Channel.TargetHandleType u=2
-org.freedesktop.Telepathy.Channel.Requested b=true
+[im.telepathy1.Client]
+Interfaces=im.telepathy1.Client.Observer;
+
+[im.telepathy1.Client.Observer.ObserverChannelFilter 0]
+im.telepathy1.Channel.ChannelType s=im.telepathy1.Channel.Type.Text
+im.telepathy1.Channel.TargetHandleType u=1
+im.telepathy1.Channel.Requested b=true
+
+[im.telepathy1.Client.Observer.ObserverChannelFilter 1]
+im.telepathy1.Channel.ChannelType s=im.telepathy1.Channel.Type.Text
+im.telepathy1.Channel.TargetHandleType u=2
+im.telepathy1.Channel.Requested b=true
 </pre>
 
       </tp:docstring>
@@ -215,10 +215,10 @@ org.freedesktop.Telepathy.Channel.Requested b=true
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>If true, upon the startup of this observer, <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Client.Observer">ObserveChannels</tp:dbus-ref>
+        namespace="im.telepathy1.Client.Observer">ObserveChannels</tp:dbus-ref>
         will be called for every already existing channel matching
         its <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Client.Observer">ObserverChannelFilter</tp:dbus-ref></p>
+        namespace="im.telepathy1.Client.Observer">ObserverChannelFilter</tp:dbus-ref></p>
 
         <p>When an activatable client having this property disappears from the
           bus and there are channels matching its ObserverChannelFilter,
@@ -227,7 +227,7 @@ org.freedesktop.Telepathy.Channel.Requested b=true
           <tt>.client</tt> file as follows:</p>
 
 <pre>
-[org.freedesktop.Telepathy.Client.Observer]
+[im.telepathy1.Client.Observer]
 Recover=true
 </pre>
 
@@ -236,7 +236,7 @@ Recover=true
             be restarted as soon as possible; while there is an unavoidable
             possibility that it will miss some events during this process
             (particularly <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type">Text</tp:dbus-ref>
             messages), this window of event loss is kept to a minimum.</p>
 
            <p>Non-activatable observers can't take advantage of this
@@ -255,7 +255,7 @@ Recover=true
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Called by the channel dispatcher when channels in which the
           observer has registered an interest are announced in a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+            namespace="im.telepathy1.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
           signal.</p>
 
         <p>If the same NewChannels signal announces some channels that match
@@ -276,7 +276,7 @@ Recover=true
             to avoid the following race: text channel logger (observer) gets
             ObserveChannels, text channel handler gets
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+              namespace="im.telepathy1.Client.Handler">HandleChannels</tp:dbus-ref>
             channel handler starts up faster and acknowledges messages,
             logger never sees those messages.</p>
         </tp:rationale>
@@ -296,17 +296,17 @@ Recover=true
       <arg name="Account" type="o" direction="in">
         <tp:docstring>
           The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Account</tp:dbus-ref>
           with which the channels are associated. The
           well-known bus name to use is that of the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>.
+          <tp:dbus-ref namespace="im.telepathy1">AccountManager</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
       <arg name="Connection" type="o" direction="in">
         <tp:docstring>
           The
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>
           with which the channels are associated. The
           well-known bus name to use can be derived from this object
           path by removing the leading '/' and replacing all subsequent
@@ -318,7 +318,7 @@ Recover=true
         direction="in">
         <tp:docstring>
           The <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s
+            namespace="im.telepathy1">Channel</tp:dbus-ref>s
           and their properties. Their well-known bus names are all the same as
           that of the Connection.
         </tp:docstring>
@@ -327,25 +327,25 @@ Recover=true
       <arg name="Dispatch_Operation" type="o" direction="in">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>The path to the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
+              namespace="im.telepathy1">ChannelDispatchOperation</tp:dbus-ref>
             for these channels, or the special value '/' if there is no
             ChannelDispatchOperation (because the channels were requested, not
             incoming).</p>
 
           <p>If the Observer calls <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelDispatchOperation">Claim</tp:dbus-ref>
             or <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
+              namespace="im.telepathy1.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
             on the dispatch operation, it MUST be careful to avoid deadlock,
             since these methods cannot return until the Observer has returned
             from <tp:member-ref>ObserveChannels</tp:member-ref>.</p>
 
           <tp:rationale>
             <p>This allows an Observer to <tp:dbus-ref
-                namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
+                namespace="im.telepathy1.ChannelDispatchOperation">Claim</tp:dbus-ref>
               a set of channels without having to match up calls to this method
               with calls to <tp:dbus-ref
-                namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>.</p>
+                namespace="im.telepathy1.Client.Approver">AddDispatchOperation</tp:dbus-ref>.</p>
           </tp:rationale>
         </tp:docstring>
       </arg>
@@ -353,14 +353,14 @@ Recover=true
       <arg name="Requests_Satisfied" type="ao" direction="in">
         <tp:docstring>
           The <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>s
+          namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>s
           satisfied by these channels.
 
           <tp:rationale>
             If the same process is an Observer and a Handler, it can be useful
             to be given this information as soon as possible (it will also
             be passed to <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Client">Handler.HandleChannels</tp:dbus-ref>).
+              namespace="im.telepathy1.Client">Handler.HandleChannels</tp:dbus-ref>).
           </tp:rationale>
         </tp:docstring>
       </arg>
@@ -387,7 +387,7 @@ Recover=true
 
             <dt><code>request-properties</code> - a{oa{sv}}</dt>
             <dd>A map from <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+              namespace="im.telepathy1">ChannelRequest</tp:dbus-ref>
               paths listed in <var>Requests_Satisfied</var> to
               <tp:type>Qualified_Property_Value_Map</tp:type>s containing
               namespaced immutable properties of each request.</dd>
@@ -407,14 +407,14 @@ Recover=true
           <p>If true, the channel dispatcher will wait for
             <tp:member-ref>ObserveChannels</tp:member-ref> to return
             before calling <tp:dbus-ref
-            namespace="ofdT.Client">Approver.AddDispatchOperation</tp:dbus-ref>
+            namespace="imt1.Client">Approver.AddDispatchOperation</tp:dbus-ref>
             on appropriate Approvers.</p>
 
           <p>This property SHOULD be false unless there is a reason
             why a channel should not be given to approvers. An example
             of this is if an Observer is also a Handler and wants to
             <tp:dbus-ref
-            namespace="ofdT.ChannelDispatchOperation">Claim</tp:dbus-ref>
+            namespace="imt1.ChannelDispatchOperation">Claim</tp:dbus-ref>
             a channel so that it becomes its handler and doesn't want
             any approver to be called, this property should be true.</p>
 
@@ -431,12 +431,8 @@ Recover=true
             specified in the observer's <tt>.client</tt> file as
             follows:</p>
 
-          <p>If this property is not implemented (telepathy-mission-control
-            5.7.5 and older), the channel dispatcher SHOULD consider it as
-            being false.</p>
-
 <pre>
-[org.freedesktop.Telepathy.Client.Observer]
+[im.telepathy1.Client.Observer]
 DelayApprovers=true
 </pre>
         </tp:docstring>
diff --git a/spec/Connection.xml b/spec/Connection.xml
index ef862b4b..fde7da32 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -21,31 +21,9 @@ License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
 USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.Requests"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.Contacts"/>
-
-    <tp:struct name="Channel_Info" array-name="Channel_Info_List">
-      <tp:deprecated version="0.17.23"/>
-      <tp:docstring>A struct representing a channel, as returned by
-        ListChannels on the Connection interface.</tp:docstring>
-      <tp:member type="o" name="Channel">
-        <tp:docstring>The object path of the channel, which is on the
-          same bus name as the connection</tp:docstring>
-      </tp:member>
-      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type">
-        <tp:docstring>The channel's type</tp:docstring>
-      </tp:member>
-      <tp:member type="u" tp:type="Handle_Type" name="Handle_Type">
-        <tp:docstring>The type of the handle that the channel communicates
-          with, or Handle_Type_None if there is no associated
-          handle</tp:docstring>
-      </tp:member>
-      <tp:member type="u" tp:type="Handle" name="Handle">
-        <tp:docstring>The handle that the channel communicates with,
-          or 0 if there is no associated handle</tp:docstring>
-      </tp:member>
-    </tp:struct>
+  <interface name="im.telepathy1.Connection">
+    <tp:requires interface="im.telepathy1.Connection.Interface.Requests"/>
+    <tp:requires interface="im.telepathy1.Connection.Interface.Contacts"/>
 
     <method name="Connect" tp:name-for-bindings="Connect">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -83,7 +61,7 @@ USA.</p>
         <tp:rationale>
           <p>In some connection managers, certain capabilities of a connection
             are known to be implemented for all connections (e.g. support
-            for SimplePresence), and some interfaces (like SimplePresence) can
+            for Presence), and some interfaces (like Presence) can
             even be used before connecting. Other capabilities may
             or may not exist, depending on server functionality; by the time
             the connection goes CONNECTED, the connection manager is expected
@@ -91,70 +69,9 @@ USA.</p>
             interfaces for the remainder of the Connection's lifetime.</p>
         </tp:rationale>
       </tp:docstring>
-      <tp:added version="0.19.2">Clients SHOULD fall back
-        to calling <tp:member-ref>GetInterfaces</tp:member-ref> if this
-        property is not supported.</tp:added>
+      <tp:added version="0.19.2"/>
     </property>
 
-    <method name="GetInterfaces" tp:name-for-bindings="Get_Interfaces">
-      <arg direction="out" type="as" tp:type="DBus_Interface[]"
-        name="Interfaces">
-        <tp:docstring>
-          The value of the <tp:member-ref>Interfaces</tp:member-ref> property
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Returns the set of optional interfaces supported by this
-          connection. See <tp:member-ref>Interfaces</tp:member-ref> for more
-          details.</p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected">
-          <tp:docstring>
-             Before version 0.17.8 calling GetInterfaces while
-             on a connection that is not yet CONNECTED wasn't allowed. If a
-             CM returns this error, its list of interfaces should be regarded
-             as empty until it becomes CONNECTED.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetProtocol" tp:name-for-bindings="Get_Protocol">
-      <arg direction="out" type="s" tp:type="Protocol" name="Protocol">
-        <tp:docstring>
-          A string identifier for the protocol
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        Get the protocol this connection is using.
-      </tp:docstring>
-    </method>
-
-    <signal name="SelfHandleChanged"
-        tp:name-for-bindings="Self_Handle_Changed">
-      <tp:docstring>
-        Emitted whenever the <tp:member-ref>SelfHandle</tp:member-ref> property
-        changes. If the connection
-        is not yet in the CONNECTED state, this signal is not guaranteed
-        to be emitted.
-      </tp:docstring>
-      <tp:added version="0.17.10">Clients MAY assume that if the
-        SelfHandle property exists, this signal will be emitted when
-        necessary.</tp:added>
-      <tp:deprecated version="0.27.2">Use SelfContactChanged to get the
-      new SelfID at the same time</tp:deprecated>
-
-      <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
-        <tp:docstring>
-          The new value of the SelfHandle property.
-        </tp:docstring>
-      </arg>
-    </signal>
-
     <signal name="SelfContactChanged"
         tp:name-for-bindings="Self_Contact_Changed">
       <tp:docstring>
@@ -190,10 +107,7 @@ USA.</p>
         If the connection is not yet in the CONNECTED state, the value of
         this property MAY be zero.
       </tp:docstring>
-      <tp:added version="0.17.10">For compatibility with older
-        versions, clients should fall back to calling the
-        <tp:member-ref>GetSelfHandle</tp:member-ref>
-        method.</tp:added>
+      <tp:added version="0.17.10"/>
     </property>
 
     <property name="SelfID" tp:name-for-bindings="Self_ID"
@@ -209,27 +123,6 @@ USA.</p>
       <tp:added version="0.27.2"/>
     </property>
 
-    <method name="GetSelfHandle" tp:name-for-bindings="Get_Self_Handle">
-      <arg direction="out" type="u" tp:type="Contact_Handle"
-        name="Self_Handle">
-        <tp:docstring>
-          The value of the <tp:member-ref>SelfHandle</tp:member-ref> property
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        Returns the value of the SelfHandle property. Change notification
-        is via the SelfHandleChanged signal.
-      </tp:docstring>
-      <tp:deprecated version="0.17.10">Use GetAll to get the
-        SelfHandle property (and all other Connection properties)
-        instead.</tp:deprecated>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-      </tp:possible-errors>
-    </method>
-
     <property name="Status" tp:name-for-bindings="Status"
       access="read" type="u" tp:type="Connection_Status">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -242,380 +135,9 @@ USA.</p>
           SHOULD be removed from the bus entirely, meaning that retrieval of
           this property SHOULD fail.</p>
       </tp:docstring>
-      <tp:added version="0.19.2">Clients SHOULD fall back
-        to calling <tp:member-ref>GetStatus</tp:member-ref> if this
-        property is not supported.</tp:added>
+      <tp:added version="0.19.2"/>
     </property>
 
-    <method name="GetStatus" tp:name-for-bindings="Get_Status">
-      <arg direction="out" type="u" tp:type="Connection_Status"
-        name="Status">
-        <tp:docstring>
-          The value of the <tp:member-ref>Status</tp:member-ref> property
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        Get the current status as defined in the
-        <tp:member-ref>StatusChanged</tp:member-ref> signal.
-      </tp:docstring>
-    </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
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Handles" type="au" tp:type="Handle[]">
-        <tp:docstring>
-          A array of integer handles to hold
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <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
-        example, a handle observed in an emitted signal, or displayed
-        somewhere in the UI that is not associated with a channel. The
-        connection manager must not deallocate a handle where any clients
-        have used this method to indicate it is in use until the
-        <tp:member-ref>ReleaseHandles</tp:member-ref>
-        method is called, or the clients disappear from the bus.</p>
-
-        <p>Note that HoldHandles is idempotent - calling it multiple times
-          is equivalent to calling it once. If a handle is "referenced" by
-          several components which share a D-Bus unique name, the client
-          should perform reference counting internally, and only call
-          ReleaseHandles when none of the cooperating components need the
-          handle any longer.</p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The handle type is invalid
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            One of the given handles is not valid
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="InspectHandles" tp:name-for-bindings="Inspect_Handles">
-      <arg direction="in" name="Handle_Type" type="u" tp:type="Handle_Type">
-        <tp:docstring>
-          The type of handle to be inspected
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Handles" type="au" tp:type="Handle[]">
-        <tp:docstring>
-          An array of integer handles of this type
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" type="as" name="Identifiers">
-        <tp:docstring>
-          An array of identifiers corresponding to the given handles, in the same order.
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        Return a string representation for a number of handles of a given
-        type.
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The handle type is invalid
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            One of the given handles is not valid
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="ListChannels" tp:name-for-bindings="List_Channels">
-      <tp:deprecated version="0.17.23">Use the
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.Channels</tp:dbus-ref>
-        property instead.
-      </tp:deprecated>
-
-      <arg direction="out" type="a(osuu)" tp:type="Channel_Info[]"
-        name="Channel_Info">
-        <tp:docstring>
-          An array of structs representing channels.
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        List all the channels which currently exist on this connection.
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="NewChannel" tp:name-for-bindings="New_Channel">
-      <tp:deprecated version="0.17.23">Connection managers MUST still
-        emit this signal, but clients SHOULD listen for the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.NewChannels</tp:dbus-ref>
-        signal instead.
-      </tp:deprecated>
-
-      <arg name="Object_Path" type="o">
-        <tp:docstring>
-          A D-Bus object path for the channel object on this service
-        </tp:docstring>
-      </arg>
-
-      <arg name="Channel_Type" type="s" tp:type="DBus_Interface">
-        <tp:docstring>
-          A D-Bus interface name representing the channel type
-        </tp:docstring>
-      </arg>
-
-      <arg name="Handle_Type" type="u" tp:type="Handle_Type">
-        <tp:docstring>
-          An integer representing the type of handle this channel
-          communicates with, or Handle_Type_None if no handle is specified
-        </tp:docstring>
-      </arg>
-
-      <arg name="Handle" type="u" tp:type="Handle">
-        <tp:docstring>
-          A handle indicating the specific contact, room or list this
-          channel communicates with, or zero if no handle is specified
-        </tp:docstring>
-      </arg>
-
-      <arg name="Suppress_Handler" type="b">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>If true, the channel was requested by a client that intends to
-            present it to the user itself (i.e. it passed suppress_handler=TRUE
-            to the <tp:member-ref>RequestChannel</tp:member-ref> method), so no
-            other handler should be
-            launched. Clients MAY assume that channels where this is true
-            were created by a user request.</p>
-
-          <p>If false, either the channel was created due to incoming
-            information from the service, or the channel was requested by
-            a local client that does not intend to handle the channel itself
-            (this usage is deprecated).</p>
-
-          <p>Clients MUST NOT assume that only incoming channels will have
-            this flag set to false.</p>
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        Emitted when a new Channel object is created, either through user
-        request or incoming information from the service.
-      </tp:docstring>
-    </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)
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Handles" type="au" tp:type="Handle[]">
-        <tp:docstring>
-          An array of integer handles being held by the client
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring>
-        <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
-        <tp:member-ref>HoldHandles</tp:member-ref> for notes.</p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The handle type is invalid
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            One of the given handles is not valid
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="RequestChannel" tp:name-for-bindings="Request_Channel">
-      <tp:deprecated version="0.17.23">Use
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.CreateChannel</tp:dbus-ref>
-        or <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.EnsureChannel</tp:dbus-ref>
-        instead. Connection managers MAY implement RequestChannel by
-        raising NotImplemented, or implement fewer types of channel via
-        this API.</tp:deprecated>
-
-      <arg direction="in" name="Type" type="s" tp:type="DBus_Interface">
-        <tp:docstring>
-          A D-Bus interface name representing base channel type
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Handle_Type" type="u" tp:type="Handle_Type">
-        <tp:docstring>
-          An integer representing the handle type, or Handle_Type_None if
-          no handle is specified
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Handle" type="u" tp:type="Handle">
-        <tp:docstring>
-          A nonzero integer handle representing a contact, room, list etc.
-          according to handle_type, or zero if the handle_type is
-          Handle_Type_None
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Suppress_Handler" type="b">
-        <tp:docstring>
-          <p>Clients SHOULD always set this to true.</p>
-
-          <tp:rationale>
-            <p>The historical meaning was that clients that did not
-              intend to take responsibility for displaying the channel to
-              the user could set this to FALSE, in which case the channel
-              dispatcher would launch an appropriate channel handler.</p>
-
-            <p>However, clients whose functionality relies on having a
-              working channel dispatcher should obtain that functionality by
-              calling methods on the channel dispatcher, so that they will
-              get an appropriate error if the channel dispatcher is missing
-              or not working.</p>
-
-            <p>The channel dispatcher itself should set this to true too,
-              so that it will ignore the
-              <tp:member-ref>NewChannel</tp:member-ref> signal that results
-              from the creation of the channel. It can then dispatch the
-              channel returned from this method to an
-              appropriate handler.</p>
-
-            <p>So, there is no sensible use-case for setting this to false,
-              and setting it to false can result in unhandled channels (in
-              the case where clients assume that a channel dispatcher is
-              present, but it isn't).</p>
-          </tp:rationale>
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" type="o" name="Object_Path">
-        <tp:docstring>
-          The D-Bus object path for the channel created or retrieved
-        </tp:docstring>
-      </arg>
-
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request a channel satisfying the specified type and communicating
-          with the contact, room, list etc. indicated by the given
-          handle_type and handle. The handle_type and handle may both be
-          zero to request the creation of a new, empty channel, which may
-          or may not be possible, depending on the protocol and channel
-          type.</p>
-
-        <p>On success, the returned channel will always be of the requested
-          type (i.e. implement the requested channel-type interface).</p>
-
-        <p>If a new, empty channel is requested, on success the returned
-          channel will always be an "anonymous" channel for which the type
-          and handle are both zero.</p>
-
-        <p>If a channel to a contact, room etc. is requested, on success, the
-          returned channel may either be a new or existing channel to
-          the requested entity (i.e. its
-          <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
-          and <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
-          properties are the
-          requested handle type and handle), or a newly created "anonymous"
-          channel associated with the requested handle in some
-          implementation-specific way.</p>
-
-        <p>For example, for a contact handle, the returned channel
-          might be "anonymous", but implement the groups interface and have
-          the requested contact already present among the members.</p>
-
-        <p>If the request cannot be satisfied, an error is raised and no
-          channel is created.</p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            Unknown channel type
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            The given handle does not exist or cannot be created
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The requested channel type cannot be created with the given handle
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
-          <tp:docstring>
-            The requested channel cannot be created because contact doesn't
-            have the required capabilities.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Banned"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Full"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.InviteOnly"/>
-      </tp:possible-errors>
-    </method>
-
     <tp:enum name="Handle_Type" type="u">
       <tp:enumvalue suffix="None" value="0">
         <tp:docstring>
@@ -634,22 +156,6 @@ USA.</p>
           A chat room
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="List" value="3">
-        <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
-        </tp:deprecated>
-        <tp:docstring>
-          A server-generated contact list (see Channel.Interface.Group)
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Group" value="4">
-        <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
-        </tp:deprecated>
-        <tp:docstring>
-          A user-defined contact list (see Channel.Interface.Group)
-        </tp:docstring>
-      </tp:enumvalue>
     </tp:enum>
 
     <tp:simple-type name="Handle" type="u" array-name="Handle_List">
@@ -669,95 +175,6 @@ USA.</p>
         Handle_Type_Room</tp:docstring>
     </tp:simple-type>
 
-    <tp:simple-type name="List_Handle" type="u"
-      array-name="List_Handle_List">
-      <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
-      </tp:deprecated>
-      <tp:docstring>An unsigned 32-bit integer representing a handle of type
-        Handle_Type_List</tp:docstring>
-    </tp:simple-type>
-
-    <tp:simple-type name="Group_Handle" type="u"
-      array-name="Group_Handle_List">
-      <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
-      </tp:deprecated>
-      <tp:docstring>An unsigned 32-bit integer representing a handle of type
-        Handle_Type_Group</tp:docstring>
-    </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
-        </tp:docstring>
-      </arg>
-
-      <arg direction="in" name="Identifiers" type="as">
-        <tp:docstring>
-          An array of identifiers of entities to request handles for
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" type="au" tp:type="Handle[]"
-        name="Handles">
-        <tp:docstring>
-          An array of integer handle numbers in the same order as the given identifiers.
-        </tp:docstring>
-      </arg>
-
-      <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.</p>
-      </tp:docstring>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            The given identifier does not identify a valid entity of the given
-            type.
-
-            <tp:rationale>
-              For instance, an XMPP connection would raise this error for
-              identifiers with type Handle_Type_Room that do not contain
-              exactly one '@' character, that contain spaces, and so on.
-            </tp:rationale>
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The given handle type is not valid, or is not implemented on this
-            connection.
-
-            <tp:rationale>
-              For instance, a connection to a protocol that doesn't have
-              chat rooms would raise this error for room handles, and all CMs
-              would raise this error for Handle_Type_None.
-            </tp:rationale>
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
     <tp:enum name="Connection_Status" plural="Connection_Statuses" type="u">
       <tp:enumvalue suffix="Connected" value="0">
         <tp:docstring>
@@ -773,13 +190,13 @@ USA.</p>
       </tp:enumvalue>
       <tp:enumvalue suffix="Disconnected" value="2">
         <tp:docstring>
-          If this is retrieved from <tp:member-ref>GetStatus</tp:member-ref> or
-          <tp:member-ref>Status</tp:member-ref>, it indicates that connection
-          has not yet been attempted. If seen in a
-          <tp:member-ref>StatusChanged</tp:member-ref> signal, it indicates
-          that the connection has failed; the Connection object SHOULD be
-          removed from D-Bus immediately, and all subsequent method calls
-          SHOULD fail.
+          If this is retrieved from
+          <tp:member-ref>Status</tp:member-ref>, it indicates that
+          connection has not yet been attempted. If seen in a
+          <tp:member-ref>StatusChanged</tp:member-ref> signal, it
+          indicates that the connection has failed; the Connection
+          object SHOULD be removed from D-Bus immediately, and all
+          subsequent method calls SHOULD fail.
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
@@ -797,7 +214,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.<tp:error-ref>Disconnected</tp:error-ref></code>.</p>
+            <code>im.telepathy1.Error.<tp:error-ref>Disconnected</tp:error-ref></code>.</p>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -809,7 +226,7 @@ USA.</p>
             if and only if the disconnection was requested by the user.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cancelled</code>.</p>
+            <code>im.telepathy1.Error.Cancelled</code>.</p>
         </tp:docstring>
       </tp:enumvalue>
 
@@ -819,15 +236,15 @@ USA.</p>
 
           <p>When the status changes from Connecting to Disconnected for this
             reason, the equivalent D-Bus error is either
-            <code>org.freedesktop.Telepathy.Error.NetworkError</code>,
-            <code>org.freedesktop.Telepathy.Error.ConnectionRefused</code>,
-            <code>org.freedesktop.Telepathy.Error.ConnectionFailed</code>
+            <code>im.telepathy1.Error.NetworkError</code>,
+            <code>im.telepathy1.Error.ConnectionRefused</code>,
+            <code>im.telepathy1.Error.ConnectionFailed</code>
             or some more specific error.</p>
 
           <p>When the status changes from Connected to Disconnected for this
             reason, the equivalent D-Bus error is either
-            <code>org.freedesktop.Telepathy.Error.NetworkError</code>,
-            <code>org.freedesktop.Telepathy.Error.ConnectionLost</code>
+            <code>im.telepathy1.Error.NetworkError</code>,
+            <code>im.telepathy1.Error.ConnectionLost</code>
             or some more specific error.</p>
         </tp:docstring>
       </tp:enumvalue>
@@ -837,7 +254,7 @@ USA.</p>
           <p>The username or password was invalid.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.AuthenticationFailed</code>.
+            <code>im.telepathy1.Error.AuthenticationFailed</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -849,9 +266,9 @@ USA.</p>
             connection was created.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.EncryptionNotAvailable</code>
+            <code>im.telepathy1.Error.EncryptionNotAvailable</code>
             if encryption was not available at all, or
-            <code>org.freedesktop.Telepathy.Error.EncryptionError</code>
+            <code>im.telepathy1.Error.EncryptionError</code>
             if encryption failed.</p>
         </tp:docstring>
       </tp:enumvalue>
@@ -868,7 +285,7 @@ USA.</p>
               and true, the requested account could not be created on the
               server because it already exists.
               The equivalent D-Bus error is
-              <code>org.freedesktop.Telepathy.Error.RegistrationExists</code>.
+              <code>im.telepathy1.Error.RegistrationExists</code>.
             </li>
 
             <li>If the status change is from Connecting to Disconnected
@@ -876,7 +293,7 @@ USA.</p>
               manager could not connect to the specified account because
               a connection to that account already exists.
               The equivalent D-Bus error is
-              <code>org.freedesktop.Telepathy.Error.AlreadyConnected</code>.
+              <code>im.telepathy1.Error.AlreadyConnected</code>.
 
               <tp:rationale>
                 In some protocols, like XMPP (when connecting with the same
@@ -890,7 +307,7 @@ USA.</p>
               a new connection to the same account (perhaps from a different
               client or location) was established.
               The equivalent D-Bus error is
-              <code>org.freedesktop.Telepathy.Error.ConnectionReplaced</code>.
+              <code>im.telepathy1.Error.ConnectionReplaced</code>.
 
               <tp:rationale>
                 In some protocols, like MSNP (when connecting twice with the
@@ -907,7 +324,7 @@ USA.</p>
           <p>The server did not provide a SSL certificate.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.NotProvided</code>.
+            <code>im.telepathy1.Error.Cert.NotProvided</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -920,7 +337,7 @@ USA.</p>
             that.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.Untrusted</code>.
+            <code>im.telepathy1.Error.Cert.Untrusted</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -930,7 +347,7 @@ USA.</p>
           <p>The server's SSL certificate has expired.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.Expired</code>.
+            <code>im.telepathy1.Error.Cert.Expired</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -940,7 +357,7 @@ USA.</p>
           <p>The server's SSL certificate is not yet valid.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.NotActivated</code>.
+            <code>im.telepathy1.Error.Cert.NotActivated</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -950,7 +367,7 @@ USA.</p>
           <p>The server's SSL certificate did not match its hostname.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.HostnameMismatch</code>.
+            <code>im.telepathy1.Error.Cert.HostnameMismatch</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -961,7 +378,7 @@ USA.</p>
             fingerprint.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.FingerprintMismatch</code>.
+            <code>im.telepathy1.Error.Cert.FingerprintMismatch</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -971,7 +388,7 @@ USA.</p>
           <p>The server's SSL certificate is self-signed.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.SelfSigned</code>.
+            <code>im.telepathy1.Error.Cert.SelfSigned</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -982,7 +399,7 @@ USA.</p>
             certificate.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.Invalid</code>.
+            <code>im.telepathy1.Error.Cert.Invalid</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -992,7 +409,7 @@ USA.</p>
           <p>The server's SSL certificate has been revoked.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.Revoked</code>.
+            <code>im.telepathy1.Error.Cert.Revoked</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -1003,7 +420,7 @@ USA.</p>
 	  or is cryptographically weak.</p>
 
           <p>When disconnected for this reason, the equivalent D-Bus error is
-            <code>org.freedesktop.Telepathy.Error.Cert.Insecure</code>.
+            <code>im.telepathy1.Error.Cert.Insecure</code>.
           </p>
         </tp:docstring>
       </tp:enumvalue>
@@ -1015,7 +432,7 @@ USA.</p>
 	  library.</p>
 
 	  <p>When disconnected for this reason, the equivalent D-Bus error is
-	    <code>org.freedesktop.Telepathy.Error.Cert.LimitExceeded</code>
+	    <code>im.telepathy1.Error.Cert.LimitExceeded</code>
 	  </p>
 	</tp:docstring>
       </tp:enumvalue>
@@ -1060,7 +477,7 @@ USA.</p>
           <tp:type>Connection_Status_Reason</tp:type>, or may be a more
           specific Telepathy error
           (such as
-          <code>org.freedesktop.Telepathy.Error.ConnectionRefused</code>
+          <code>im.telepathy1.Error.ConnectionRefused</code>
           for Connection_Status_Reason_Network_Error)
           or a protocol-specific or connection-manager-specific error in a
           suitable namespace.
@@ -1123,10 +540,11 @@ USA.</p>
 
     <tp:contact-attribute name="contact-id" type="s">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same string that would be returned by
-          <tp:member-ref>InspectHandles</tp:member-ref>. As a special case,
-          this is always present in the result of <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts">GetContactAttributes</tp:dbus-ref>,
+        <p>The normalized contact's identifier. Not necessarily the same string
+          as passed to <tp:dbus-ref
+          namespace="imt1.Connection.Interface.Contacts">GetContactByID</tp:dbus-ref>.
+          As a special case, this is always present in the result of <tp:dbus-ref
+            namespace="im.telepathy1.Connection.Interface.Contacts">GetContactAttributes</tp:dbus-ref>,
           whether it was explicitly requested or not.</p>
       </tp:docstring>
     </tp:contact-attribute>
@@ -1171,8 +589,8 @@ USA.</p>
             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
+              namespace="im.telepathy1.Connection.Interface"
+              >Location1</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,
@@ -1182,8 +600,8 @@ USA.</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
+              namespace="im.telepathy1.Connection.Interface"
+              >MailNotification1</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
@@ -1250,18 +668,6 @@ USA.</p>
       </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
@@ -1270,17 +676,17 @@ USA.</p>
 
       <p>In order to allow Connection objects to be discovered by new clients,
         the object path and well-known bus name MUST be of the form
-        <code>/org/freedesktop/Telepathy/Connection/cmname/proto/account</code>
+        <code>/im/telepathy1/Connection/cmname/proto/account</code>
         and
-        <code>org.freedesktop.Telepathy.Connection.cmname.proto.account</code>
+        <code>im.telepathy1.Connection.cmname.proto.account</code>
         where:</p>
 
       <ul>
         <li><em>cmname</em> is the same
           <tp:type>Connection_Manager_Name</tp:type> that appears
           in the connection manager's object path and well-known bus name</li>
-        <li><em>proto</em> is the <tp:type>Protocol</tp:type> name as seen in
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.ConnectionManager">ListProtocols</tp:dbus-ref>,
+        <li><em>proto</em> is the <tp:type>Protocol_Name</tp:type> as seen in
+          <tp:dbus-ref namespace="imt1.ConnectionManager">Protocols</tp:dbus-ref>,
           but with "-" replaced with "_" to get a valid
           object path/bus name</li>
         <li><em>account</em> is some non-empty sequence of ASCII letters,
@@ -1303,12 +709,12 @@ USA.</p>
 
     <p>As well as the methods and signatures below, arbitrary interfaces may be
     provided by the Connection object to represent extra connection-wide
-    functionality, such as the Connection.Interface.SimplePresence for
+    functionality, such as the Connection.Interface.Presence for
     receiving and
     reporting presence information, and Connection.Interface.Aliasing for
     connections where contacts may set and change an alias for themselves.
     These interfaces can be discovered using the
-    <tp:member-ref>GetInterfaces</tp:member-ref> method.</p>
+    <tp:member-ref>Interfaces</tp:member-ref> property.</p>
 
     <p>Contacts, rooms, and server-stored lists (such as subscribed contacts,
     block lists, or allow lists) on a service are all represented by
@@ -1320,19 +726,10 @@ USA.</p>
     <p>Zero as a handle value is sometimes used as a "null" value to mean
     the absence of a contact, room, etc.</p>
 
-    <p>Handles have per-type uniqueness, meaning that
-    every (handle type, handle number) tuple is guaranteed to be unique within
-    a connection and that a handle alone (without its type) is meaningless or
-    ambiguous. Connection manager implementations should reference count these
-    handles to determine if they are in use either by any active clients or any
-    open channels, and may deallocate them when this ceases to be true. Clients
-    may request handles of a given type and identifier with the
-    <tp:member-ref>RequestHandles</tp:member-ref> method, inspect the entity
-    identifier with the <tp:member-ref>InspectHandles</tp:member-ref>
-    method, keep handles from being released with
-    <tp:member-ref>HoldHandles</tp:member-ref>, and notify that they are no
-    longer storing handles with
-    <tp:member-ref>ReleaseHandles</tp:member-ref>.</p>
+    <p>Handles have per-type uniqueness, meaning that every (handle
+    type, handle number) tuple is guaranteed to be unique within a
+    connection for the lifetime of the connection and that a handle
+    alone (without its type) is meaningless or ambiguous.</p>
     </tp:docstring>
 
     <tp:changed version="0.17.10">Previously, the account part of
@@ -1346,6 +743,10 @@ USA.</p>
       are now mandatory. Their functionality will be merged into the main
       Connection interface at some point in future.</tp:changed>
 
+    <tp:changed version="0.99.1">All deprecated types, methods,
+      and signals have been removed from this interface including
+      anything to do with handle reference counting.</tp:changed>
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Addressing.xml b/spec/Connection_Interface_Addressing1.xml
index 129e6716..8e359f66 100644
--- a/spec/Connection_Interface_Addressing.xml
+++ b/spec/Connection_Interface_Addressing1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Addressing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Addressing1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2010-2012 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
@@ -16,9 +16,9 @@
       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.Addressing1">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.Contacts"/>
+  <interface name="im.telepathy1.Connection.Interface.Addressing1">
+    <tp:requires interface="im.telepathy1.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection.Interface.Contacts"/>
     <tp:added version="0.25.2">(as stable API)</tp:added>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface deals with the multiple address types that can
@@ -38,7 +38,7 @@
           <p>The vCard field of the addresses we are requesting. The
             field name SHOULD be in lower case. Supported
             fields can be found in
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableVCardFields</tp:dbus-ref>.</p>
+            <tp:dbus-ref namespace="im.telepathy1.Protocol.Interface.Addressing1">AddressableVCardFields</tp:dbus-ref>.</p>
 
           <p>The <code>url</code> vCard field MUST NOT appear here; see
             <tp:member-ref>GetContactsByURI</tp:member-ref> instead.</p>
@@ -65,13 +65,13 @@
             activity, will be in the reply.</p>
 
           <p>Attributes from this interface and from
-            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
+            <tp:dbus-ref>im.telepathy1.Connection</tp:dbus-ref>
             are always returned, and need not be requested
             explicitly.</p>
 
           <p>The behavior of this parameter is similar to the same
             parameter in
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
+            <tp:dbus-ref namespace="im.telepathy1.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
           </tp:docstring>
       </arg>
 
@@ -101,7 +101,7 @@
 
           <p>Each contact's attributes will always include at least the
             identifier that would be obtained by inspecting the handle
-            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>).
+            (<code>im.telepathy1.Connection/contact-id</code>).
           </p>
         </tp:docstring>
       </arg>
@@ -109,17 +109,10 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request contacts and retrieve their attributes using a given field
           in their vCards.</p>
-
-        <p>The connection manager should record that these handles are in
-          use by the client who invokes this method, and must not
-          deallocate the handles until the client disconnects from the
-          bus or calls the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.ReleaseHandles</tp:dbus-ref>
-          method.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
       </tp:possible-errors>
     </method>
 
@@ -129,7 +122,7 @@
         <tp:docstring>
           The URI addresses to get contact handles for. Supported
           schemes can be found in
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableURISchemes</tp:dbus-ref>.
+          <tp:dbus-ref namespace="im.telepathy1.Protocol.Interface.Addressing1">AddressableURISchemes</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <arg direction="in" name="Interfaces" type="as"
@@ -141,13 +134,13 @@
             activity, will be in the reply.</p>
 
           <p>Attributes from this interface and from
-            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
+            <tp:dbus-ref>im.telepathy1.Connection</tp:dbus-ref>
             are always returned, and need not be requested
             explicitly.</p>
 
           <p>The behavior of this parameter is similar to the same
             parameter in
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
+            <tp:dbus-ref namespace="im.telepathy1.Connection.Interface">Contacts.GetContactAttributes</tp:dbus-ref>.</p>
           </tp:docstring>
       </arg>
 
@@ -176,24 +169,17 @@
 
           <p>Each contact's attributes will always include at least the
             identifier that would be obtained by inspecting the handle
-            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>).
+            (<code>im.telepathy1.Connection/contact-id</code>).
           </p>
         </tp:docstring>
       </arg>
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request contacts and retrieve their attributes using URI addresses.</p>
-
-        <p>The connection manager should record that these handles are in
-          use by the client who invokes this method, and must not
-          deallocate the handles until the client disconnects from the
-          bus or calls the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.ReleaseHandles</tp:dbus-ref>
-          method.</p>
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Aliasing.xml b/spec/Connection_Interface_Aliasing1.xml
index 96757713..55b11dca 100644
--- a/spec/Connection_Interface_Aliasing.xml
+++ b/spec/Connection_Interface_Aliasing1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Aliasing" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Aliasing1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
@@ -18,8 +18,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Aliasing">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Aliasing1">
+    <tp:requires interface="im.telepathy1.Connection"/>
 
     <tp:mapping name="Alias_Map" array-name="">
       <tp:docstring>A dictionary whose keys are contact handles and whose
@@ -28,24 +28,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:member type="s" name="Alias"/>
     </tp:mapping>
 
-    <tp:struct name="Alias_Pair" array-name="Alias_Pair_List">
-      <tp:docstring>
-        A pair (contact handle, alias) as seen in the
-        <tp:member-ref>AliasesChanged</tp:member-ref> signal.
-      </tp:docstring>
-      <tp:member type="u" tp:type="Contact_Handle" name="Handle"/>
-      <tp:member type="s" name="Alias"/>
-    </tp:struct>
-
     <signal name="AliasesChanged" tp:name-for-bindings="Aliases_Changed">
-      <arg name="Aliases" type="a(us)" tp:type="Alias_Pair[]">
-        <!-- FIXME: if we break API, this could be an Alias_Map, a{us} -->
+      <arg name="Aliases" type="a{us}" tp:type="Alias_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array containing structs of:
-          <ul>
-            <li>the handle representing the contact</li>
-            <li>the new alias</li>
-          </ul>
+          A mapping from the handle representing the contact to the new alias
         </tp:docstring>
       </arg>
       <tp:docstring>
@@ -70,21 +56,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </tp:flag>
     </tp:flags>
-    <method name="GetAliasFlags" tp:name-for-bindings="Get_Alias_Flags">
-      <arg direction="out" type="u" tp:type="Connection_Alias_Flags"
-        name="Alias_Flags">
-        <tp:docstring>
-          An integer with a bitwise OR of flags from ConnectionAliasFlags
-        </tp:docstring>
-      </arg>
+    <property name="AliasFlags"
+      tp:name-for-bindings="Alias_Flags" type="u" access="read"
+      tp:immutable="yes">
+      <tp:added version="0.99.1"/>
       <tp:docstring>
-        Return a bitwise OR of flags detailing the behaviour of aliases on this
-        connection.
+        A bitwise OR of flags from ConnectionAliasFlags detailing the behaviour
+        of aliases on this connection.
       </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-      </tp:possible-errors>
-    </method>
+    </property>
     <method name="RequestAliases" tp:name-for-bindings="Request_Aliases">
       <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
@@ -100,34 +80,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Request the value of several contacts' aliases at once.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-      </tp:possible-errors>
-    </method>
-    <method name="GetAliases" tp:name-for-bindings="Get_Aliases">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of handles representing contacts
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a{us}" tp:type="Alias_Map" name="Aliases">
-        <tp:docstring>
-          A dictionary mapping contact handles to aliases
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request the value of several contacts' aliases at once. This SHOULD
-        only return cached aliases, falling back on the contact identifier
-        (i.e. the string corresponding to the handle) if none is present. Also
-        if there was no cached alias, a request SHOULD be started of which the
-        result is later signalled by
-        <tp:member-ref>AliasesChanged</tp:member-ref>.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
       </tp:possible-errors>
     </method>
     <method name="SetAliases" tp:name-for-bindings="Set_Aliases">
@@ -142,26 +98,26 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         indicated by emitting an <tp:member-ref>AliasesChanged</tp:member-ref>
         signal. On connections where the CONNECTION_ALIAS_FLAG_USER_SET flag is
         not set, this method will only ever succeed if the contact is the
-        user's own handle (as returned by <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection.GetSelfHandle</tp:dbus-ref>).
+        user's own handle (as returned by the <tp:dbus-ref
+          namespace="im.telepathy1">Connection.SelfHandle</tp:dbus-ref>
+        property).
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
     <tp:contact-attribute name="alias" type="s">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same string that would be returned by
-          <tp:member-ref>GetAliases</tp:member-ref>
-          (always present with some value, possibly the
-          same as Connection/contact-id, if information from the
-          Aliasing interface was requested)
-        </p>
+        <p>The contact's alias. This SHOULD only return cached aliases, falling
+        back on the contact identifier (i.e. the string corresponding to the
+        handle) if none is present. Also if there was no cached alias, a request
+        SHOULD be started of which the result is later signalled by
+        <tp:member-ref>AliasesChanged</tp:member-ref>.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
@@ -172,8 +128,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     alias is changed or first discovered.</p>
 
     <p>On connections where the user is allowed to set aliases for contacts and
-    store them on the server, the <tp:member-ref>GetAliasFlags</tp:member-ref>
-    method will have the CONNECTION_ALIAS_FLAG_USER_SET flag set, and the
+    store them on the server, the <tp:member-ref>AliasFlags</tp:member-ref>
+    property will have the CONNECTION_ALIAS_FLAG_USER_SET flag set, and the
     <tp:member-ref>SetAliases</tp:member-ref> method may be called on contact
     handles other than the user themselves.</p>
 
diff --git a/spec/Connection_Interface_Anonymity.xml b/spec/Connection_Interface_Anonymity1.xml
index 704263cb..8e626d06 100644
--- a/spec/Connection_Interface_Anonymity.xml
+++ b/spec/Connection_Interface_Anonymity1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Anonymity"
+<node name="/Connection_Interface_Anonymity1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2008-2010 Nokia Corporation</tp:copyright>
@@ -21,7 +21,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Anonymity">
+  <interface name="im.telepathy1.Connection.Interface.Anonymity1">
     <tp:added version="0.19.7">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -118,7 +118,7 @@
           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.Error.<tp:error-ref>WouldBreakAnonymity</tp:error-ref></code>
+          <code>im.telepathy1.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
@@ -137,7 +137,7 @@
           <tp:member-ref>AnonymityModesChanged</tp:member-ref> signal.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             An unsupported mode was supplied. Supported modes are specified
             in the SupportedAnonymityModes property, and this should be
diff --git a/spec/Connection_Interface_Avatars.xml b/spec/Connection_Interface_Avatars1.xml
index 3b9290e1..1d3f4626 100644
--- a/spec/Connection_Interface_Avatars.xml
+++ b/spec/Connection_Interface_Avatars1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Avatars" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Avatars1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2005-2008 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright (C) 2005-2008 Nokia Corporation</tp:copyright>
   <tp:copyright>Copyright (C) 2006 INdT</tp:copyright>
@@ -18,8 +18,11 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Avatars">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Avatars1">
+    <tp:requires interface="im.telepathy1.Connection"/>
+    <tp:changed version="0.99.1">The deprecated method,
+      GetAvatarRequirements, has been removed in favour of using the
+      D-Bus properties instead.</tp:changed>
 
     <tp:simple-type name="Avatar_Token" type="s"
       array-name="Avatar_Token_List">
@@ -45,7 +48,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:rationale>
           <p>This means that clients MAY use the triple
             (<tp:type>Connection_Manager_Name</tp:type>,
-            <tp:type>Protocol</tp:type>, avatar token) as a key for
+            <tp:type>Protocol_Name</tp:type>, avatar token) as a key for
             their avatar cache. For instance, an avatar for a
             telepathy-gabble Jabber contact might be stored in a file
             .../gabble/jabber/4e199b4a1c40b497a95fcd1cd896351733849949.png.</p>
@@ -128,9 +131,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="SupportedAvatarMIMETypes"
       tp:name-for-bindings="Supported_Avatar_MIME_Types"
       type="as" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         An array of supported MIME types (e.g. "image/jpeg").
         Clients MAY assume that the first type in this array is preferred.
@@ -142,9 +143,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="MinimumAvatarHeight"
       tp:name-for-bindings="Minimum_Avatar_Height"
       type="u" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         The minimum height in pixels of an avatar on this protocol, which MAY
         be 0.
@@ -156,9 +155,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="MinimumAvatarWidth"
       tp:name-for-bindings="Minimum_Avatar_Width"
       type="u" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         The minimum width in pixels of an avatar on this protocol, which MAY
         be 0.
@@ -206,9 +203,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="MaximumAvatarHeight"
       tp:name-for-bindings="Maximum_Avatar_Height"
       type="u" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         The maximum height in pixels of an avatar on this protocol, or 0 if
         there is no limit.
@@ -220,9 +215,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="MaximumAvatarWidth"
       tp:name-for-bindings="Maximum_Avatar_Width"
       type="u" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         The maximum width in pixels of an avatar on this protocol, or 0 if
         there is no limit.
@@ -234,9 +227,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <property name="MaximumAvatarBytes"
       tp:name-for-bindings="Maximum_Avatar_Bytes"
       type="u" access="read">
-      <tp:added version="0.17.22">Fall back to calling
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
-          property fails.</tp:added>
+      <tp:added version="0.17.22"/>
       <tp:docstring>
         The maximum size in bytes of an avatar on this protocol, or 0 if
         there is no limit.
@@ -245,81 +236,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </property>
 
-    <method name="GetAvatarRequirements"
-      tp:name-for-bindings="Get_Avatar_Requirements">
-      <tp:deprecated version="0.17.22">Use GetAll to retrieve the
-        D-Bus properties on this interface, falling back to this method
-        on failure.</tp:deprecated>
-      <arg direction="out" type="as" name="MIME_Types">
-        <tp:docstring>
-          An array of supported MIME types (eg image/jpeg)
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="q" name="Min_Width">
-        <tp:docstring>
-          The minimum image width in pixels
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="q" name="Min_Height">
-        <tp:docstring>
-          The minimum image height in pixels
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="q" name="Max_Width">
-        <tp:docstring>
-          The maximum image width in pixels, or 0 if there is no limit
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="q" name="Max_Height">
-        <tp:docstring>
-          The maximum image height in pixels, or 0 if there is no limit
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="u" name="Max_Bytes">
-        <tp:docstring>
-          The maximum image size in bytes, or 0 if there is no limit
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get the required format of avatars on this connection.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetAvatarTokens" tp:name-for-bindings="Get_Avatar_Tokens">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-        An array of handles representing contacts
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="as" name="Tokens" tp:type="Avatar_Token[]">
-        <tp:docstring>
-          An array of avatar tokens or empty strings (if no avatar is set) in the
-          same order as the given array of contact handles
-        </tp:docstring>
-      </arg>
-      <tp:deprecated version="0.15.5">Use GetKnownAvatarTokens
-        instead.</tp:deprecated>
-      <tp:docstring>
-        Get the unique tokens for all of the given contacts' avatars.
-
-        Using this method in new Telepathy clients is deprecated; use
-        <tp:member-ref>GetKnownAvatarTokens</tp:member-ref> instead.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-      </tp:possible-errors>
-    </method>
-
     <method name="GetKnownAvatarTokens"
       tp:name-for-bindings="Get_Known_Avatar_Tokens">
       <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
@@ -345,47 +261,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         map until an avatar is explicitly set or cleared.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="RequestAvatar" tp:name-for-bindings="Request_Avatar">
-      <arg direction="in" name="Contact" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          An integer handle for the contact to request the avatar for
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="ay" name="Data">
-        <tp:docstring>
-          An array of bytes containing the image data
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="s" name="MIME_Type">
-        <tp:docstring>
-        A string containing the image MIME type (eg image/jpeg), or empty if
-        unknown
-        </tp:docstring>
-      </arg>
-      <tp:deprecated version="0.15.5">Use RequestAvatars
-        instead.</tp:deprecated>
-      <tp:docstring>
-        Request the avatar for a given contact. Using this method in new
-        Telepathy clients is deprecated; use RequestAvatars instead.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The contact does not currently have an avatar.
-          </tp:docstring>
-        </tp:error>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
       </tp:possible-errors>
     </method>
 
@@ -404,8 +284,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         avatar) the AvatarRetrieved signal is not emitted for that contact.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
       </tp:possible-errors>
     </method>
 
@@ -427,15 +307,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
       <tp:docstring>
         Set a new avatar image for this connection. The avatar image must
-        respect the requirements obtained by
-        <tp:member-ref>GetAvatarRequirements</tp:member-ref>.
+        respect the requirements obtained by the properties on this
+        interface.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
       </tp:possible-errors>
     </method>
 
@@ -445,8 +325,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Remove the avatar image for this connection.
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -473,7 +353,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <p>Avatars are identified by a string, the <tp:type>Avatar_Token</tp:type>,
     which represents a particular avatar. Tokens MUST be chosen by the
     connection manager in such a way that the triple
-    (<tp:type>Connection_Manager_Name</tp:type>, <tp:type>Protocol</tp:type>,
+    (<tp:type>Connection_Manager_Name</tp:type>,
+    <tp:type>Protocol_Name</tp:type>,
     <tp:type>Avatar_Token</tp:type>) uniquely identifies an avatar.
     An empty token means that an avatar has not been set for this contact, and
     a changed token implies the contact's avatar has changed, but the strings
@@ -492,9 +373,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <p>To publish an avatar, a client should use
     <tp:member-ref>SetAvatar</tp:member-ref> to provide an image which meets
-    the requirements returned by the
-    <tp:member-ref>GetAvatarRequirements</tp:member-ref>
-    function. On some protocols the avatar is stored on the server, so setting
+    the requirements returned by the the properties on the interface.
+    On some protocols the avatar is stored on the server, so setting
     the avatar is persistent, but on others it is transferred via a peer to
     peer mechanism, so needs to be set every connection. Hence, on every
     connection, clients should inspect the avatar token of the connection's
diff --git a/spec/Connection_Interface_Balance.xml b/spec/Connection_Interface_Balance1.xml
index 974c651f..a01b8241 100644
--- a/spec/Connection_Interface_Balance.xml
+++ b/spec/Connection_Interface_Balance1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Balance"
+<node name="/Connection_Interface_Balance1"
   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>
@@ -19,8 +19,8 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Balance">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Balance1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.19.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -82,7 +82,7 @@
       access="read" type="(ius)" tp:type="Currency_Amount">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The user's balance on the account corresponding to this <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.
+            namespace="im.telepathy1">Connection</tp:dbus-ref>.
           A negative amount may be possible on some services, and indicates
           that the user owes money to the service provider.</p>
 
diff --git a/spec/Connection_Interface_Capabilities.xml b/spec/Connection_Interface_Capabilities.xml
deleted file mode 100644
index 8e5eb335..00000000
--- a/spec/Connection_Interface_Capabilities.xml
+++ /dev/null
@@ -1,254 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Connection_Interface_Capabilities" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Capabilities">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities"/>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>An interface for connections where it is possible to know what channel
-        types may be requested before the request is made to the connection
-        object. Each capability represents a commitment by the connection
-        manager that it will ordinarily be able to create a channel when given
-        a request with the given type and handle.</p>
-
-      <p>Capabilities pertain to particular contact handles, and represent
-        activities such as having a text chat or a voice call with the user.
-        The activities are represented by the D-Bus interface name of the
-        channel type for that activity.</p>
-
-      <p>The generic capability flags are defined by
-        <tp:type>Connection_Capability_Flags</tp:type>.</p>
-
-      <p>In addition, channel types may have type specific capability flags of
-        their own, which are described in the documentation for each channel
-        type.</p>
-
-      <p>This interface also provides for user interfaces notifying the
-        connection manager of what capabilities to advertise for the user. This
-        is done by using the
-        <tp:member-ref>AdvertiseCapabilities</tp:member-ref> method, and deals
-        with the
-        interface names of channel types and the type specific flags pertaining
-        to them which are implemented by available client processes.</p>
-    </tp:docstring>
-
-    <tp:changed version="0.17.8">Previously, this interface
-      also expressed capabilities of the connection itself, indicating what
-      sorts of channels could be requested (for instance, the ability to
-      open chatroom lists or chatrooms). However, this was never very
-      well-defined or consistent, and as far as we know it was never
-      implemented correctly. This usage is now deprecated.</tp:changed>
-
-    <tp:deprecated version="0.19.8">Client implementations SHOULD use <tp:dbus-ref
-      namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities</tp:dbus-ref>
-      instead.</tp:deprecated>
-    <tp:changed version="0.19.8">Connection managers implementing
-      Capabilities MUST implement ContactCapabilities too.</tp:changed>
-
-    <tp:flags name="Connection_Capability_Flags"
-      value-prefix="Connection_Capability_Flag" type="u">
-      <tp:flag suffix="Create" value="1">
-        <tp:docstring>
-          The given channel type and handle can be given to <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection">RequestChannel</tp:dbus-ref>
-          to create a new channel of this type.
-        </tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Invite" value="2">
-        <tp:docstring>
-          The given contact can be invited to an existing channel of this type.
-        </tp:docstring>
-      </tp:flag>
-    </tp:flags>
-
-    <tp:struct name="Capability_Pair" array-name="Capability_Pair_List">
-      <tp:docstring>A pair (channel type, type-specific flags) as passed to
-        <tp:member-ref>AdvertiseCapabilities</tp:member-ref> on the
-        Capabilities interface.</tp:docstring>
-      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type"/>
-      <tp:member type="u" name="Type_Specific_Flags"/>
-    </tp:struct>
-
-    <tp:struct name="Contact_Capability" array-name="Contact_Capability_List">
-      <tp:docstring>A struct (contact handle, channel type, generic flags,
-        type-specific flags) representing a capability posessed by a contact,
-        as returned by <tp:member-ref>GetCapabilities</tp:member-ref> on the
-        Capabilities interface.</tp:docstring>
-      <tp:member type="u" tp:type="Contact_Handle" name="Handle"/>
-      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type"/>
-      <tp:member type="u" tp:type="Connection_Capability_Flags"
-                 name="Generic_Flags"/>
-      <tp:member type="u" name="Type_Specific_Flags"/>
-    </tp:struct>
-
-    <tp:struct name="Capability_Change" array-name="Capability_Change_List">
-      <tp:docstring>A struct (contact handle, channel type, old generic flags,
-        new generic flags, old type-specific flags, new type-specific flags)
-        representing a change to one of a contact's capabilities, as seen in the
-        <tp:member-ref>CapabilitiesChanged</tp:member-ref> signal on the
-        Capabilities interface.</tp:docstring>
-      <tp:member type="u" tp:type="Contact_Handle" name="Handle"/>
-      <tp:member type="s" tp:type="DBus_Interface" name="Channel_Type"/>
-      <tp:member type="u" tp:type="Connection_Capability_Flags"
-                 name="Old_Generic_Flags"/>
-      <tp:member type="u" tp:type="Connection_Capability_Flags"
-                 name="New_Generic_Flags"/>
-      <tp:member type="u" name="Old_Type_Specific_Flags"/>
-      <tp:member type="u" name="New_Type_Specific_Flags"/>
-    </tp:struct>
-
-    <method name="AdvertiseCapabilities"
-      tp:name-for-bindings="Advertise_Capabilities">
-      <arg direction="in" name="Add" type="a(su)" tp:type="Capability_Pair[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structures containing:
-          <ul>
-            <li>a string channel type</li>
-            <li>a bitwise OR of type specific capability flags</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Remove" type="as" tp:type="DBus_Interface[]">
-        <tp:docstring>
-          An array of D-Bus interface names of channel types to remove
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a(su)" tp:type="Capability_Pair[]"
-        name="Self_Capabilities">
-        <tp:docstring>
-          An array of structures describing the current capabilities containing:
-          <ul>
-            <li>a string channel type</li>
-            <li>a bitwise OR of type specific capability flags</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Used by user interfaces to indicate which channel types they are able
-        to handle on this connection. Because these may be provided by
-        different client processes, this method accepts channel types to add
-        and remove from the set already advertised on this connection. The type
-        of advertised capabilities (create versus invite) is protocol-dependent
-        and hence cannot be set by the this method. In the case of a client
-        adding an already advertised channel type but with new channel type
-        specific flags, the connection manager should simply add the new flags
-        to the set of advertised capabilities.</p>
-
-        <p>Upon a successful invocation of this method, the
-        <tp:member-ref>CapabilitiesChanged</tp:member-ref>
-        signal will be emitted for the user's own handle ( <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection.GetSelfHandle</tp:dbus-ref>)
-        by the connection manager to indicate the changes
-        that have been made.  This signal should also be monitored to ensure
-        that the set is kept accurate - for example, a client may remove
-        capabilities or type specific capability flags when it exits
-        which are still provided by another client.</p>
-
-        <p>On connections managed by the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>,
-          this method SHOULD NOT be used by clients other than the
-          ChannelDispatcher itself.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-      </tp:possible-errors>
-    </method>
-
-    <signal name="CapabilitiesChanged"
-      tp:name-for-bindings="Capabilities_Changed">
-      <arg name="Caps" type="a(usuuuu)" tp:type="Capability_Change[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structures containing:
-          <ul>
-            <li>an integer handle representing the contact</li>
-            <li>a string channel type</li>
-            <li>a bitwise OR of the contact's old generic capability flags</li>
-            <li>a bitwise OR of the contact's new generic capability flags</li>
-            <li>a bitwise OR of the contact's old type specific capability flags</li>
-            <li>a bitwise OR of the contact's new type specific capability flags</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Announce that there has been a change of capabilities on the
-          given handle.</p>
-
-        <p>If the handle is zero, the capabilities refer to the connection
-          itself, in some poorly defined way. This usage is deprecated and
-          clients should ignore it.</p>
-      </tp:docstring>
-    </signal>
-
-    <method name="GetCapabilities" tp:name-for-bindings="Get_Capabilities">
-      <arg direction="in" name="Handles" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of contact handles for this connection.</p>
-
-          <p>This may include zero, which originally meant a query for
-            capabilities available on the connection itself. This usage
-            is deprecated; clients SHOULD NOT do this, and connection managers
-            SHOULD proceed as though zero had not been present in this
-            list.</p>
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a(usuu)" tp:type="Contact_Capability[]"
-        name="Contact_Capabilities">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structures containing:
-          <ul>
-            <li>an integer handle representing the contact</li>
-            <li>a string channel type</li>
-            <li>a bitwise OR of generic capability flags for the type</li>
-            <li>a bitwise OR of type specific capability flags for the type</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Returns an array of capabilities for the given contact handles.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            The handle does not represent a contact and is not zero
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
-
-    <tp:contact-attribute name="caps"
-      type="a(usuu)" tp:type="Contact_Capability[]">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same structs that would be returned by
-          <tp:member-ref>GetCapabilities</tp:member-ref>
-          (all of them will redundantly have the contact's handle as the
-          first member). Omitted from the result if the contact's capabilities
-          are not known; present in the result as an empty array if the
-          contact is known to have no capabilities at all.</p>
-      </tp:docstring>
-    </tp:contact-attribute>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Cellular.xml b/spec/Connection_Interface_Cellular1.xml
index e9b10e3c..d5f66974 100644
--- a/spec/Connection_Interface_Cellular.xml
+++ b/spec/Connection_Interface_Cellular1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Cellular"
+<node name="/Connection_Interface_Cellular1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2008-2010 Nokia Corporation</tp:copyright>
@@ -21,7 +21,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Cellular">
+  <interface name="im.telepathy1.Connection.Interface.Cellular1">
     <tp:added version="0.19.8">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Connection_Interface_Client_Types.xml b/spec/Connection_Interface_Client_Types1.xml
index 97908561..985c7552 100644
--- a/spec/Connection_Interface_Client_Types.xml
+++ b/spec/Connection_Interface_Client_Types1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Client_Types"
+<node name="/Connection_Interface_Client_Types1"
   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">
@@ -17,9 +17,9 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ClientTypes">
+  <interface name="im.telepathy1.Connection.Interface.ClientTypes1">
     <tp:added version="0.21.1">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface on connections to support protocols which allows users to
@@ -61,7 +61,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         client types of the most available resource will be returned. In
         other words, the returned client types are those for the resource whose
         presence will be retreived using the
-        <tp:dbus-ref namespace="ofdT.Connection.Interface">SimplePresence</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Connection.Interface">Presence1</tp:dbus-ref>
         interface.</p>
 
       <p>For example, if a contact has two resources:</p>
@@ -98,46 +98,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:member>
     </tp:mapping>
 
-    <method name="GetClientTypes" tp:name-for-bindings="Get_Client_Types">
-      <tp:docstring>
-        Return the client types of the given contacts, if they are
-        already known. If any of the given contacts' client types are
-        not known, request their current client types, but return
-        immediately without waiting for a reply; if a reply with a
-        non-empty client type array is later received for those
-        contacts, the
-        <tp:member-ref>ClientTypesUpdated</tp:member-ref> signal will
-        be emitted for them.
-
-        <tp:rationale>
-          This method is appropriate for "lazy" client type finding, for instance
-          displaying the client types (if available) of everyone in your contact
-          list.
-        </tp:rationale>
-      </tp:docstring>
-
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          The contacts whose client types should be returned or signalled.
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" name="Client_Types" type="a{uas}"
-        tp:type="Contact_Client_Types">
-        <tp:docstring>
-          The contacts' client types, if already known. Contacts whose client
-          types are not already known are omitted from the mapping; contacts known
-          to have no client type information appear in the mapping with an empty
-          list.
-        </tp:docstring>
-      </arg>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-      </tp:possible-errors>
-    </method>
-
     <method name="RequestClientTypes" tp:name-for-bindings="Request_Client_Types">
       <tp:docstring>
         Return the current client types of the given contact. If necessary, make
@@ -167,10 +127,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied">
           <tp:docstring>
             The requested contact does not allow the local user to see their
             client type information.
@@ -200,10 +160,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:contact-attribute name="client-types" type="as"
       tp:type="Contact_Client_Type[]">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same mapping that would be returned by
-          <tp:member-ref>GetClientTypes</tp:member-ref> for this contact.
-          Omitted from the result if the contact's client types are not
-          known.</p>
+        <p>The client types of the contact, if they are already known. If the
+        contact's client types are not known, request their current client
+        types, but omit this attribute from the result; if a reply with a
+        non-empty client type array is later received for the contact, the
+        <tp:member-ref>ClientTypesUpdated</tp:member-ref> signal will
+        be emitted.</p>
+
+        <tp:rationale>
+          This attribute is appropriate for "lazy" client type finding, for
+          instance displaying the client types (if available) of everyone in
+          your contact list.
+        </tp:rationale>
       </tp:docstring>
     </tp:contact-attribute>
 
diff --git a/spec/Connection_Interface_Communication_Policy.xml b/spec/Connection_Interface_Communication_Policy1.xml
index 31343de6..33e9c56f 100644
--- a/spec/Connection_Interface_Communication_Policy.xml
+++ b/spec/Connection_Interface_Communication_Policy1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Communication_Policy"
+<node name="/Connection_Interface_Communication_Policy1"
   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">
@@ -19,10 +19,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   </tp:license>
 
   <interface
-     name="org.freedesktop.Telepathy.Connection.Interface.CommunicationPolicy.DRAFT"
+     name="im.telepathy1.Connection.Interface.CommunicationPolicy1"
      tp:causes-havoc="experimental">
     <tp:added version="0.21.1">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"/>
+    <tp:requires interface="im.telepathy1.Connection.Interface.Presence1"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>
@@ -79,8 +79,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <pre>
 {
-    'org.freedesktop.Telepathy.Channel.Type.Text' : Access_Control_Type_Open,
-    'org.freedesktop.Telepathy.Channel.Type.Call' : Access_Control_Type_Publish_List
+    'im.telepathy1.Channel.Type.Text' : Access_Control_Type_Open,
+    'im.telepathy1.Channel.Type.Call' : Access_Control_Type_Publish_List
 }
         </pre>
 
diff --git a/spec/Connection_Interface_Contact_Blocking.xml b/spec/Connection_Interface_Contact_Blocking1.xml
index 756fd4db..594aff31 100644
--- a/spec/Connection_Interface_Contact_Blocking.xml
+++ b/spec/Connection_Interface_Contact_Blocking1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Contact_Blocking" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Contact_Blocking1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009–2011 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -18,9 +18,8 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactBlocking">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList"/>
+  <interface name="im.telepathy1.Connection.Interface.ContactBlocking1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version='0.21.13'>Changes from the draft:
       methods and signals now return <tp:type>Handle_Identifier_Map</tp:type>
       (<code>a{us}</code>) rather than bare lists of contact handles
@@ -46,22 +45,6 @@
         to implement this interface using an on-disk file of blocked
         contacts or some other means to store blocked contacts between
         connections.</p>
-
-      <p>This interface is intended to replace the
-        <tp:dbus-ref namespace="ofdT.Channel.Type">ContactList</tp:dbus-ref>
-        channel with <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
-        <code>List</code> and <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetID</tp:dbus-ref> <code>"deny"</code>
-        (along with the <tp:dbus-ref
-        namespace='ofdT.Connection.Interface'>ContactList</tp:dbus-ref> and
-        <tp:dbus-ref
-        namespace='ofdT.Connection.Interface'>ContactGroups</tp:dbus-ref>
-        interfaces replacing other channels with <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
-        <code>List</code> and <tp:dbus-ref
-        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
-        <code>Group</code>, respectively).</p>
     </tp:docstring>
 
     <method name="BlockContacts" tp:name-for-bindings="Block_Contacts">
@@ -186,7 +169,7 @@
 
         <p>Note that there is no capability for supporting blocking itself:
           the presence of this interface on a <tp:dbus-ref
-          namespace='ofdT'>Connection</tp:dbus-ref> indicates that blocking
+          namespace='imt1'>Connection</tp:dbus-ref> indicates that blocking
           contacts is supported.</p>
       </tp:docstring>
     </property>
diff --git a/spec/Connection_Interface_Contact_Capabilities.xml b/spec/Connection_Interface_Contact_Capabilities1.xml
index fb13c37d..d84f7e47 100644
--- a/spec/Connection_Interface_Contact_Capabilities.xml
+++ b/spec/Connection_Interface_Contact_Capabilities1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Contact_Capabilities" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Contact_Capabilities1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2005, 2006, 2008 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2005, 2006, 2008 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
@@ -18,8 +18,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.ContactCapabilities1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.17.28">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -58,7 +58,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:member name="Well_Known_Name" type="s" tp:type="DBus_Well_Known_Name">
         <tp:docstring>
           For implementations of the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Client</tp:dbus-ref>
+            namespace="im.telepathy1">Client</tp:dbus-ref>
           interface, the well-known bus name name of the client; for any other
           process, any other reversed domain name that uniquely identifies it.
         </tp:docstring>
@@ -69,7 +69,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           An array of channel classes that can be handled by this client.
           This will usually be a copy of the client's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
           property.
         </tp:docstring>
       </tp:member>
@@ -80,7 +80,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           An array of client capabilities supported by this client, to be
           used by the connection manager to determine what capabilities to
           advertise. This will usually be a copy of the client's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref>
+            namespace="im.telepathy1.Client.Handler">Capabilities</tp:dbus-ref>
           property.
         </tp:docstring>
       </tp:member>
@@ -96,7 +96,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           than the ChannelDispatcher SHOULD NOT call this method, and the
           ChannelDispatcher SHOULD use this method to advertise the
           capabilities of all the registered <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>
+            namespace="im.telepathy1">Client.Handler</tp:dbus-ref>
           implementations.On connections not managed by the ChannelDispatcher,
           clients MAY use this method directly, to indicate the channels they
           will handle and the extra capabilities they have.</p>
@@ -105,7 +105,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           will only emit the
           <tp:member-ref>ContactCapabilitiesChanged</tp:member-ref> signal
           for the user's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection">SelfHandle</tp:dbus-ref>
+            namespace="im.telepathy1.Connection">SelfHandle</tp:dbus-ref>
           if, in the underlying protocol, the new capabilities are distinct
           from the previous state.</p>
 
@@ -155,44 +155,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetContactCapabilities"
-            tp:name-for-bindings="Get_Contact_Capabilities">
-      <arg direction="in" name="Handles" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of contact handles for this connection.</p>
-
-          <p>The handle zero MUST NOT be included in the request.</p>
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a{ua(a{sv}as)}"
-           tp:type="Contact_Capabilities_Map" name="Contact_Capabilities">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>A map from contact handles to lists of requestable channel
-            classes, representing the channel requests that are expected
-            to succeed for that contact.</p>
-
-          <p>Contacts listed among Handles whose capabilities are unknown
-            SHOULD be omitted from this map; contacts known to have an empty
-            set of capabilities SHOULD be included in the keys of this map,
-            with an empty array as the corresponding value.</p>
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Returns an array of requestable channel classes for the given
-          contact handles, representing the channel requests that are
-          expected to succeed.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
-          <tp:docstring>
-            The handle does not represent a contact. Zero is always invalid.
-          </tp:docstring>
-        </tp:error>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
       </tp:possible-errors>
     </method>
 
@@ -231,7 +194,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          <p>The contact's capabilities. These should be represented
           in the same way as in <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+            namespace="im.telepathy1.Connection.Interface.Requests"
             >RequestableChannelClasses</tp:dbus-ref>,
           except that they may have more fixed properties or fewer allowed
           properties, to represent contacts who do not have all the
@@ -239,7 +202,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>In particular, requestable channel classes for channels with
           target handle type Contact MUST list <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel"
+            namespace="im.telepathy1.Channel"
             >TargetHandleType</tp:dbus-ref> among their fixed properties when
           they appear here, and clients MAY assume that this will be the
           case.</p>
@@ -254,9 +217,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>Channel classes with target handle type Handle_Type_Contact
           indicate that a request that matches the channel class, and also
           either has the contact's handle as <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel"
+            namespace="im.telepathy1.Channel"
             >TargetHandle</tp:dbus-ref> or the contact's identifier as
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
+          <tp:dbus-ref namespace="im.telepathy1.Channel"
             >TargetID</tp:dbus-ref>, can be expected to succeed. Connection
           managers SHOULD NOT include the TargetHandle or TargetID as a
           fixed property in contact capabilities.</p>
@@ -293,9 +256,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:contact-attribute name="capabilities"
       type="a(a{sv}as)" tp:type="Requestable_Channel_Class[]">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same structs that would be returned by
-          <tp:member-ref>GetContactCapabilities</tp:member-ref>.
-          Omitted from the result if the contact's capabilities
+        <p>Returns an array of requestable channel classes for the given
+          contact, representing the channel requests that are
+          expected to succeed.</p>
+
+        <p>Omitted from the result if the contact's capabilities
           are not known; present in the result as an empty array if the
           contact is known to have no capabilities at all.</p>
       </tp:docstring>
diff --git a/spec/Connection_Interface_Contact_Groups.xml b/spec/Connection_Interface_Contact_Groups1.xml
index 5282a827..68ee9cc1 100644
--- a/spec/Connection_Interface_Contact_Groups.xml
+++ b/spec/Connection_Interface_Contact_Groups1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Contact_Groups" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Contact_Groups1" 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">
@@ -18,9 +18,9 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactGroups">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.ContactList"/>
+  <interface name="im.telepathy1.Connection.Interface.ContactGroups1">
+    <tp:requires interface="im.telepathy1.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection.Interface.ContactList1"/>
     <tp:added version="0.21.0">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -33,7 +33,7 @@
         <tp:token-ref>groups</tp:token-ref> contact attribute (this should
         usually be done by connecting to the GroupsChanged signal, then
         calling <tp:dbus-ref
-          namespace="ofdT.Connection.Interface.ContactList"
+          namespace="imt1.Connection.Interface.ContactList1"
           >GetContactListAttributes</tp:dbus-ref> with this interface
         included in the Interfaces argument). Simple user interfaces can
         limit themselves to displaying that information, and ignore the rest
@@ -148,7 +148,7 @@
           receiving <tp:member-ref>GroupRenamed</tp:member-ref>.</p>
 
         <p>This property's value is not meaningful until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> has become Success.</p>
       </tp:docstring>
     </property>
@@ -263,11 +263,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -281,21 +281,21 @@
       </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.NotAvailable">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>Raised if <tp:member-ref>DisjointGroups</tp:member-ref>
             is true and the list of groups has more than one
             member.</tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -324,11 +324,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -342,16 +342,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -374,11 +374,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -391,16 +391,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -418,11 +418,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -440,16 +440,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -464,11 +464,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -477,15 +477,15 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
@@ -507,11 +507,11 @@
           this method call MUST be emitted before the method returns.</p>
 
         <p>This method SHOULD NOT be called until the
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >ContactListState</tp:dbus-ref> changes to Success.
           If the ContactListState is Failure, this method SHOULD raise the
           same error as
-          <tp:dbus-ref namespace="ofdT.Connection.Interface.ContactList"
+          <tp:dbus-ref namespace="imt1.Connection.Interface.ContactList1"
             >GetContactListAttributes</tp:dbus-ref>.</p>
       </tp:docstring>
 
@@ -524,23 +524,23 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Raised if <tp:member-ref>GroupStorage</tp:member-ref>
             is Contact_Metadata_Storage_Type_None, i.e. groups cannot be edited.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.DoesNotExist">
+        <tp:error name="im.telepathy1.Error.DoesNotExist">
           <tp:docstring>Raised if there is no group with that
             name.</tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>Raised if there is already a group with the new
             name.</tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet"/>
+        <tp:error name="im.telepathy1.Error.NotYet"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Contact_Info.xml b/spec/Connection_Interface_Contact_Info1.xml
index 527d3252..76248e1c 100644
--- a/spec/Connection_Interface_Contact_Info.xml
+++ b/spec/Connection_Interface_Contact_Info1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Contact_Info" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Contact_Info1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2008 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2008 Nokia Corporation </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,9 +17,9 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactInfo">
+  <interface name="im.telepathy1.Connection.Interface.ContactInfo1">
     <tp:added version="0.19.4">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection"/>
 
     <tp:struct name="Contact_Info_Field" array-name="Contact_Info_Field_List">
       <tp:member type="s" name="Field_Name">
@@ -191,28 +191,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
-    <method name="GetContactInfo"
-      tp:name-for-bindings="Get_Contact_Info">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of handles representing contacts.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="ContactInfo" type="a{ua(sasas)}"
-        tp:type="Contact_Info_Map">
-        <tp:docstring>
-          A dictionary mapping contact handles to information, whose keys are
-          the subset of the requested list of handles for which information was
-          cached.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request information on several contacts at once.  This SHOULD only
-        return cached information, omitting handles for which no information is
-        cached from the returned map.
-      </tp:docstring>
-    </method>
-
     <method name="RefreshContactInfo"
       tp:name-for-bindings="Refresh_Contact_Info">
       <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
@@ -233,8 +211,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
       </tp:possible-errors>
     </method>
 
@@ -262,10 +240,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The contact's information could not be retrieved.
           </tp:docstring>
@@ -288,16 +266,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             Setting your own information is not supported on this protocol.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The supplied fields do not match the restrictions specified by
             <tp:member-ref>SupportedFields</tp:member-ref>.
@@ -475,9 +453,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <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>
+              namespace="imt1.Connection.Interface.Aliasing1">SetAliases</tp:dbus-ref>
             or when the Account's <tp:dbus-ref
-              namespace="ofdT.Account">Nickname</tp:dbus-ref>
+              namespace="imt1.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>
@@ -517,8 +495,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         the Push flag.</p>
 
       <p>On protocols with the Push flag set, UIs can connect to
-        <tp:member-ref>ContactInfoChanged</tp:member-ref>, call
-        <tp:member-ref>GetContactInfo</tp:member-ref> once at login for the set
+        <tp:member-ref>ContactInfoChanged</tp:member-ref>, get
+        <tp:token-ref>info</tp:token-ref> attributes once at login for the set
         of contacts they are interested in, and then be sure they will receive
         the latest contact info. On protocols like XMPP, clients can do the
         same, but will receive (at most) opportunistic updates if the info is
@@ -538,10 +516,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:contact-attribute name="info"
       type="a(sasas)" tp:type="Contact_Info_Field[]">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same value that would be returned by
-          <tp:member-ref>GetContactInfo</tp:member-ref> for this contact.
-          Omitted from the result if the contact's info
-          is not known.</p>
+        <p>The contact's information. Omitted from the result if the contact's
+        info is not known.</p>
       </tp:docstring>
     </tp:contact-attribute>
 
diff --git a/spec/Connection_Interface_Contact_List.xml b/spec/Connection_Interface_Contact_List1.xml
index 50a2634c..a1ff6802 100644
--- a/spec/Connection_Interface_Contact_List.xml
+++ b/spec/Connection_Interface_Contact_List1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Contact_List" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Contact_List1" 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">
@@ -18,9 +18,12 @@
       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
       USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ContactList">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.ContactList1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.21.0">(as stable API)</tp:added>
+    <tp:changed version="0.99.1">The deprecated ContactsChanged
+      signal has been replaced with the ContactsChangedWithID
+      version.</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connections that have any concept of a list of
@@ -35,9 +38,7 @@
           any server or roster, it's possible to list "nearby" contacts.</p>
 
         <p>In Telepathy 0.20 and older, we represented contact lists as a
-          collection of <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Type"
-            >ContactList</tp:dbus-ref> channels. This is remarkably difficult to
+          collection of ContactList channels. This is remarkably difficult to
           work with in practice - every client that cares about contact lists
           has to take the union of some hard-to-define set of these
           channels - and conflicts with the idea that channels that cannot
@@ -163,7 +164,7 @@
           <p>A list of strings indicating which D-Bus interfaces the calling
             process is interested in. Equivalent to the corresponding argument
             to <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
+              namespace="im.telepathy1.Connection.Interface.Contacts"
               >GetContactAttributes</tp:dbus-ref>,
             except that if this list does not contain the ContactList
             interface itself, it is treated as though that interface was also
@@ -171,38 +172,27 @@
         </tp:docstring>
       </arg>
 
-      <arg direction="in" name="Hold" type="b">
-        <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:docstring>
-      </arg>
-
       <arg direction="out" type="a{ua{sv}}" name="Attributes"
         tp:type="Contact_Attributes_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary mapping the contact handles to contact attributes,
             equivalent to the result of <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts"
+              namespace="im.telepathy1.Connection.Interface.Contacts"
               >GetContactAttributes</tp:dbus-ref>.</p>
 
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.ServiceBusy"/>
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             <p>The <tp:member-ref>ContactListState</tp:member-ref> is
               None or Waiting. In particular, this error is raised if the
-              <tp:dbus-ref namespace="ofdT.Connection">Status</tp:dbus-ref>
+              <tp:dbus-ref namespace="imt1.Connection">Status</tp:dbus-ref>
               is not yet Connection_Status_Connected.</p>
           </tp:docstring>
         </tp:error>
@@ -264,12 +254,11 @@
         </tp:rationale>
 
         <p>If this attribute is not Yes, the local user cannot generally
-          expect to receive presence from this contact. Their presence status
-          as returned by <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.SimplePresence">GetPresences</tp:dbus-ref>
-          is likely to be (Unknown, "unknown", ""), unless the local user
-          can temporarily see their presence for some other reason (for
-          instance, on XMPP, contacts seen in chatrooms will temporarily
+          expect to receive presence from this contact. Their <tp:token-ref
+            namespace="im.telepathy1.Connection.Interface.Presence1">presence</tp:token-ref>
+          contact attribute is likely to be (Unknown, "unknown", ""), unless the
+          local user can temporarily see their presence for some other reason
+          (for instance, on XMPP, contacts seen in chatrooms will temporarily
           have available presence).</p>
 
         <p>If this attribute is Ask, this indicates that the local user has
@@ -576,8 +565,8 @@
       </tp:member>
     </tp:mapping>
 
-    <signal name="ContactsChangedWithID"
-      tp:name-for-bindings="Contacts_Changed_With_ID">
+    <signal name="ContactsChanged"
+      tp:name-for-bindings="Contacts_Changed">
       <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'
@@ -631,40 +620,6 @@
       </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>
-
     <property name="CanChangeContactList" type="b" access="read"
       tp:name-for-bindings="Can_Change_Contact_List">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -675,7 +630,7 @@
           <tp:member-ref>RemoveContacts</tp:member-ref> methods.</p>
 
         <p>If false, all of those methods will always fail; they SHOULD raise
-          the error org.freedesktop.Telepathy.Error.NotImplemented.</p>
+          the error im.telepathy1.Error.NotImplemented.</p>
 
         <tp:rationale>
           <p>In XEP-0174 "Serverless Messaging" (link-local XMPP), presence is
@@ -708,11 +663,11 @@
         </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
+            namespace="im.telepathy1.Connection.Interface.Aliasing1"
+            >AliasFlags</tp:dbus-ref> property has 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"
+            namespace="im.telepathy1.Connection.Interface.Aliasing1"
             >SetAliases</tp:dbus-ref>.</p>
 
         <p>The user MAY be
@@ -799,16 +754,16 @@
       </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.NotYet">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring>
             The <tp:member-ref>ContactListState</tp:member-ref> is None
             or Waiting.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
             <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
@@ -937,16 +892,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action, because
             <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring>
             The <tp:member-ref>ContactListState</tp:member-ref> is None
             or Waiting.
@@ -999,16 +954,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
             <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring>
             The <tp:member-ref>ContactListState</tp:member-ref> is None
             or Waiting.
@@ -1048,10 +1003,10 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
             <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
@@ -1091,16 +1046,16 @@
       </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.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             It was not possible to perform the requested action because
             <tp:member-ref>CanChangeContactList</tp:member-ref> is false.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+        <tp:error name="im.telepathy1.Error.NotYet">
           <tp:docstring>
             The <tp:member-ref>ContactListState</tp:member-ref> is None
             or Waiting.
@@ -1118,9 +1073,9 @@
       </tp:docstring>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Contacts.xml b/spec/Connection_Interface_Contacts.xml
index ccbdb843..98d2b2bd 100644
--- a/spec/Connection_Interface_Contacts.xml
+++ b/spec/Connection_Interface_Contacts.xml
@@ -18,8 +18,8 @@
       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.Contacts">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Contacts">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.17.9"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -81,16 +81,6 @@
       </tp:member>
     </tp:mapping>
 
-    <property name="ContactAttributeInterfaces" access="read" type="as"
-      tp:type="DBus_Interface[]"
-      tp:name-for-bindings="Contact_Attribute_Interfaces">
-      <tp:docstring>
-        A list of D-Bus interfaces for which
-        <tp:member-ref>GetContactAttributes</tp:member-ref> is expected to work.
-        This cannot change during the lifetime of the Connection.
-      </tp:docstring>
-    </property>
-
     <method name="GetContactAttributes"
       tp:name-for-bindings="Get_Contact_Attributes">
       <tp:docstring>
@@ -111,22 +101,8 @@
             interfaces, whose values can be obtained without additional network
             activity, will be in the reply.</p>
 
-          <p>Connection managers SHOULD ignore interfaces requested which they
-            do not support (i.e. those not mentioned in the
-            <tp:member-ref>ContactAttributeInterfaces</tp:member-ref>
-            property.)</p>
-
-          <tp:rationale>
-            <p>This simplifies client-side code. Clients which care may
-              distinguish between unsupported interfaces (e.g. this Connection
-              does not support Avatars), and interfaces on which no information
-              is known for these contacts (e.g. we don't know the avatar tokens
-              of any of the contacts, so we omitted them all) by inspecting
-              <tp:member-ref>ContactAttributeInterfaces</tp:member-ref>.</p>
-          </tp:rationale>
-
           <p>Attributes from the interface
-            <tp:dbus-ref>org.freedesktop.Telepathy.Connection</tp:dbus-ref>
+            <tp:dbus-ref>im.telepathy1.Connection</tp:dbus-ref>
             are always returned, and need not be requested explicitly.</p>
 
           <p>As well as returning cached information immediately, the
@@ -134,36 +110,15 @@
             values for the contact attributes. If better values are later
             obtained by this process, they will be indicated with the usual
             signals (such as <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing">AliasesChanged</tp:dbus-ref>).</p>
+              namespace="im.telepathy1.Connection.Interface.Aliasing1">AliasesChanged</tp:dbus-ref>).</p>
 
           <tp:rationale>
             For instance, an XMPP connection manager could download vCards
             in response to a request for <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface">Aliasing</tp:dbus-ref>
+              namespace="im.telepathy1.Connection.Interface">Aliasing1</tp:dbus-ref>
             attributes.
           </tp:rationale>
         </tp:docstring>
-        <tp:changed version="0.19.2">
-          requesting information for interfaces not mentioned in
-          <tp:member-ref>ContactAttributeInterfaces</tp:member-ref> is no
-          longer an error. Be aware that older connection managers may still
-          consider this an error.
-        </tp:changed>
-      </arg>
-
-      <arg direction="in" name="Hold" type="b">
-        <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>
-            <p>For further round-trip avoidance.</p>
-          </tp:rationale>
-        </tp:docstring>
       </arg>
 
       <arg direction="out" type="a{ua{sv}}" name="Attributes"
@@ -178,12 +133,12 @@
 
           <p>Each contact's attributes will always include at least the
             identifier that would be obtained by inspecting the handle
-            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>).</p>
+            (<code>im.telepathy1.Connection/contact-id</code>).</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
       </tp:possible-errors>
     </method>
 
@@ -219,8 +174,7 @@
 
       <arg direction="out" name="Handle" type="u" tp:type="Contact_Handle">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>The contact's handle, as returned by <tp:dbus-ref
-          namespace="ofdT.Connection">RequestHandles</tp:dbus-ref></p>
+          <p>The contact's handle</p>
         </tp:docstring>
       </arg>
 
@@ -240,8 +194,8 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
       </tp:possible-errors>
     </method>
   </interface>
diff --git a/spec/Connection_Interface_Forwarding.xml b/spec/Connection_Interface_Forwarding1.xml
index 32c7e1cb..60aab7a5 100644
--- a/spec/Connection_Interface_Forwarding.xml
+++ b/spec/Connection_Interface_Forwarding1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Forwarding"
+<node name="/Connection_Interface_Forwarding1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>
@@ -22,7 +22,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Forwarding.DRAFT"
+  <interface name="im.telepathy1.Connection.Interface.Forwarding1"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
 
@@ -87,12 +87,12 @@
         20s to accept the channel.</p>
 
       <p>When an unanswered <tp:dbus-ref
-          namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref> call is
+          namespace='imt1.Channel.Type'>Call1</tp:dbus-ref> call is
         forwarded, both the contact and the self handle should be removed from
         the group with the self handle as the actor, and
         <tp:type>Channel_Group_Change_Reason</tp:type> <code>No_Answer</code> or
         <code>Busy</code>, as appropriate. For <tp:dbus-ref
-        namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels, the
+        namespace='imt1.Channel.Type'>Call1</tp:dbus-ref> channels, the
         <tp:type>Call_State_Change_Reason</tp:type> <code>Forwarded</code>
         should be used.</p>
     </tp:docstring>
@@ -322,9 +322,9 @@
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The specified Condition is not supported by this connection,
             or the number of chained
@@ -333,7 +333,7 @@
             <tp:member-ref>SetForwardingRule</tp:member-ref>.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
+        <tp:error name="im.telepathy1.Error.InvalidHandle">
           <tp:docstring>
             A Handle that has been supplied is invalid.
           </tp:docstring>
diff --git a/spec/Connection_Interface_IRC_Command1.xml b/spec/Connection_Interface_IRC_Command1.xml
index b30d304b..67bca340 100644
--- a/spec/Connection_Interface_IRC_Command1.xml
+++ b/spec/Connection_Interface_IRC_Command1.xml
@@ -16,8 +16,8 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.IRCCommand1">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.IRCCommand1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.27.3"/>
 
     <method name="Send" tp:name-for-bindings="Send">
@@ -36,9 +36,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
            character set, if different, before sending to the server.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The connection manager MAY raise this error for commands that
             have a more appropriate D-Bus API.
diff --git a/spec/Connection_Interface_Keepalive.xml b/spec/Connection_Interface_Keepalive1.xml
index 9f4ac683..e2c32dcb 100644
--- a/spec/Connection_Interface_Keepalive.xml
+++ b/spec/Connection_Interface_Keepalive1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Keepalive"
+<node name="/Connection_Interface_Keepalive1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -21,9 +21,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Keepalive.DRAFT"
+  <interface name="im.telepathy1.Connection.Interface.Keepalive1"
     tp:causes-havoc="experimental">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.21.2">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -47,10 +47,10 @@
         <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>
+        namespace='im.telepathy1'>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>
+          namespace='im.telepathy1'>Account.Parameters</tp:dbus-ref>
         and passed onto the connection by the account manager.</p>
     </tp:docstring>
 
diff --git a/spec/Connection_Interface_Location.xml b/spec/Connection_Interface_Location1.xml
index c4fd68c3..e451a3c4 100644
--- a/spec/Connection_Interface_Location.xml
+++ b/spec/Connection_Interface_Location1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Location"
+<node name="/Connection_Interface_Location1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
   <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
@@ -18,9 +18,9 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Location">
+  <interface name="im.telepathy1.Connection.Interface.Location1">
     <tp:added version="0.17.27">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface on connections to support protocols which allow users to
@@ -49,11 +49,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         possible.</p>
 
       <p>Clients of this interface SHOULD register an interest in it by calling
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+        <tp:dbus-ref namespace="im.telepathy1"
           >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"
+        <tp:dbus-ref namespace="im.telepathy1"
           >Connection.RemoveClientInterest</tp:dbus-ref> after use to allow
         the CM to release resources associated with this interface.</p>
     </tp:docstring>
@@ -258,54 +258,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:member>
     </tp:mapping>
 
-    <method name="GetLocations" tp:name-for-bindings="Get_Locations">
-      <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>
-          <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[]">
-        <tp:docstring>
-          The contacts whose locations should be returned or signalled.
-        </tp:docstring>
-      </arg>
-
-      <arg direction="out" name="Locations" type="a{ua{sv}}"
-        tp:type="Contact_Locations">
-        <tp:docstring>
-          The contacts' locations, if already known. Contacts whose locations
-          are not already known are omitted from the mapping; contacts known
-          to have no location information appear in the mapping with an empty
-          Location dictionary.
-        </tp:docstring>
-      </arg>
-
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-      </tp:possible-errors>
-    </method>
-
     <method name="RequestLocation" tp:name-for-bindings="Request_Location">
       <tp:docstring>
         Return the current location of the given contact. If necessary, make
@@ -334,10 +286,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied">
           <tp:docstring>
             The requested contact does not allow the local user to see their
             location information.
@@ -383,8 +335,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The user's server does not support publishing their own location.
             If it is possible to determine this ahead of time, the
@@ -392,18 +344,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             <tp:member-ref>SupportedLocationFeatures</tp:member-ref>.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
     <property name="LocationAccessControlTypes" type="au" access="read"
-      tp:type="Rich_Presence_Access_Control_Type[]" tp:name-for-bindings="Location_Access_Control_Types">
+      tp:type="Access_Control_Type[]" tp:name-for-bindings="Location_Access_Control_Types">
       <tp:docstring>The types of access control that are supported by this
         connection.</tp:docstring>
     </property>
 
     <property name="LocationAccessControl" type="(uv)" access="readwrite"
-      tp:type="Rich_Presence_Access_Control" tp:name-for-bindings="Location_Access_Control">
+      tp:type="Access_Control" tp:name-for-bindings="Location_Access_Control">
       <tp:docstring>The current access control mechanism and settings
         for this connection. Before publishing location for the first time,
         if this has not been set by a client, implementations SHOULD
@@ -418,7 +370,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         Indicates the Location features supported by this connection. This
         property MAY be undefined before <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection">Status</tp:dbus-ref>
+          namespace="im.telepathy1.Connection">Status</tp:dbus-ref>
         becomes <code>Connected</code>, but MUST remain constant thereafter.
       </tp:docstring>
     </property>
@@ -441,21 +393,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:contact-attribute name="location"
       type="a{sv}" tp:type="Location">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same mapping that would be returned by
-          <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>
+        <p>The contact's current location, if already known. If contact's
+          location is 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, the <tp:member-ref>LocationUpdated</tp:member-ref>
+          signal will be emitted.</p>
+
+        <tp:rationale>
+          <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>
+
       </tp:docstring>
     </tp:contact-attribute>
 
diff --git a/spec/Connection_Interface_Mail_Notification.xml b/spec/Connection_Interface_Mail_Notification1.xml
index 395e1019..b8ef504e 100644
--- a/spec/Connection_Interface_Mail_Notification.xml
+++ b/spec/Connection_Interface_Mail_Notification1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Mail_Notification"
+<node name="/Connection_Interface_Mail_Notification1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"
   >
   <tp:copyright> Copyright (C) 2007 Collabora Limited </tp:copyright>
@@ -19,8 +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.MailNotification">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    name="im.telepathy1.Connection.Interface.MailNotification1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.21.3">(as stable API)</tp:added>
 
     <tp:client-interest>
@@ -500,9 +500,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
       </tp:possible-errors>
     </method>
 
@@ -538,10 +538,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:rationale>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
       </tp:possible-errors>
     </method>
 
@@ -555,12 +555,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
       <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"
+          namespace="im.telepathy1"
           >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:dbus-ref namespace="org.freedesktop.Telepathy"
+        <tp:dbus-ref namespace="im.telepathy1"
           >Connection.RemoveClientInterest</tp:dbus-ref> to allow the CM to
         release resources.</p>
 
diff --git a/spec/Connection_Interface_Power_Saving.xml b/spec/Connection_Interface_Power_Saving1.xml
index 571bf6d5..c4913807 100644
--- a/spec/Connection_Interface_Power_Saving.xml
+++ b/spec/Connection_Interface_Power_Saving1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Power_Saving"
+<node name="/Connection_Interface_Power_Saving1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"
   >
   <tp:copyright> Copyright © 2007-2010 Collabora Limited </tp:copyright>
@@ -19,7 +19,7 @@ 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">
+    name="im.telepathy1.Connection.Interface.PowerSaving1">
     <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
@@ -72,12 +72,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The current connection has no power saving features.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Presence.xml b/spec/Connection_Interface_Presence.xml
deleted file mode 100644
index 8a344d41..00000000
--- a/spec/Connection_Interface_Presence.xml
+++ /dev/null
@@ -1,346 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Connection_Interface_Presence" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright>
-    Copyright (C) 2005, 2006 Collabora Limited
-  </tp:copyright>
-  <tp:copyright>
-Copyright (C) 2005, 2006 Nokia Corporation
-  </tp:copyright>
-  <tp:copyright>
-Copyright (C) 2006 INdT
-  </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.Presence">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"/>
-
-    <tp:mapping name="Multiple_Status_Map">
-      <tp:docstring>Mapping used in
-        <tp:type>Last_Activity_And_Statuses</tp:type> and passed to
-        <tp:member-ref>SetStatus</tp:member-ref>, representing a collection of
-        statuses. Use of this mapping with more than one member is
-        deprecated.</tp:docstring>
-      <tp:member type="s" name="Status"/>
-      <tp:member type="a{sv}" tp:type="String_Variant_Map" name="Parameters"/>
-    </tp:mapping>
-    <tp:struct name="Last_Activity_And_Statuses" array-name="">
-      <tp:docstring>Structure representing a contact's presence, containing
-        a last-activity time (deprecated) and a Multiple_Status_Map.
-      </tp:docstring>
-      <tp:member type="u" tp:type="Unix_Timestamp" name="Last_Activity"/>
-      <tp:member type="a{sa{sv}}" tp:type="Multiple_Status_Map"
-        name="Statuses"/>
-    </tp:struct>
-    <tp:mapping name="Contact_Presences">
-      <tp:docstring>Mapping returned by
-        <tp:member-ref>GetPresence</tp:member-ref> and signalled by
-        <tp:member-ref>PresenceUpdate</tp:member-ref>, where the keys are
-        contacts and the values represent their presences.</tp:docstring>
-      <tp:member type="u" tp:type="Contact_Handle" name="Contact"/>
-      <tp:member type="(ua{sa{sv}})" tp:type="Last_Activity_And_Statuses"
-        name="Presence"/>
-    </tp:mapping>
-    <tp:struct name="Status_Spec" array-name="">
-      <tp:member type="u" tp:type="Connection_Presence_Type" name="Type"/>
-      <tp:member type="b" name="May_Set_On_Self"/>
-      <tp:member type="b" name="Exclusive"/>
-      <tp:member type="a{ss}" tp:type="String_String_Map"
-        name="Parameter_Types"/>
-    </tp:struct>
-    <tp:mapping name="Status_Spec_Map">
-      <tp:member type="s" name="Identifier"/>
-      <tp:member type="(ubba{ss})" tp:type="Status_Spec" name="Spec"/>
-    </tp:mapping>
-
-    <method name="AddStatus" tp:name-for-bindings="Add_Status">
-      <arg direction="in" name="Status" type="s">
-        <tp:docstring>
-          The string identifier of the desired status
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Parameters" type="a{sv}" tp:type="String_Variant_Map">
-        <tp:docstring>
-          A dictionary of optional parameter names mapped to their variant-boxed values
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that a single presence status is published for the user, along
-        with any desired parameters. Changes will be indicated by
-        <tp:member-ref>PresenceUpdate</tp:member-ref> signals being emitted.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
-    <method name="ClearStatus" tp:name-for-bindings="Clear_Status">
-      <tp:docstring>
-        Request that all of a user's presence statuses be removed. Be aware
-        that this request may simply result in the statuses being replaced by a
-        default available status. Changes will be indicated by
-        <tp:member-ref>PresenceUpdate</tp:member-ref> signals being emitted.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
-    <method name="GetPresence" tp:name-for-bindings="Get_Presence">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of the contacts whose presence should be obtained
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Presence" type="a{u(ua{sa{sv}})}"
-        tp:type="Contact_Presences">
-        <tp:docstring>
-          Presence information in the same format as for the
-          <tp:member-ref>PresenceUpdate</tp:member-ref> signal
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get presence previously emitted by
-        <tp:member-ref>PresenceUpdate</tp:member-ref> for the given contacts.
-        Data is returned in the same structure as the PresenceUpdate signal.
-        Using this method in favour of
-        <tp:member-ref>RequestPresence</tp:member-ref> has the advantage that
-        it will not wake up each client connected to the PresenceUpdate signal.
-      </tp:docstring>
-      <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.NotAvailable"/>
-      </tp:possible-errors>
-    </method>
-    <method name="GetStatuses" tp:name-for-bindings="Get_Statuses">
-      <arg direction="out" type="a{s(ubba{ss})}" tp:type="Status_Spec_Map"
-        name="Available_Statuses">
-        <tp:docstring>
-        A dictionary of string identifiers mapped to a struct for each status, containing:
-        <ul>
-          <li>a type value from one of the values above</li>
-          <li>a boolean to indicate if this status may be set on yourself</li>
-          <li>a boolean to indicate if this is an exclusive status which you
-            may not set alongside any other</li>
-          <li>a dictionary of valid optional string argument names mapped to
-            their types</li>
-        </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get a dictionary of the valid presence statuses for this connection.
-        This is only available when online because only some statuses will
-        be available on some servers.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-    <signal name="PresenceUpdate" tp:name-for-bindings="Presence_Update">
-      <arg name="Presence" type="a{u(ua{sa{sv}})}" tp:type="Contact_Presences">
-        <tp:docstring>
-        A dictionary of contact handles mapped to a struct containing
-        a UNIX timestamp of the last activity time (in UTC), and
-        a dictionary mapping the contact's current status identifiers to
-          a dictionary of optional parameter names mapped to their
-          variant-boxed values
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        This signal should be emitted when your own presence has been changed,
-        or the presence of the member of any of the connection's channels has
-        been changed, or when the presence requested by
-        <tp:member-ref>RequestPresence</tp:member-ref> is available.
-      </tp:docstring>
-    </signal>
-    <method name="RemoveStatus" tp:name-for-bindings="Remove_Status">
-      <arg direction="in" name="Status" type="s">
-        <tp:docstring>
-          The string identifier of the status not to publish anymore for the user
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that the given presence status is no longer published for the
-        user. Changes will be indicated by
-        <tp:member-ref>PresenceUpdate</tp:member-ref> signals being emitted. As
-        with <tp:member-ref>ClearStatus</tp:member-ref>, removing a status may
-        actually result in it being replaced by a default available status.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>The status requested is not currently set</tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-    <method name="RequestPresence" tp:name-for-bindings="Request_Presence">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of the contacts whose presence should be obtained
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request the presence for contacts on this connection. A <tp:member-ref>PresenceUpdate</tp:member-ref>
-        signal will be emitted when they are received. This is not the same as
-        subscribing to the presence of a contact, which must be done using the
-        'subscription' <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel.Type">ContactList</tp:dbus-ref>,
-        and on some protocols presence information may not be available unless
-        a subscription exists.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The presence of the requested contacts is not reported to this connection
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-    <method name="SetLastActivityTime"
-      tp:name-for-bindings="Set_Last_Activity_Time">
-      <arg direction="in" name="Time" type="u" tp:type="Unix_Timestamp">
-        <tp:docstring>
-          A UNIX timestamp of the user's last activity time (in UTC)
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that the recorded last activity time for the user be updated on
-        the server.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            This protocol has no concept of idle time
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-    <method name="SetStatus" tp:name-for-bindings="Set_Status">
-      <arg direction="in" name="Statuses" type="a{sa{sv}}" tp:type="Multiple_Status_Map">
-        <tp:docstring>
-          A dictionary mapping status identifiers to dictionaries, which
-          map optional parameter names to their variant-boxed values
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Request that the user's presence be changed to the given statuses
-          and desired parameters. Changes will be reflected by
-          <tp:member-ref>PresenceUpdate</tp:member-ref>
-          signals being emitted.</p>
-
-        <p>Statuses whose <tp:type>Connection_Presence_Type</tp:type>
-          is Offline, Error or Unknown MUST NOT be passed to this
-          function. Connection managers SHOULD reject these statuses.</p>
-
-        <tp:rationale>
-          <p>The same rationale as for <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence.SetPresence</tp:dbus-ref>
-            applies.</p>
-        </tp:rationale>
-
-        <p>On certain protocols, this method may be
-          called on a newly-created connection which is still in the
-          DISCONNECTED state, and will sign on with the requested status.
-          If the requested status is not available after signing on,
-          NotAvailable will be returned and the connection will remain
-          offline, or if the protocol does not support signing on with
-          a certain status, Disconnected will be returned.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-      </tp:possible-errors>
-    </method>
-
-    <tp:deprecated version="0.17.21">Client implementations
-      SHOULD use <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
-      instead.</tp:deprecated>
-    <tp:changed version="0.17.23">Connection managers implementing
-      Presence MUST implement SimplePresence too.</tp:changed>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-
-      <p>This interface is for services which have a concept of presence which
-        can be published for yourself and monitored on your contacts.
-        Telepathy's definition of presence is based on that used by
-        <a href="http://www.galago-project.org/">the Galago project</a>.</p>
-
-    <p>Presence on an individual (yourself or one of your contacts) is modelled as
-    a last activity time along with a set of zero or more statuses, each of
-    which may have arbitrary key/value parameters. Valid statuses are defined
-    per connection, and a list of them can be obtained with the
-    <tp:member-ref>GetStatuses</tp:member-ref> method.</p>
-
-    <p>(The SimplePresence interface which replaces this one restricts
-      presences to one status per contact, with an optional message, which is
-      in practice all that was implemented on this interface.)</p>
-
-    <p>Each status has an arbitrary string identifier which should have an agreed
-    meaning between the connection manager and any client which is expected to
-    make use of it. The well-known values defined by the <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
-      interface SHOULD be used where possible</p>
-
-    <p>As well as these well-known status identifiers, every status also has a
-    numerical type value chosen from
-    <tp:type>Connection_Presence_Type</tp:type> which can be used by the client
-    to classify even unknown statuses into different fundamental types.</p>
-
-    <p>These numerical types exist so that even if a client does not understand
-    the string identifier being used, and hence cannot present the presence to
-    the user to set on themselves, it may display an approximation of the
-    presence if it is set on a contact.</p>
-
-    <p>The dictionary of variant types allows the connection manager to exchange
-    further protocol-specific information with the client. It is recommended
-    that the string (s) argument 'message' be interpreted as an optional
-    message which can be associated with a presence status.</p>
-
-    <p>If the connection has a 'subscribe' contact list,
-    <tp:member-ref>PresenceUpdate</tp:member-ref> signals should be emitted to
-    indicate changes of contacts on this list, and should also be emitted for
-    changes in your own presence. Depending on the protocol, the signal may
-    also be emitted for others such as people with whom you are communicating,
-    and any user interface should be updated accordingly.</p>
-
-    <p>On some protocols, <tp:member-ref>RequestPresence</tp:member-ref> may
-    only succeed on contacts on your 'subscribe' list, and other contacts will
-    cause a PermissionDenied error.  On protocols where there is no 'subscribe'
-    list, and RequestPresence succeeds, a client may poll the server
-    intermittently to update any display of presence information.</p>
-    </tp:docstring>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Presence1.xml
index 0860f5fe..a49bf4f7 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Presence1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Simple_Presence" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Presence1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2005-2008 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
@@ -19,10 +19,10 @@
       Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.SimplePresence">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Presence1">
+    <tp:requires interface="im.telepathy1.Connection"/>
 
-    <tp:struct name="Simple_Presence">
+    <tp:struct name="Presence">
       <tp:docstring>
         A struct representing the presence of a contact.
       </tp:docstring>
@@ -62,10 +62,9 @@
       </tp:member>
     </tp:struct>
 
-    <tp:mapping name="Simple_Contact_Presences">
+    <tp:mapping name="Contact_Presence_Map">
       <tp:docstring>
-        Mapping returned by <tp:member-ref>GetPresences</tp:member-ref>
-        and signalled by <tp:member-ref>PresencesChanged</tp:member-ref>,
+        Mapping signalled by <tp:member-ref>PresencesChanged</tp:member-ref>,
         indicating the presence of a number of contacts.
       </tp:docstring>
       <tp:member type="u" tp:type="Contact_Handle" name="Contact">
@@ -73,14 +72,14 @@
           A contact
         </tp:docstring>
       </tp:member>
-      <tp:member type="(uss)" tp:type="Simple_Presence" name="Presence">
+      <tp:member type="(uss)" tp:type="Presence" name="Presence">
         <tp:docstring>
           The contact's presence
         </tp:docstring>
       </tp:member>
     </tp:mapping>
 
-    <tp:struct name="Simple_Status_Spec">
+    <tp:struct name="Status_Spec">
       <tp:docstring>
         A struct containing information about a status.
       </tp:docstring>
@@ -112,7 +111,7 @@
       </tp:member>
     </tp:struct>
 
-    <tp:mapping name="Simple_Status_Spec_Map">
+    <tp:mapping name="Status_Spec_Map">
       <tp:docstring>
         A mapping describing possible statuses.
       </tp:docstring>
@@ -122,7 +121,7 @@
           The string identifier of this status.
         </tp:docstring>
       </tp:member>
-      <tp:member type="(ubb)" tp:type="Simple_Status_Spec" name="Spec">
+      <tp:member type="(ubb)" tp:type="Status_Spec" name="Spec">
         <tp:docstring>
           Details of this status.
         </tp:docstring>
@@ -158,7 +157,7 @@
 
           <tp:rationale>
             <p>To go offline, call <tp:dbus-ref
-                namespace="org.freedesktop.Telepathy.Connection">Disconnect</tp:dbus-ref>
+                namespace="im.telepathy1.Connection">Disconnect</tp:dbus-ref>
             instead. The "error" and "unknown" statuses make no sense.</p>
           </tp:rationale>
         </tp:docstring>
@@ -186,8 +185,8 @@
           presences might change upon connecting.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             Either the specified status is not supported, the specified
             status cannot be set on the user themselves, or a non-empty
@@ -195,52 +194,12 @@
             accept a message.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="GetPresences" tp:name-for-bindings="Get_Presences">
-      <arg direction="in" name="Contacts" type="au" tp:type="Contact_Handle[]">
-        <tp:docstring>
-          An array of the contacts whose presence should be obtained.
-        </tp:docstring>
-      </arg>
-      <arg direction="out" name="Presence" type="a{u(uss)}"
-        tp:type="Simple_Contact_Presences">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Presence information in the same format as for the
-            <tp:member-ref>PresencesChanged</tp:member-ref> signal.
-            The returned mapping MUST include an entry for each contact
-            in the method's argument.</p>
-
-          <p>The definition of the connection presence types Unknown
-            and Offline means that if a connection manager will return
-            Unknown for contacts not on the subscribe list, it MUST delay
-            the reply to this method call until it has found out which
-            contacts are, in fact, on the subscribe list.</p>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get presence previously emitted by
-        <tp:member-ref>PresencesChanged</tp:member-ref> for the given
-        contacts. Data is returned in the same structure as the
-        PresencesChanged signal; no additional network requests are made.
-      </tp:docstring>
-      <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:docstring>
-            While discovering the subscribe list in order to distinguish
-            between Unknown and Offline statuses, a network error occurred.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
       </tp:possible-errors>
     </method>
 
     <property name="Statuses" tp:name-for-bindings="Statuses" access="read"
-      type="a{s(ubb)}" tp:type="Simple_Status_Spec_Map">
+      type="a{s(ubb)}" tp:type="Status_Spec_Map">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A dictionary where the keys are the presence statuses that are
           available on this connection, and the values are the corresponding
@@ -320,7 +279,7 @@
     </property>
 
     <signal name="PresencesChanged" tp:name-for-bindings="Presences_Changed">
-      <arg name="Presence" type="a{u(uss)}" tp:type="Simple_Contact_Presences">
+      <arg name="Presence" type="a{u(uss)}" tp:type="Contact_Presence_Map">
         <tp:docstring>
           A dictionary of contact handles mapped to the status,
           presence type and status message.
@@ -337,12 +296,7 @@
       <tp:enumvalue suffix="Unset" value="0">
         <tp:docstring>
           An invalid presence type used as a null value. This value MUST NOT
-          appear in the <tp:member-ref>Statuses</tp:member-ref> property,
-          or in the result of <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Presence">GetStatuses</tp:dbus-ref>
-          on the deprecated <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface">Presence</tp:dbus-ref>
-          interface.
+          appear in the <tp:member-ref>Statuses</tp:member-ref> property.
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Offline" value="1">
@@ -397,11 +351,9 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A type for communication access control. These control
           policies are used in
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">CommunicationPolicy.DRAFT</tp:dbus-ref>
-          as well as most rich presence interfaces.</p>
-
-        <p>New interfaces should use this type, and NOT
-          <tp:type>Rich_Presence_Access_Control_Type</tp:type>.</p>
+          <tp:dbus-ref namespace="imt1.Connection.Interface">CommunicationPolicy1</tp:dbus-ref>
+          and in rich presence interfaces such as
+          <tp:dbus-ref namespace="imt1.Connection.Interface">Location1</tp:dbus-ref>.</p>
       </tp:docstring>
       <tp:enumvalue suffix="Whitelist" value="0">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -415,17 +367,21 @@
       </tp:enumvalue>
       <tp:enumvalue suffix="Publish_List" value="1">
         <tp:docstring>
-          Allow contacts in the user's 'publish' list. The associated
-          variant in <tp:type>Access_Control</tp:type> is ignored.
+          Allow contacts whose
+          <tp:token-ref namespace="imt1.Connection.Interface.ContactList1">publish</tp:token-ref>
+          state is Yes, i.e. those who can normally see the local user's presence.
+          The associated variant in <tp:type>Access_Control</tp:type> is ignored.
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Group" value="2">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Only allow contacts that are in a certain group.</p>
+          <p>Only allow contacts that are in a certain user-defined group, as
+            configured by the <tp:dbus-ref
+              namespace="imt1.Connection.Interface">ContactGroups1</tp:dbus-ref>
+            interface.</p>
 
-          <p>The associated variant in <tp:type>Access_Control</tp:type> is a
-            <tp:type>Group_Handle</tp:type> representing the permitted
-            group.</p>
+          <p>The associated variant in <tp:type>Access_Control</tp:type> is
+            a string (D-Bus type 's'), the name of a contact group.</p>
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Open" value="3">
@@ -436,9 +392,12 @@
       </tp:enumvalue>
       <tp:enumvalue suffix="Subscribe_Or_Publish_List" value="4">
         <tp:docstring>
-          Allow all contacts in the user's 'subscribe' or 'publish'
-          list. The associated variant in <tp:type>Access_Control</tp:type> is
-          ignored.
+          Allow contacts whose
+          <tp:token-ref namespace="imt1.Connection.Interface.ContactList1">subscribe</tp:token-ref>
+          and/or <tp:token-ref namespace="imt1.Connection.Interface.ContactList1">publish</tp:token-ref>
+          state is Yes, i.e. those whose presence can normally be seen by the
+          local user, and those who can normally see the local user's presence.
+          The associated variant in <tp:type>Access_Control</tp:type> is ignored.
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Closed" value="5">
@@ -466,59 +425,12 @@
       </tp:enumvalue>
     </tp:enum>
 
-    <tp:enum name="Rich_Presence_Access_Control_Type" type="u"
-      array-name="Rich_Presence_Access_Control_Type_List">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A type of access control for Rich_Presence_Access_Control.
-          For most types, the exact access control is given by an associated
-          variant.</p>
-
-        <tp:rationale>
-          <p>These are the access control types from XMPP publish/subscribe
-          (XEP-0060).</p>
-        </tp:rationale>
-
-        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
-          uses this for historical reasons, new interfaces will use
-          <tp:type>Access_Control_Type</tp:type>.</p>
-      </tp:docstring>
-
-      <tp:enumvalue suffix="Whitelist" value="0">
-        <tp:docstring>
-          The associated variant is a list of contacts (signature 'au',
-          Contact_Handle[]) who can see the extended presence information.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Publish_List" value="1">
-        <tp:docstring>
-          All contacts in the user's 'publish' contact list can see the
-          extended presence information. The associated variant is ignored.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Group" value="2">
-        <tp:docstring>
-          The associated variant is a handle of type Group (signature 'u',
-          Group_Handle) representing a group of contacts who can see the
-          extended presence information.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Open" value="3">
-        <tp:docstring>
-          Anyone with access to the service can see the extended presence
-          information.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
     <tp:struct name="Access_Control">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>An access control mode for extended presence items like geolocation.
-          This type isn't actually used by the SimplePresence interface, but
+          This type isn't actually used by the Presence interface, but
           it's included here so it can be referenced by rich presence
           interfaces.</p>
-
-        <p>New interfaces should use this type, and NOT
-          <tp:type>Rich_Presence_Access_Control</tp:type>.</p>
       </tp:docstring>
 
       <tp:member name="Type" type="u" tp:type="Access_Control_Type">
@@ -535,40 +447,20 @@
       </tp:member>
     </tp:struct>
 
-    <tp:struct name="Rich_Presence_Access_Control">
+    <tp:contact-attribute name="presence"
+      type="(uss)" tp:type="Presence">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>An access control mode for extended presence items like geolocation.
-          This type isn't actually used by the SimplePresence interface, but
-          it's included here so it can be referenced by rich presence interfaces
-          such as <tp:dbus-ref
-                     namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>.</p>
-
-        <p><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Location</tp:dbus-ref>
-          uses this for historical reasons, new interfaces will use
-          <tp:type>Access_Control_Type</tp:type>.</p>
-      </tp:docstring>
+        <p>The contact's presence.</p>
 
-      <tp:member name="Type" type="u" tp:type="Rich_Presence_Access_Control_Type">
-        <tp:docstring>
-          The type of access control to apply.
-        </tp:docstring>
-      </tp:member>
-      <tp:member name="Detail" type="v">
-        <tp:docstring>
-          Any additional information required by the Type. The required
-          type and semantics are defined for each
-          <tp:type>Rich_Presence_Access_Control_Type</tp:type>.
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
+        <p>The presence is likely to be (Unknown, "unknown", "") unless
+          <tp:token-ref
+            namespace="im.telepathy1.Connection.Interface.ContactList1">subscribe</tp:token-ref>
+          contact attribute is Yes, or the local user can temporarily see their
+          presence for some other reason (for instance, on XMPP, contacts seen
+          in chatrooms will temporarily have available presence).</p>
 
-    <tp:contact-attribute name="presence"
-      type="(uss)" tp:type="Simple_Presence">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The same struct that would be returned by
-          <tp:member-ref>GetPresences</tp:member-ref>
-          (always present with some value if information from the
-          SimplePresence interface was requested)</p>
+        <p>Always present with some value if information if the
+          Presence interface was requested</p>
       </tp:docstring>
     </tp:contact-attribute>
 
diff --git a/spec/Connection_Interface_Privacy.xml b/spec/Connection_Interface_Privacy.xml
deleted file mode 100644
index b89d968f..00000000
--- a/spec/Connection_Interface_Privacy.xml
+++ /dev/null
@@ -1,94 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Connection_Interface_Privacy" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Privacy"
-    tp:causes-havoc='not well-tested'>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
-    <method name="GetPrivacyMode" tp:name-for-bindings="Get_Privacy_Mode">
-      <arg direction="out" type="s">
-        <tp:docstring>
-          A string representing the current privacy mode
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Return the current privacy mode, which must be one of the values
-        returned by GetPrivacyModes.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-    <method name="GetPrivacyModes" tp:name-for-bindings="Get_Privacy_Modes">
-      <arg direction="out" type="as">
-        <tp:docstring>
-          An array of valid privacy modes for this connection
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        Returns the privacy modes available on this connection. The following
-        well-known names should be used where appropriate:
-        <dl>
-          <dt>allow-all</dt><dd>any contact may initiate communication</dd>
-          <dt>allow-specified</dt><dd>only contacts on your 'allow' list may initiate communication</dd>
-          <dt>allow-subscribed</dt><dd>only contacts on your subscription list may initiate communication</dd>
-         </dl>
-       </tp:docstring>
-    </method>
-    <signal name="PrivacyModeChanged"
-      tp:name-for-bindings="Privacy_Mode_Changed">
-      <arg name="Mode" type="s">
-        <tp:docstring>
-          The current privacy mode
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when the privacy mode is changed or the value has been
-        initially received from the server.
-      </tp:docstring>
-    </signal>
-    <method name="SetPrivacyMode" tp:name-for-bindings="Set_Privacy_Mode">
-      <arg direction="in" name="Mode" type="s">
-        <tp:docstring>
-          The desired privacy mode
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that the privacy mode be changed to the given value, which
-        must be one of the values returned by GetPrivacyModes. Success is
-        indicated by the method returning and the PrivacyModeChanged
-        signal being emitted.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-      </tp:possible-errors>
-    </method>
-    <tp:docstring>
-      An interface to support getting and setting privacy modes to configure
-    situations such as not being contactable by people who are not on your
-    subscribe list. If this interface is not implemented, the default can be
-    presumed to be allow-all (as defined in GetPrivacyModes).
-    </tp:docstring>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Interface_Renaming.xml b/spec/Connection_Interface_Renaming1.xml
index 20061185..5a5e2b70 100644
--- a/spec/Connection_Interface_Renaming.xml
+++ b/spec/Connection_Interface_Renaming1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Renaming" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Renaming1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
   <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
@@ -18,20 +18,32 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Renaming">
+  <interface name="im.telepathy1.Connection.Interface.Renaming1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.27.3">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
     <signal name="Renamed" tp:name-for-bindings="Renamed">
       <arg name="Original" type="u" tp:type="Contact_Handle">
         <tp:docstring>
           The handle of the original identifier
         </tp:docstring>
       </arg>
-      <arg name="New" type="u" tp:type="Contact_Handle">
+      <arg name="New_Handle" type="u" tp:type="Contact_Handle">
         <tp:docstring>
           The handle of the new identifier
         </tp:docstring>
       </arg>
+      <arg name="New_Identifier" type="s">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The normalized identifier corresponding to New_Handle.</p>
+
+          <tp:rationale>
+            <p>Providing this immediately means that client libraries
+              can do useful things with this signal (log the change,
+              construct contact objects, etc.) without an additional
+              round-trip to find the corresponding string.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Emitted when the unique identifier of a contact on the server
           changes.</p>
@@ -51,7 +63,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           a channel which has the groups interface, it will be removed from
           the channel and the new handle will be added. The resulting
           <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Group">MembersChanged</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Interface.Group1">MembersChanged</tp:dbus-ref>
           signal must be emitted <em>after</em> the
           <tp:member-ref>Renamed</tp:member-ref> signal; the reason should be
           RENAMED.
@@ -73,18 +85,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request that the user's own identifier is changed on the server.
           If successful, a <tp:member-ref>Renamed</tp:member-ref> signal will
-          be emitted for the current "self handle" as returned by <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection">GetSelfHandle</tp:dbus-ref>.</p>
+          be emitted for the current "self handle" as returned by the <tp:dbus-ref
+            namespace="im.telepathy1.Connection">SelfHandle</tp:dbus-ref>
+          property.</p>
         <p>It is protocol-dependent how the identifier that's actually
           used will be derived from the supplied identifier; some sort of
           normalization might take place.</p>
       </tp:docstring>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotAvailable"/>
+        <tp:error name="im.telepathy1.Error.InvalidArgument"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
     <tp:docstring>
diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
index c8dc3280..8707630b 100644
--- a/spec/Connection_Interface_Requests.xml
+++ b/spec/Connection_Interface_Requests.xml
@@ -21,8 +21,8 @@
       USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Requests">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+  <interface name="im.telepathy1.Connection.Interface.Requests">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.17.11">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -30,12 +30,6 @@
         represent bundles of channels that should be dispatched together, and
         does not assume any particular properties by which channels are
         uniquely identifiable.</p>
-
-      <p>If this interface is implemented on a connection, then
-        <tp:member-ref>NewChannels</tp:member-ref> MUST be emitted for
-        all new channels, even those created with <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection"
-        >RequestChannel</tp:dbus-ref>.</p>
     </tp:docstring>
 
     <tp:struct name="Channel_Details" array-name="Channel_Details_List">
@@ -84,12 +78,12 @@
           </tp:rationale>
 
           <p>Each dictionary MUST contain the keys
-            <tp:dbus-ref>org.freedesktop.Telepathy.Channel.ChannelType</tp:dbus-ref>,
-            <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandleType</tp:dbus-ref>,
-            <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandle</tp:dbus-ref>,
-            <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetID</tp:dbus-ref>
+            <tp:dbus-ref>im.telepathy1.Channel.ChannelType</tp:dbus-ref>,
+            <tp:dbus-ref>im.telepathy1.Channel.TargetHandleType</tp:dbus-ref>,
+            <tp:dbus-ref>im.telepathy1.Channel.TargetHandle</tp:dbus-ref>,
+            <tp:dbus-ref>im.telepathy1.Channel.TargetID</tp:dbus-ref>
             and
-            <tp:dbus-ref>org.freedesktop.Telepathy.Channel.Requested</tp:dbus-ref>.
+            <tp:dbus-ref>im.telepathy1.Channel.Requested</tp:dbus-ref>.
           </p>
 
           <tp:rationale>
@@ -108,16 +102,6 @@
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request that an entirely new channel is created.</p>
-
-        <tp:rationale>
-          <p>There is deliberately no flag corresponding to the
-            suppress_handler argument to
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.RequestChannel</tp:dbus-ref>,
-            because passing a FALSE value for that argument is deprecated.
-            Requests made using this interface always behave as though
-            suppress_handler was TRUE.</p>
-        </tp:rationale>
-
       </tp:docstring>
 
       <arg direction="in" name="Request" type="a{sv}"
@@ -125,7 +109,7 @@
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary containing desirable properties, which MUST include
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>.
+              namespace="im.telepathy1.Channel">ChannelType</tp:dbus-ref>.
             Some properties
             are defined such that only an exact match makes sense, and
             connection managers MUST NOT satisfy a request with a channel
@@ -184,9 +168,9 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The channel request was one that can never succeed,
             such as requesting an unsupported channel type, or requesting
@@ -194,42 +178,42 @@
             the given target handle type.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
+        <tp:error name="im.telepathy1.Error.InvalidHandle">
           <tp:docstring>
             An invalid handle was requested as the value of a property whose
             value is a handle (like
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.TargetHandle</tp:dbus-ref>),
+            <tp:dbus-ref namespace="im.telepathy1">Channel.TargetHandle</tp:dbus-ref>),
             or a syntactically invalid identifier was requested as the value
             of a property whose value is the string corresponding to a handle
             (like <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.TargetID</tp:dbus-ref>).
+            namespace="im.telepathy1">Channel.TargetID</tp:dbus-ref>).
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The request matched the fixed properties of a
             <tp:type>Requestable_Channel_Class</tp:type> in
             <tp:member-ref>RequestableChannelClasses</tp:member-ref>, but the
             allowed arguments did not make sense; for example, a <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">RoomList</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type">RoomList1</tp:dbus-ref>
             was requested, but the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.RoomList">Server</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type.RoomList1">Server</tp:dbus-ref>
             property provided was not a valid DNS name.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
+        <tp:error name="im.telepathy1.Error.NotCapable">
           <tp:docstring>
             The requested channel cannot be created because the requested
             contact is using a client that lacks a particular feature.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Offline">
+        <tp:error name="im.telepathy1.Error.Offline">
           <tp:docstring>
             The requested channel cannot be created because the target is
             offline.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
             <p>The requested channel cannot be created, but in
               principle, a similar request might succeed in future.
@@ -242,17 +226,15 @@
               <li>a channel matching the request has already been requested
                 (by a previous call to CreateChannel,
                 <tp:member-ref>EnsureChannel</tp:member-ref>,
-                <tp:dbus-ref
-                  namespace="org.freedesktop.Telepathy">Connection.RequestChannel</tp:dbus-ref>
                 or similar) and the protocol requires that only one such
                 channel can exist at a time</li>
             </ul>
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Banned"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Full"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.InviteOnly"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.Channel.Banned"/>
+        <tp:error name="im.telepathy1.Error.Channel.Full"/>
+        <tp:error name="im.telepathy1.Error.Channel.InviteOnly"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
@@ -330,9 +312,9 @@
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The channel request was one that can never succeed,
             such as requesting an unsupported channel type, or requesting
@@ -340,102 +322,84 @@
             the given target handle type.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle">
+        <tp:error name="im.telepathy1.Error.InvalidHandle">
           <tp:docstring>
             An invalid handle was requested as the value of a property whose
             value is a handle (like
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.TargetHandle</tp:dbus-ref>),
+            <tp:dbus-ref namespace="im.telepathy1">Channel.TargetHandle</tp:dbus-ref>),
             or a syntactically invalid identifier was requested as the value
             of a property whose value is the string corresponding to a handle
             (like <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Channel.TargetID</tp:dbus-ref>).
+            namespace="im.telepathy1">Channel.TargetID</tp:dbus-ref>).
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The request matched the fixed properties of a
             <tp:type>Requestable_Channel_Class</tp:type> in
             <tp:member-ref>RequestableChannelClasses</tp:member-ref>, but the
             allowed arguments did not make sense; for example, a <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">RoomList</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type">RoomList1</tp:dbus-ref>
             was requested, but the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type.RoomList">Server</tp:dbus-ref>
+              namespace="im.telepathy1.Channel.Type.RoomList1">Server</tp:dbus-ref>
             property provided was not a valid DNS name.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
+        <tp:error name="im.telepathy1.Error.NotCapable">
           <tp:docstring>
             The requested channel cannot be created because the requested
             contact is using a client that lacks a particular feature.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Offline">
+        <tp:error name="im.telepathy1.Error.Offline">
           <tp:docstring>
             The requested channel cannot be created because the target is
             offline.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The requested channel cannot be created, but in
             principle, a similar request might succeed in future.
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Banned"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.Full"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.Channel.InviteOnly"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+        <tp:error name="im.telepathy1.Error.Channel.Banned"/>
+        <tp:error name="im.telepathy1.Error.Channel.Full"/>
+        <tp:error name="im.telepathy1.Error.Channel.InviteOnly"/>
+        <tp:error name="im.telepathy1.Error.PermissionDenied"/>
       </tp:possible-errors>
     </method>
 
     <signal name="NewChannels" tp:name-for-bindings="New_Channels">
       <tp:added version="0.17.11">(as stable API)</tp:added>
       <tp:changed version="0.17.14">Added a guarantee of ordering
-        relative to NewChannel</tp:changed>
+        relative to the old NewChannel signal (now removed)</tp:changed>
+      <tp:changed version="0.27.1">Added recommendation against
+        announcing channels together</tp:changed>
 
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>New channels have been created. The connection manager SHOULD emit
-          a single signal for any group of closely related channels that are
-          created at the same time, so that the channel dispatcher can try to
-          dispatch them to a handler as a unit.</p>
+        <p>A new channel has been created. The connection manager
+          SHOULD emit a single signal for each channel created.</p>
 
-        <p>In particular, if additional channels are created as a side-effect
-          of a call to <tp:member-ref>CreateChannel</tp:member-ref>,
-          these channels SHOULD appear in the same NewChannels signal as
-          the channel that satisfies the request.</p>
+        <p>For example, joining a MUC Tube in XMPP requires joining the
+          corresponding MUC (chatroom). Either the connection manager
+          should announce a new <tp:dbus-ref
+          namespace="imt1.Channel.Type">Text</tp:dbus-ref> channel
+          separately, or not expose the Text channel on the bus
+          until it's actually requested (or an incoming message
+          appears).</p>
 
         <tp:rationale>
-          <p>Joining a MUC Tube in XMPP requires joining the corresponding
-            MUC (chatroom), so a <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>
-            channel can be created as a side-effect.</p>
-        </tp:rationale>
-
-        <p>Every time NewChannels is emitted, it MUST be followed by
-          a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection.NewChannel</tp:dbus-ref>
-          signal for each channel.</p>
-
-        <tp:rationale>
-          <p>The double signal emission is for the benefit of older Telepathy
-            clients, which won't be listening for NewChannels.</p>
-
-          <p>The more informative NewChannels signal comes first so that
-            clients that did not examine the connection to find
-            out whether Requests is supported will see the more informative
-            signal for each channel first, and then ignore the less
-            informative signal because it announces a new channel of which
-            they are already aware.</p>
+          <p>Signalling the creation of multiple channels together
+            makes writing simple clients much more complicated, can
+            result in lost messages, and isn't nearly as useful in
+            practice as it sounds.</p>
         </tp:rationale>
       </tp:docstring>
 
       <arg name="Channels" type="a(oa{sv})" tp:type="Channel_Details[]">
         <tp:docstring>
-          The channels and their details. All channels that are signalled
-          together like this MUST have the same
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.FUTURE">Bundle</tp:dbus-ref>
-          property, which may
-          either refer to an existing bundle, or establish a new bundle.
+          The channels and their details.
         </tp:docstring>
       </arg>
     </signal>
@@ -459,7 +423,7 @@
 
         <tp:rationale>
           This is redundant with the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel">Closed</tp:dbus-ref>
+            namespace="im.telepathy1.Channel">Closed</tp:dbus-ref>
           signal on the channel itself, but it does provide full change
           notification for the Channels property.
         </tp:rationale>
@@ -483,13 +447,9 @@
           a subset of their properties.</p>
 
         <p>Channel classes SHOULD always include the keys
-          <tp:dbus-ref>org.freedesktop.Telepathy.Channel.ChannelType</tp:dbus-ref>
+          <tp:dbus-ref>im.telepathy1.Channel.ChannelType</tp:dbus-ref>
           and
-          <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandleType</tp:dbus-ref>.
-          (One exception is that <tp:dbus-ref namespace="ofdT.Channel.Type"
-            >ContactSearch</tp:dbus-ref> channels do not have TargetHandleType
-          <code>None</code> in their requestable channel classes, for
-          historical reasons.)</p>
+          <tp:dbus-ref>im.telepathy1.Channel.TargetHandleType</tp:dbus-ref>.</p>
       </tp:docstring>
 
       <tp:member type="s" name="Key" tp:type="DBus_Qualified_Member">
@@ -586,15 +546,6 @@
               between the properties, so we do not have separate arrays
               of required and optional properties.</p>
           </tp:rationale>
-
-          <p>If this array contains the
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.FUTURE">Bundle</tp:dbus-ref>
-            property, then this class of channel can be combined with other
-            channels with that property in a request, or added to an existing
-            bundle. If not, this signifies that the connection manager is
-            unable to mark channels of this class as part of a bundle - this
-            means that to the remote contact they are likely to be
-            indistinguishable from channels requested separately.</p>
         </tp:docstring>
       </tp:member>
     </tp:struct>
diff --git a/spec/Connection_Interface_Resources.xml b/spec/Connection_Interface_Resources1.xml
index 716089cd..ca7dddd3 100644
--- a/spec/Connection_Interface_Resources.xml
+++ b/spec/Connection_Interface_Resources1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Resources"
+<node name="/Connection_Interface_Resources1"
   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">
@@ -17,10 +17,10 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.Resources.DRAFT"
+  <interface name="im.telepathy1.Connection.Interface.Resources1"
     tp:causes-havoc="experimental">
     <tp:added version="0.21.1">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+    <tp:requires interface="im.telepathy1.Connection"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface on connections to show contact attributes for
@@ -45,16 +45,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         attempts to change this.</p>
 
       <p>When using this interface, it is a little like using the
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface"
+        <tp:dbus-ref namespace="im.telepathy1.Connection.Interface"
         >Contacts</tp:dbus-ref> interface, but only resource-specific
         attributes are ever returned. The resource-specific contact
         attributes are decided on by the CM, but XMPP's are listed
         below:</p>
 
       <ul>
-        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence/presence</tp:dbus-ref></li>
-        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities/capabilities</tp:dbus-ref></li>
-        <li><tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ClientTypes/client-types</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="im.telepathy1.Connection.Interface">Presence1/presence</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="im.telepathy1.Connection.Interface">ContactCapabilities1/capabilities</tp:dbus-ref></li>
+        <li><tp:dbus-ref namespace="im.telepathy1.Connection.Interface">ClientTypes1/client-types</tp:dbus-ref></li>
       </ul>
 
     </tp:docstring>
@@ -91,8 +91,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="im.telepathy1.Error.Disconnected"/>
+        <tp:error name="im.telepathy1.Error.InvalidHandle"/>
       </tp:possible-errors>
     </method>
 
diff --git a/spec/Connection_Interface_Service_Point.xml b/spec/Connection_Interface_Service_Point1.xml
index b135c04c..a650141b 100644
--- a/spec/Connection_Interface_Service_Point.xml
+++ b/spec/Connection_Interface_Service_Point1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Interface_Service_Point" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+<node name="/Connection_Interface_Service_Point1" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
   <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,7 +17,7 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Connection.Interface.ServicePoint">
+  <interface name="im.telepathy1.Connection.Interface.ServicePoint1">
     <tp:added version="0.19.7">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -43,7 +43,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           A list of IDs that are mapped to this service. This is provided as
           a convenience for the UIs, but the preferred method for
           requesting channel to a service is by setting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.ServicePoint">InitialServicePoint</tp:dbus-ref>
+            namespace="im.telepathy1.Channel.Interface.ServicePoint1">InitialServicePoint</tp:dbus-ref>
             property in a channel request.
         </tp:docstring>
       </tp:member>
diff --git a/spec/Connection_Interface_Sidecars1.xml b/spec/Connection_Interface_Sidecars1.xml
index c303fcbe..9ef67f3e 100644
--- a/spec/Connection_Interface_Sidecars1.xml
+++ b/spec/Connection_Interface_Sidecars1.xml
@@ -1,29 +1,36 @@
 <?xml version="1.0" ?>
 <node name="/Connection_Interface_Sidecars1"
-  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"
-  >
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright © 2009-2013 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 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>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>
+    <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.Sidecars1">
-    <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
+
+  <interface name="im.telepathy1.Connection.Interface.Sidecars1">
+    <tp:requires interface="im.telepathy1.Connection"/>
     <tp:added version="0.27.3"/>
 
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>A <a href="http://en.wikipedia.org/wiki/Sidecar">sidecar</a>
+        is an object with a particular interface which provides
+        additional connection-specific functionality. This interface
+        serves as a way to ensure these sidecars.</p>
+    </tp:docstring>
+
     <method name="EnsureSidecar" tp:name-for-bindings="Ensure_Sidecar">
       <tp:added version="0.27.3">(as stable API)</tp:added>
 
@@ -75,23 +82,19 @@ USA.</p>
             in a dictionary, build a proxy object from the value). More
             “plural” plugins are likely to want to implement new types of
             <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>
+              namespace="im.telepathy1">Channel</tp:dbus-ref>
             instead.</p>
         </tp:rationale>
       </tp:docstring>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+      <tp:error name="im.telepathy1.Error.NotImplemented">
         <tp:docstring>
           The requested sidecar is not implemented by this connection manager,
-          or a necessary server-side component does not exist. (FIXME: split
-          these two errors out? Then again, once we list the guaranteed and
-          possible sidecars on a Protocol object, clients can tell the
-          difference themselves, because they shouldn't be calling this in the
-          first case.)
+          or a necessary server-side component does not exist.
         </tp:docstring>
       </tp:error>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.ServiceBusy">
+      <tp:error name="im.telepathy1.Error.ServiceBusy">
         <tp:docstring>
           A server-side component needed by the requested sidecar reported it
           is currently too busy, or did not respond for some
@@ -99,7 +102,7 @@ USA.</p>
         </tp:docstring>
       </tp:error>
 
-      <tp:error name="org.freedesktop.Telepathy.Error.Cancelled">
+      <tp:error name="im.telepathy1.Error.Cancelled">
         <tp:docstring>
           The connection was disconnected while the sidecar was being set up.
         </tp:docstring>
@@ -108,3 +111,4 @@ USA.</p>
 
   </interface>
 </node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml
index ada5057d..b9bfe81a 100644
--- a/spec/Connection_Manager.xml
+++ b/spec/Connection_Manager.xml
@@ -18,13 +18,14 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.ConnectionManager">
+  <interface name="im.telepathy1.ConnectionManager">
 
     <tp:simple-type name="Connection_Manager_Name" type="s">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of a connection manager, found in its well-known
           bus name and object path. This must be a non-empty string of
-          ASCII letters, digits and underscores, starting with a letter.
+          ASCII letters, digits and underscores, starting with a letter
+          or underscore.
           This is typically the name of the executable with any "telepathy-"
           prefix removed, and any hyphen/minus signs replaced by
           underscores.</p>
@@ -56,11 +57,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         characters were not specified</tp:changed>
     </tp:simple-type>
 
-    <tp:simple-type name="Protocol" type="s" array-name="Protocol_List">
+    <tp:simple-type name="Protocol_Name" type="s" array-name="Protocol_Name_List">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>An instant messaging protocol. It must consist only of ASCII
-          letters, digits and hyphen/minus signs (U+002D "-"), and must start
-          with a letter. Where possible, this SHOULD be
+          letters, digits and underscores, and must start
+          with a letter or underscore. Where possible, this SHOULD be
           chosen from the following well-known values:</p>
 
         <ul>
@@ -70,7 +71,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <li>icq - ICQ (OSCAR)</li>
           <li>irc - Internet Relay Chat (RFC 1459, 2810-2813)</li>
           <li>jabber - XMPP (RFC 3920, 3921) or Jabber</li>
-          <li>local-xmpp - Link-local XMPP (XEP-0174) (Bonjour, Salut)</li>
+          <li>local_xmpp - Link-local XMPP (XEP-0174) (Bonjour, Salut)</li>
           <li>msn - MSNP (Windows Live Messenger)</li>
           <li>myspace - MySpaceIM</li>
           <li>mxit - MXit</li>
@@ -89,14 +90,28 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <li>yahoojp - Japanese version of YMSG</li>
           <li>zephyr - Zephyr</li>
         </ul>
+
+        <tp:rationale>
+          <p>Identifiers formed with letters, digits and underscores and not
+            starting with a digit are valid in all syntactically-restricted
+            strings used in D-Bus, and non-problematic in filenames.</p>
+
+          <p>Telepathy 0.x used hyphen/minus instead of underscore in the
+            canonical form of a protocol name, which meant that protocol
+            names often had to be transformed between their canonical form,
+            and a form that used underscores for use in a D-Bus name.</p>
+        </tp:rationale>
       </tp:docstring>
       <tp:changed version="0.17.1">Prior to version 0.17.1, the allowed
         characters were not specified</tp:changed>
+      <tp:changed version="0.99.1">
+        In Telepathy 0.x, protocol names could contain hyphen/minus signs,
+        but not underscores.
+      </tp:changed>
     </tp:simple-type>
 
     <tp:struct name="Param_Spec" array-name="Param_Spec_List">
-      <tp:docstring>A struct representing an allowed parameter, as returned
-        by GetParameters on the ConnectionManager interface.</tp:docstring>
+      <tp:docstring>A struct representing an allowed parameter.</tp:docstring>
       <tp:member type="s" name="Name">
         <tp:docstring>A string parameter name</tp:docstring>
       </tp:member>
@@ -128,9 +143,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:flag>
       <tp:flag suffix="Has_Default" value="4">
         <tp:docstring>
-          This parameter has a default value, which is returned in
-          GetParameters; not providing this parameter is equivalent to
-          providing the default.
+          This parameter has a default value; not providing this
+          parameter is equivalent to providing the default.
         </tp:docstring>
       </tp:flag>
       <tp:flag suffix="Secret" value="8">
@@ -150,7 +164,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>This parameter is also a D-Bus property on the resulting
             <tp:dbus-ref
-              namespace="ofdT">Connection</tp:dbus-ref>; a
+              namespace="imt1">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
@@ -158,7 +172,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             <code>org.freedesktop.DBus.Properties</code> interface.</p>
 
           <p>When a new value for a parameter with this flag is passed to
-            <tp:dbus-ref namespace="ofdT">Account.UpdateParameters</tp:dbus-ref>,
+            <tp:dbus-ref namespace="imt1">Account.UpdateParameters</tp:dbus-ref>,
             the account manager will attempt to update its value on any running
             connections. Similarly, if the parameter also has the
             <code>Has_Default</code> flag, and is passed in the second argument
@@ -166,16 +180,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             to 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:dbus-ref namespace="imt1">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
+              namespace='imt1'>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>
+                namespace='imt1.Connection.Interface'>Cellular1</tp:dbus-ref>
               preferences.</p>
           </tp:rationale>
         </tp:docstring>
@@ -183,46 +197,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:flag>
     </tp:flags>
 
-    <method name="GetParameters" tp:name-for-bindings="Get_Parameters">
-      <arg direction="in" name="Protocol" type="s" tp:type="Protocol">
-        <tp:docstring>
-          The required protocol name
-        </tp:docstring>
-      </arg>
-      <arg direction="out" type="a(susv)" tp:type="Param_Spec[]"
-        name="Parameters">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          An array of structs representing possible parameters.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get a list of the parameters which may be specified in the
-        <tp:dbus-ref namespace='ofdT.Account'>Parameters</tp:dbus-ref> of an
-        <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> (or, for
-        specialised applications which do not use the account manager, passed
-        to <tp:member-ref>RequestConnection</tp:member-ref>). Some parameters
-        are mandatory, and some parameters only make sense when registering new
-        accounts with the server; see the <tp:type>Param_Spec</tp:type>
-        documentation for more details.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
-          <tp:docstring>
-            The requested protocol is not supported by this manager
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
     <tp:mapping name="Protocol_Properties_Map">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A map from protocol identifiers supported by a connection
           manager to the immutable properties of the corresponding
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Protocol</tp:dbus-ref> objects.</p>
       </tp:docstring>
 
-      <tp:member name="Protocol" type="s" tp:type="Protocol">
+      <tp:member name="Name" type="s" tp:type="Protocol_Name">
         <tp:docstring>A protocol name</tp:docstring>
       </tp:member>
 
@@ -239,7 +222,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A map from protocol identifiers supported by this connection
           manager to the immutable properties of the corresponding
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Protocol</tp:dbus-ref> objects.</p>
 
         <tp:rationale>
@@ -248,25 +231,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             most clients will only need one D-Bus round trip to interrogate
             the ConnectionManager about all its protocols.</p>
         </tp:rationale>
-
-        <p>If this map is empty or missing, clients SHOULD fall back to
-          calling <tp:member-ref>ListProtocols</tp:member-ref> and
-          <tp:member-ref>GetParameters</tp:member-ref>.</p>
       </tp:docstring>
     </property>
 
-    <method name="ListProtocols" tp:name-for-bindings="List_Protocols">
-      <arg direction="out" type="as" tp:type="Protocol[]" name="Protocols">
-        <tp:docstring>
-          The keys of the <tp:member-ref>Protocols</tp:member-ref> map.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Get a list of protocol identifiers that are implemented by this
-        connection manager.
-      </tp:docstring>
-    </method>
-
     <signal name="NewConnection" tp:name-for-bindings="New_Connection">
       <arg name="Bus_Name" type="s" tp:type="DBus_Bus_Name">
         <tp:docstring>
@@ -278,20 +245,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           The object path of the Connection object on this service
         </tp:docstring>
       </arg>
-      <arg name="Protocol" type="s" tp:type="Protocol">
+      <arg name="Protocol" type="s" tp:type="Protocol_Name">
         <tp:docstring>
           The identifier for the protocol this connection uses
         </tp:docstring>
       </arg>
       <tp:docstring>
         Emitted when a new <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref> object
+        namespace="im.telepathy1">Connection</tp:dbus-ref> object
         is created.
       </tp:docstring>
     </signal>
 
     <method name="RequestConnection" tp:name-for-bindings="Request_Connection">
-      <arg direction="in" name="Protocol" type="s" tp:type="Protocol">
+      <arg direction="in" name="Protocol" type="s" tp:type="Protocol_Name">
         <tp:docstring>
           The protocol identifier
         </tp:docstring>
@@ -299,9 +266,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <arg direction="in" name="Parameters" type="a{sv}"
         tp:type="String_Variant_Map">
         <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 well-known list of names and value types documented on the
+          A dictionary mapping parameter names to values of the
+          appropriate type, as indicated by the <tp:dbus-ref
+          namespace="imt1.Protocol">Parameters</tp:dbus-ref> property
+          (which can be retrieved by getting the
+          <tp:member-ref>Protocols</tp:member-ref> property) and the
+          well-known list of names and value types documented on the
           <tp:type>Connection_Parameter_Name</tp:type> type.
         </tp:docstring>
       </arg>
@@ -317,31 +287,34 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Request a
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>
           object representing a given account on a given
           protocol with the given parameters. The method returns the bus name
           and the object path where the new Connection object can be found,
           which should have the status of Connection_Status_Disconnected, to
           allow signal handlers to be attached before connecting is started
           with the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">Connect</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Connection">Connect</tp:dbus-ref>
           method.</p>
 
         <p><strong>Most applications should not use this method</strong>: they
           should instead use the the <tp:dbus-ref
-          namespace='ofdT.Account'>Connection</tp:dbus-ref> property on an
-          <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> object obtained
+          namespace='imt1.Account'>Connection</tp:dbus-ref> property on an
+          <tp:dbus-ref namespace='imt1'>Account</tp:dbus-ref> object obtained
           from the <tp:dbus-ref
-          namespace='ofdT'>AccountManager</tp:dbus-ref>. This method is used
+          namespace='imt1'>AccountManager</tp:dbus-ref>. This method is used
           internally by the account manager to create connections when
           needed.</p>
 
-        <p>The parameters which must and may be provided in the parameters
-        dictionary can be discovered with the
-        <tp:member-ref>GetParameters</tp:member-ref> method. These
-        parameters, their types, and their default values may be cached
-        in files so that all available connection managers do not need to be
-        started to discover which protocols are available.</p>
+        <p>The parameters which must and may be provided in the
+        parameters dictionary can be discovered by looking at the
+        <tp:dbus-ref
+        namespace="imt1.Protocol">Parameters</tp:dbus-ref> property by
+        getting the <tp:member-ref>Protocols</tp:member-ref>
+        property. These parameters, their types, and their default
+        values may be cached in files so that all available connection
+        managers do not need to be started to discover which protocols
+        are available.</p>
 
         <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
@@ -367,18 +340,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         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:error name="im.telepathy1.Error.NetworkError"/>
+        <tp:error name="im.telepathy1.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:error name="im.telepathy1.Error.NotAvailable">
           <tp:docstring>
             The requested connection already appears to exist
           </tp:docstring>
         </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             Unrecognised connection parameters
           </tp:docstring>
@@ -392,7 +365,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <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
+          namespace='imt1.Protocol'>Parameters</tp:dbus-ref> that may be passed
           to <tp:member-ref>RequestConnection</tp:member-ref>.</p>
 
         <dl>
@@ -446,7 +419,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
               pings.</p>
 
             <p>This parameter is superseded by the <tp:dbus-ref
-                namespace='ofdT.Connection.Interface.Keepalive.DRAFT'>KeepaliveInterval</tp:dbus-ref>
+                namespace='imt1.Connection.Interface.Keepalive1'>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
@@ -475,10 +448,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           defined; it's provided as a hook for possible future
           functionality.</p>
 
-        <p>To be compatible with older connection managers, if retrieving
-          this property fails, clients SHOULD assume that its value is
-          an empty list.</p>
-
         <p>Connection managers with a non-empty list of Interfaces MUST
           represent them in the <code>.manager</code> file, if they have one,
           as an <code>Interfaces</code> key in the
@@ -497,7 +466,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:type>Connection_Manager_Name</tp:type> for syntax).</p>
 
     <p>The connection manager must then provide a well-known bus name of
-      <code>org.freedesktop.Telepathy.ConnectionManager.<em>cmname</em></code>
+      <code>im.telepathy1.ConnectionManager.<em>cmname</em></code>
       where <em>cmname</em> is its connection manager name. If it makes sense
       to start the connection manager using D-Bus service activation, it
       must register that well-known name for service activation by installing
@@ -512,14 +481,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <p>When the connection manager is running, it must have an object
       implementing the ConnectionManager interface at the object path
-      <code>/org/freedesktop/Telepathy/ConnectionManager/<em>cmname</em></code>.
+      <code>/im/telepathy1/ConnectionManager/<em>cmname</em></code>.
     </p>
 
     <p>Connection managers' capabilities can be determined dynamically by
-      calling their <tp:member-ref>ListProtocols</tp:member-ref> method, then
-      for each protocol of interest, calling
-      <tp:member-ref>GetParameters</tp:member-ref> to discover the required and
-      optional parameters.
+      getting the <tp:member-ref>Protocols</tp:member-ref> property.
       However, since it is inefficient to activate all possible connection
       managers on the system just to find out what they can do, there
       is a standard mechanism to store static information about CMs in
@@ -532,8 +498,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       defaulting to $HOME/.local/share if unset, followed by
       colon-separated paths from $XDG_DATA_DIRS, defaulting to
       /usr/local/share:/usr/share if unset) for the first file named
-      <code>telepathy/managers/<em>cmname</em>.manager</code> that can be
-      read without error. This file has the same syntax as a
+      <code>telepathy-1/managers/<em>cmname</em>.manager</code> that can be
+      read without error and contains a group whose name is the name of this
+      interface. This file has the same syntax as a
       <a href="http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html">freedesktop.org Desktop Entry file</a>.</p>
 
     <p>Clients must still support connection managers for which no
@@ -544,31 +511,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       a plugin architecture) should not install a <code>.manager</code>
       file.</p>
 
-    <p>The <code>.manager</code> file SHOULD have a group headed
-      <code>[ConnectionManager]</code>, containing a key
+    <p>The <code>.manager</code> file MUST have a group headed
+      <code>[im.telepathy1.ConnectionManager]</code>, containing a key
       <code>Interfaces</code> representing
       <tp:member-ref>Interfaces</tp:member-ref> as a sequence of strings
       each followed by a semicolon (the "localestrings" type from the Desktop
       Entry Specification).</p>
 
-    <p>The <code>[ConnectionManager]</code> group SHOULD NOT contain keys
-      <code>ObjectPath</code> or <code>BusName</code>. If it does, they MUST
-      be ignored.</p>
-
-    <tp:rationale>
-      <p>The object path and bus name are derivable from the connection
-        manager's name, which is part of the filename, so these keys are
-        redundant. They were required in very old versions of Telepathy.</p>
-    </tp:rationale>
-
     <p>For each protocol name <em>proto</em> that would be returned by
-      ListProtocols, the .manager file contains a group
-      headed <code>[Protocol <em>proto</em>]</code>. For each parameter
-      <em>p</em> that would be returned by GetParameters(<em>proto</em>), the
-      .manager file contains a key <code>param-<em>p</em></code> with a value
-      consisting of a D-Bus signature (a single complete type), optionally
-      followed by a space and a space-separated list of flags. The supported
-      flags are:</p>
+    the keys of the <tp:member-ref>Protocols</tp:member-ref> property,
+    the .manager file contains a group headed <code>[im.telepathy1.Protocol
+    <em>proto</em>]</code>. For each parameter <em>p</em> that would
+    be in the <tp:dbus-ref
+    namespace="imt1.Protocol">Parameters</tp:dbus-ref> property
+    (retrievable using the <tp:member-ref>Protocols</tp:member-ref>
+    property), the .manager file contains a key
+    <code>param-<em>p</em></code> with a value consisting of a D-Bus
+    signature (a single complete type), optionally followed by a space
+    and a space-separated list of flags. The supported flags are:</p>
 
     <ul>
       <li><code>required</code>, corresponding to
@@ -630,6 +590,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     <tp:changed version="0.25.2">Prior to version 0.25.2 the
       serialization of object-path arrays (signature 'ao') was not
       defined</tp:changed>
+    <tp:changed version="0.99.1">GetParameters and ListProtocols
+      have been removed in favour of the
+      <tp:member-ref>Protocols</tp:member-ref> property.</tp:changed>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Connection_Manager_Interface_Account_Storage.xml b/spec/Connection_Manager_Interface_Account_Storage1.xml
index 2f4f4bf7..a3af965d 100644
--- a/spec/Connection_Manager_Interface_Account_Storage.xml
+++ b/spec/Connection_Manager_Interface_Account_Storage1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Connection_Manager_Interface_Account_Storage"
+<node name="/Connection_Manager_Interface_Account_Storage1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2011 Collabora Ltd.</tp:copyright>
@@ -20,20 +20,20 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.ConnectionManager.Interface.AccountStorage.DRAFT"
+  <interface name="im.telepathy1.ConnectionManager.Interface.AccountStorage1"
     tp:causes-havoc="experimental">
     <tp:added version="0.21.10">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.ConnectionManager"/>
+    <tp:requires interface="im.telepathy1.ConnectionManager"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for connection managers that store account details
         internally.  At the moment this consists only of storing an account's
         credentials, but other functionality may be added in the future.</p>
 
-      <p><tp:dbus-ref namespace="ofdT">Account</tp:dbus-ref> objects
+      <p><tp:dbus-ref namespace="imt1">Account</tp:dbus-ref> objects
         representing accounts on a connection manager that implements this
         interface should implement the
-	<tp:dbus-ref namespace="ofdT.Account.Interface">ExternalPasswordStorage.DRAFT</tp:dbus-ref>
+	<tp:dbus-ref namespace="imt1.Account.Interface">ExternalPasswordStorage1</tp:dbus-ref>
         interface.</p>
     </tp:docstring>
 
@@ -80,12 +80,12 @@
         type="s">
         <tp:docstring>
           An account id as returned from
-	  <tp:dbus-ref namespace="ofdT">Protocol.IdentifyAccount</tp:dbus-ref>.
+	  <tp:dbus-ref namespace="imt1">Protocol.IdentifyAccount</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The account id is invalid.
           </tp:docstring>
@@ -103,12 +103,12 @@
         type="s">
         <tp:docstring>
           An account id as returned from
-	  <tp:dbus-ref namespace="ofdT">Protocol.IdentifyAccount</tp:dbus-ref>.
+	  <tp:dbus-ref namespace="imt1">Protocol.IdentifyAccount</tp:dbus-ref>.
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The account id is invalid.
           </tp:docstring>
diff --git a/spec/Debug.xml b/spec/Debug1.xml
index 70a82e90..ae98c2db 100644
--- a/spec/Debug.xml
+++ b/spec/Debug1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Debug"
+<node name="/Debug1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>Copyright (C) 2009 Collabora Ltd.</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -17,14 +17,14 @@ Lesser General Public License for more details.</p>
 License along with this library; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
   </tp:license>
-  <interface name="org.freedesktop.Telepathy.Debug">
+  <interface name="im.telepathy1.Debug1">
     <tp:added version="0.17.27">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for providing debug messages.</p>
 
       <p>This interface is primarily provided by one object per
-      service, at the path <tt>/org/freedesktop/Telepathy/debug</tt>.</p>
+      service, at the path <tt>/im/telepathy1/Debug</tt>.</p>
     </tp:docstring>
 
     <property name="Enabled" type="b" access="readwrite"
diff --git a/spec/Media_Session_Handler.xml b/spec/Media_Session_Handler.xml
deleted file mode 100644
index 70aa7507..00000000
--- a/spec/Media_Session_Handler.xml
+++ /dev/null
@@ -1,81 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Media_Session_Handler" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005, 2006 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Media.SessionHandler">
-    <method name="Error" tp:name-for-bindings="Error">
-      <arg direction="in" name="Error_Code" type="u"
-        tp:type="Media_Stream_Error"/>
-      <arg direction="in" name="Message" type="s"/>
-      <tp:deprecated version="0.13.4">
-        Use <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media">StreamHandler.Error</tp:dbus-ref>
-        on each StreamHandler object instead.
-      </tp:deprecated>
-      <tp:docstring>
-        Informs the connection manager that an error occured in this session.
-        If used, the connection manager must terminate the session and all of
-        the streams within it, and may also emit a <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">StreamError</tp:dbus-ref>
-        signal on the channel for each stream within the session.
-      </tp:docstring>
-    </method>
-    <signal name="NewStreamHandler" tp:name-for-bindings="New_Stream_Handler">
-      <arg name="Stream_Handler" type="o">
-        <tp:docstring>
-          The path of a new object implementing the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Media">StreamHandler</tp:dbus-ref>
-          interface.
-        </tp:docstring>
-      </arg>
-      <arg name="ID" type="u">
-        <tp:docstring>
-          The unique ID of the new stream
-        </tp:docstring>
-      </arg>
-      <arg name="Media_Type" type="u" tp:type="Media_Stream_Type">
-        <tp:docstring>
-          Type of media that this stream should handle
-        </tp:docstring>
-      </arg>
-      <arg name="Direction" type="u" tp:type="Media_Stream_Direction">
-        <tp:docstring>
-          Direction of this stream
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when a new stream handler has been created for this
-        session.
-      </tp:docstring>
-    </signal>
-    <method name="Ready" tp:name-for-bindings="Ready">
-      <tp:docstring>
-        Inform the connection manager that a client is ready to handle
-        this session handler (i.e. that it has connected to the
-        <tp:member-ref>NewStreamHandler</tp:member-ref> signal and done any
-        other necessary setup).
-      </tp:docstring>
-    </method>
-    <tp:docstring>
-      An media session handler is an object that handles a number of synchronised
-    media streams.
-    </tp:docstring>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
deleted file mode 100644
index 0a833709..00000000
--- a/spec/Media_Stream_Handler.xml
+++ /dev/null
@@ -1,906 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Media_Stream_Handler" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005-2008 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005-2008 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Media.StreamHandler">
-
-    <tp:docstring>
-    Handles signalling the information pertaining to a specific media stream.
-    A client should provide information to this handler as and when it is
-    available.
-    </tp:docstring>
-
-    <tp:struct name="Media_Stream_Handler_Candidate"
-      array-name="Media_Stream_Handler_Candidate_List">
-      <tp:member type="s" name="Name"/>
-      <tp:member type="a(usuussduss)" name="Transports"
-        tp:type="Media_Stream_Handler_Transport[]"/>
-    </tp:struct>
-
-    <tp:struct name="Media_Stream_Handler_Transport"
-      array-name="Media_Stream_Handler_Transport_List">
-      <tp:member type="u" name="Component_Number"/>
-      <tp:member type="s" name="IP_Address"/>
-      <tp:member type="u" name="Port"/>
-      <tp:member type="u" tp:type="Media_Stream_Base_Proto" name="Protocol"/>
-      <tp:member type="s" name="Subtype"/>
-      <tp:member type="s" name="Profile"/>
-      <tp:member type="d" name="Preference_Value"/>
-      <tp:member type="u" tp:type="Media_Stream_Transport_Type"
-        name="Transport_Type"/>
-      <tp:member type="s" name="Username"/>
-      <tp:member type="s" name="Password"/>
-    </tp:struct>
-
-    <tp:struct name="Media_Stream_Handler_Codec"
-      array-name="Media_Stream_Handler_Codec_List">
-      <tp:docstring>
-        Information about a codec supported by a client or a peer's client.
-      </tp:docstring>
-
-      <tp:member type="u" name="Codec_ID">
-        <tp:docstring>
-          The codec's payload identifier, as per RFC 3551 (static or dynamic)
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="Name">
-        <tp:docstring>The codec's name</tp:docstring>
-      </tp:member>
-      <tp:member type="u" tp:type="Media_Stream_Type" name="Media_Type">
-        <tp:docstring>Type of stream this codec supports</tp:docstring>
-      </tp:member>
-      <tp:member type="u" name="Clock_Rate">
-        <tp:docstring>Sampling frequency in Hertz</tp:docstring>
-      </tp:member>
-      <tp:member type="u" name="Number_Of_Channels">
-        <tp:docstring>Number of supported channels</tp:docstring>
-      </tp:member>
-      <tp:member type="a{ss}" name="Parameters" tp:type="String_String_Map">
-        <tp:docstring>Codec-specific optional parameters</tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
-      type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
-      <tp:added version="0.17.22"/>
-      <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:rationale>
-          High-quality connection managers already need an asynchronous
-          DNS resolver, so they might as well resolve this name to an IP
-          to make life easier for streaming implementations.
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-    <property name="CreatedLocally" tp:name-for-bindings="Created_Locally"
-      type="b" access="read">
-      <tp:added version="0.17.22"/>
-      <tp:docstring>
-        True if we were the creator of this stream, false otherwise.
-        <tp:rationale>
-          This information is needed for some nat traversal mechanisms, such
-          as ICE-UDP, where the creator gets the role of the controlling agent.
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-    <property name="NATTraversal" tp:name-for-bindings="NAT_Traversal"
-      type="s" access="read">
-      <tp:added version="0.17.22"/>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The transport (NAT traversal technique) to be used for this
-          stream. Well-known values include:</p>
-
-        <dl>
-          <dt>none</dt>
-          <dd>Raw UDP, with or without STUN, should be used. If the
-            <tp:member-ref>STUNServers</tp:member-ref> property is non-empty,
-            STUN SHOULD be used.</dd>
-
-          <dt>stun</dt>
-          <dd>A deprecated synonym for 'none'.</dd>
-
-          <dt>gtalk-p2p</dt>
-          <dd>Google Talk peer-to-peer connectivity establishment should be
-            used, as implemented in libjingle 0.3.</dd>
-
-          <dt>ice-udp</dt>
-          <dd>Interactive Connectivity Establishment should be used,
-            as defined by the IETF MMUSIC working group.</dd>
-
-          <dt>wlm-8.5</dt>
-          <dd>The transport used by Windows Live Messenger 8.5 or later,
-            which resembles ICE draft 6, should be used.</dd>
-
-          <dt>wlm-2009</dt>
-          <dd>The transport used by Windows Live Messenger 2009 or later,
-            which resembles ICE draft 19, should be used.</dd>
-        </dl>
-
-        <p>This property cannot change once the stream has been created, so
-          there is no change notification.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="RelayInfo" type="aa{sv}" access="read"
-      tp:type="String_Variant_Map[]" tp:name-for-bindings="Relay_Info">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>A list of mappings describing TURN or Google relay servers
-          available for the client to use in its candidate gathering, as
-          determined from the protocol. Map keys are:</p>
-
-        <dl>
-          <dt><code>ip</code> - s</dt>
-          <dd>The IP address of the relay server as a dotted-quad IPv4
-            address literal or an RFC2373 IPv6 address literal. This MUST NOT
-            be a DNS hostname.
-
-            <tp:rationale>
-              High-quality connection managers already need an asynchronous
-              DNS resolver, so they might as well resolve this name to an IP
-              and make life easier for streaming implementations.
-            </tp:rationale>
-          </dd>
-
-          <dt><code>type</code> - s</dt>
-          <dd>
-            <p>Either <code>udp</code> for UDP (UDP MUST be assumed if this
-              key is omitted), <code>tcp</code> for TCP, or
-              <code>tls</code>.</p>
-
-            <p>The precise meaning of this key depends on the
-              <tp:member-ref>NATTraversal</tp:member-ref> property: if
-              NATTraversal is <code>ice-udp</code>, <code>tls</code> means
-              TLS over TCP as referenced by ICE draft 19, and if
-              NATTraversal is <code>gtalk-p2p</code>, <code>tls</code> means
-              a fake SSL session over TCP as implemented by libjingle.</p>
-          </dd>
-
-          <dt><code>port</code> - q</dt>
-          <dd>The UDP or TCP port of the relay server as an ASCII unsigned
-            integer</dd>
-
-          <dt><code>username</code> - s</dt>
-          <dd>The username to use</dd>
-
-          <dt><code>password</code> - s</dt>
-          <dd>The password to use</dd>
-
-          <dt><code>component</code> - u</dt>
-          <dd>The component number to use this relay server for, as an
-            ASCII unsigned integer; if not included, this relay server
-            may be used for any or all components.
-
-            <tp:rationale>
-              In ICE draft 6, as used by Google Talk, credentials are only
-              valid once, so each component needs relaying separately.
-            </tp:rationale>
-          </dd>
-        </dl>
-
-        <tp:rationale>
-          <p>An equivalent of the gtalk-p2p-relay-token property on
-            MediaSignalling channels is not included here. The connection
-            manager should be responsible for making the necessary HTTP
-            requests to turn the token into a username and password.</p>
-        </tp:rationale>
-
-        <p>The type of relay server that this represents depends on
-          the value of the <tp:member-ref>NATTraversal</tp:member-ref>
-          property. If NATTraversal is ice-udp, this is a TURN server;
-          if NATTraversal 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>This property cannot change once the stream has been created, so
-          there is no change notification.</p>
-      </tp:docstring>
-    </property>
-
-    <signal name="AddRemoteCandidate"
-      tp:name-for-bindings="Add_Remote_Candidate">
-      <arg name="Candidate_ID" type="s">
-        <tp:docstring>
-          String identifier for this candidate
-        </tp:docstring>
-      </arg>
-      <arg name="Transports" type="a(usuussduss)"
-        tp:type="Media_Stream_Handler_Transport[]">
-        <tp:docstring>
-          Array of transports for this candidate with fields,
-          as defined in NewNativeCandidate
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client of a new remote candidate.
-      </tp:docstring>
-    </signal>
-    <signal name="Close" tp:name-for-bindings="Close">
-      <tp:docstring>
-        Signal emitted when the connection manager wishes the stream to be
-        closed.
-      </tp:docstring>
-    </signal>
-    <method name="CodecChoice" tp:name-for-bindings="Codec_Choice">
-      <arg direction="in" name="Codec_ID" type="u"/>
-      <tp:docstring>
-        Inform the connection manager of codec used to receive data.
-      </tp:docstring>
-    </method>
-    <method name="Error" tp:name-for-bindings="Error">
-      <arg direction="in" name="Error_Code" type="u" tp:type="Media_Stream_Error">
-        <tp:docstring>
-          ID of error, from the MediaStreamError enumeration
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Message" type="s">
-        <tp:docstring>
-          String describing the error
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager that an error occured in this stream. The
-        connection manager should emit the StreamError signal for the stream on
-        the relevant channel, and remove the stream from the session.
-      </tp:docstring>
-    </method>
-    <tp:enum name="Media_Stream_Error" type="u">
-      <tp:enumvalue suffix="Unknown" value="0">
-        <tp:docstring>
-          An unknown error occured.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="EOS" value="1">
-        <tp:docstring>
-          The end of the stream was reached.
-        </tp:docstring>
-        <tp:deprecated version="0.17.27">
-          This error has no use anywhere. In Farsight 1 times, it was used to
-          indicate a GStreamer EOS (when the end of a file is reached). But
-          since this is for live calls, it makes no sense.
-        </tp:deprecated>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Codec_Negotiation_Failed" value="2">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          There are no common codecs between the local side
-          and the other particpants in the call. The possible codecs are not
-          signalled here: the streaming implementation is assumed to report
-          them in an implementation-dependent way, e.g. Farsight should use
-          GstMissingElement.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Connection_Failed" value="3">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          A network connection for the Media could not be established or was
-          lost.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Network_Error" value="4">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          There was an error in the networking stack
-          (other than the connection failure).
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="No_Codecs" value="5">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          There are no installed codecs for this media type.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Invalid_CM_Behavior" value="6">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          The CM is doing something wrong.
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Media_Error" value="7">
-        <tp:added version="0.17.27"/>
-        <tp:docstring>
-          There was an error in the media processing stack.
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-    <method name="NativeCandidatesPrepared"
-      tp:name-for-bindings="Native_Candidates_Prepared">
-      <tp:docstring>
-        Informs the connection manager that all possible native candisates
-        have been discovered for the moment.
-      </tp:docstring>
-    </method>
-    <method name="NewActiveCandidatePair"
-      tp:name-for-bindings="New_Active_Candidate_Pair">
-      <arg direction="in" name="Native_Candidate_ID" type="s"/>
-      <arg direction="in" name="Remote_Candidate_ID" type="s"/>
-      <tp:docstring>
-        Informs the connection manager that a valid candidate pair
-        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>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="TCP" value="1">
-        <tp:docstring>TCP (Transmission Control Protocol)</tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-    <method name="NewNativeCandidate"
-      tp:name-for-bindings="New_Native_Candidate">
-      <arg direction="in" name="Candidate_ID" type="s">
-        <tp:docstring>
-          String identifier for this candidate
-        </tp:docstring>
-      </arg>
-      <arg direction="in" name="Transports" type="a(usuussduss)"
-        tp:type="Media_Stream_Handler_Transport[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          Array of transports for this candidate, with fields:
-          <ul>
-            <li>component number</li>
-            <li>IP address (as a string)</li>
-            <li>port</li>
-            <li>base network protocol (one of the values of MediaStreamBaseProto)</li>
-            <li>proto subtype (e.g. RTP)</li>
-            <li>proto profile (e.g. AVP)</li>
-            <li>our preference value of this transport (double in range 0.0-1.0
-              inclusive); 1 signals the most preferred transport</li>
-            <li>transport type, one of the values of MediaStreamTransportType</li>
-            <li>username if authentication is required</li>
-            <li>password if authentication is required</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform this MediaStreamHandler that a new native transport candidate
-        has been ascertained.
-      </tp:docstring>
-    </method>
-    <tp:enum name="Media_Stream_Transport_Type" type="u">
-      <tp:enumvalue suffix="Local" value="0">
-        <tp:docstring>
-          A local address
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Derived" value="1">
-        <tp:docstring>
-          An external address derived by a method such as STUN
-        </tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Relay" value="2">
-        <tp:docstring>
-          An external stream relay
-        </tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-    <method name="Ready" tp:name-for-bindings="Ready">
-      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
-        tp:type="Media_Stream_Handler_Codec[]">
-        <tp:docstring>
-          Locally-supported codecs.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager that a client is ready to handle
-        this StreamHandler. Also provide it with info about all supported
-        codecs.
-      </tp:docstring>
-    </method>
-    <method name="SetLocalCodecs" tp:name-for-bindings="Set_Local_Codecs">
-      <arg name="Codecs" type="a(usuuua{ss})" direction="in"
-        tp:type="Media_Stream_Handler_Codec[]">
-        <tp:docstring>
-          Locally-supported codecs
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Used to provide codecs after Ready(), so the media client can go
-          ready for an incoming call and exchange candidates/codecs before
-          knowing what local codecs are available.</p>
-
-        <p>This is useful for gatewaying calls between two connection managers.
-          Given an incoming call, you need to call
-          <tp:member-ref>Ready</tp:member-ref> to get the remote codecs before
-          you can use them as the "local" codecs to place the outgoing call,
-          and hence receive the outgoing call's remote codecs to use as the
-          incoming call's "local" codecs.</p>
-
-        <p>In this situation, you would pass an empty list of codecs to the
-          incoming call's Ready method, then later call SetLocalCodecs on the
-          incoming call in order to respond to the offer.</p>
-      </tp:docstring>
-    </method>
-    <signal name="RemoveRemoteCandidate"
-      tp:name-for-bindings="Remove_Remote_Candidate">
-      <arg name="Candidate_ID" type="s">
-        <tp:docstring>
-          String identifier for remote candidate to drop
-        </tp:docstring>
-      </arg>
-      <tp:deprecated version="0.17.18">
-        There is no case where you want to release candidates (except
-        for an ICE reset, and there you'd want to replace then all,
-        using <tp:member-ref>SetRemoteCandidateList</tp:member-ref>).
-      </tp:deprecated>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client that the remote end has removed a previously usable
-        candidate.
-
-        <tp:rationale>
-          It seemed like a good idea at the time, but wasn't.
-        </tp:rationale>
-      </tp:docstring>
-    </signal>
-    <signal name="SetActiveCandidatePair"
-      tp:name-for-bindings="Set_Active_Candidate_Pair">
-      <arg name="Native_Candidate_ID" type="s"/>
-      <arg name="Remote_Candidate_ID" type="s"/>
-      <tp:docstring>
-        Emitted by the connection manager to inform the client that a
-        valid candidate pair has been discovered by the remote end
-        and streaming is in progress.
-      </tp:docstring>
-    </signal>
-    <signal name="SetRemoteCandidateList"
-      tp:name-for-bindings="Set_Remote_Candidate_List">
-      <arg name="Remote_Candidates" type="a(sa(usuussduss))"
-        tp:type="Media_Stream_Handler_Candidate[]">
-        <tp:docstring>
-        A list of candidate id and a list of transports
-        as defined in NewNativeCandidate
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client of all the available remote candidates at once.
-      </tp:docstring>
-    </signal>
-    <signal name="SetRemoteCodecs" tp:name-for-bindings="Set_Remote_Codecs">
-      <arg name="Codecs" type="a(usuuua{ss})"
-        tp:type="Media_Stream_Handler_Codec[]">
-        <tp:docstring>
-          Codecs supported by the remote peer.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client of the codecs supported by the remote end.
-        If these codecs are compatible with the remote codecs, then the client
-        must call <tp:member-ref>SupportedCodecs</tp:member-ref>,
-        otherwise call <tp:member-ref>Error</tp:member-ref>.
-      </tp:docstring>
-    </signal>
-    <signal name="SetStreamPlaying" tp:name-for-bindings="Set_Stream_Playing">
-      <arg name="Playing" type="b"/>
-      <tp:docstring>
-        If emitted with argument TRUE, this means that the connection manager
-        wishes to set the stream playing; this means that the streaming
-        implementation should expect to receive data. If emitted with argument
-        FALSE this signal is basically meaningless and should be ignored.
-
-        <tp:rationale>
-          We're very sorry.
-        </tp:rationale>
-      </tp:docstring>
-    </signal>
-    <signal name="SetStreamSending" tp:name-for-bindings="Set_Stream_Sending">
-      <arg name="Sending" type="b"/>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to set whether or not
-        the stream sends to the remote end.
-      </tp:docstring>
-    </signal>
-    <signal name="StartTelephonyEvent"
-      tp:name-for-bindings="Start_Telephony_Event">
-      <arg name="Event" type="y" tp:type="DTMF_Event">
-        <tp:docstring>
-          A telephony event code.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Request that a telephony event (as defined by RFC 4733) is transmitted
-        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>
-        Request that any ongoing telephony events (as defined by RFC 4733)
-        being transmitted over this stream are stopped.
-      </tp:docstring>
-    </signal>
-    <method name="StreamState" tp:name-for-bindings="Stream_State">
-      <arg direction="in" name="State" type="u" tp:type="Media_Stream_State"/>
-      <tp:docstring>
-        Informs the connection manager of the stream's current state, as
-        as specified in Channel.Type.StreamedMedia::ListStreams.
-      </tp:docstring>
-    </method>
-
-    <method name="SupportedCodecs" tp:name-for-bindings="Supported_Codecs">
-      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
-        tp:type="Media_Stream_Handler_Codec[]">
-        <tp:docstring>
-          Locally supported codecs.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager of the supported codecs for this session.
-        This is called after the connection manager has emitted SetRemoteCodecs
-        to notify what codecs are supported by the peer, and will thus be an
-        intersection of all locally supported codecs (passed to Ready)
-        and those supported by the peer.
-      </tp:docstring>
-    </method>
-
-    <method name="CodecsUpdated" tp:name-for-bindings="Codecs_Updated">
-      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
-        tp:type="Media_Stream_Handler_Codec[]">
-        <tp:docstring>
-          Locally supported codecs, which SHOULD be the same as were previously
-          in effect, but possibly with different parameters.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager that the parameters of the supported
-        codecs for this session have changed. The connection manager should
-        send the new parameters to the remote contact.
-
-        <tp:rationale>
-          This is required for H.264 and Theora, for example.
-        </tp:rationale>
-      </tp:docstring>
-    </method>
-
-    <signal name="SetStreamHeld" tp:name-for-bindings="Set_Stream_Held">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when the connection manager wishes to place the stream on
-          hold (so the streaming client should free hardware or software
-          resources) or take the stream off hold (so the streaming client
-          should reacquire the necessary resources).</p>
-
-        <p>When placing a channel's streams on hold, the connection manager
-          SHOULD notify the remote contact that this will be done (if
-          appropriate in the protocol) before it emits this signal.</p>
-
-        <tp:rationale>
-          <p>It is assumed that relinquishing a resource will not fail.
-            If it does, the call is probably doomed anyway.</p>
-        </tp:rationale>
-
-        <p>When unholding a channel's streams, the connection manager
-          SHOULD emit this signal and wait for success to be indicated
-          via HoldState before it notifies the remote contact that the
-          channel has been taken off hold.</p>
-
-        <tp:rationale>
-          <p>This means that if a resource is unavailable, the remote
-            contact will never even be told that we tried to acquire it.</p>
-        </tp:rationale>
-      </tp:docstring>
-      <tp:added version="0.17.3"/>
-
-      <arg name="Held" type="b">
-        <tp:docstring>
-          If true, the stream is to be placed on hold.
-        </tp:docstring>
-      </arg>
-    </signal>
-
-    <method name="HoldState" tp:name-for-bindings="Hold_State">
-      <tp:docstring>
-        Notify the connection manager that the stream's hold state has
-        been changed successfully in response to SetStreamHeld.
-      </tp:docstring>
-      <tp:added version="0.17.3"/>
-      <arg direction="in" name="Held" type="b">
-        <tp:docstring>
-          If true, the stream is now on hold.
-        </tp:docstring>
-      </arg>
-    </method>
-
-    <method name="UnholdFailure" tp:name-for-bindings="Unhold_Failure">
-      <tp:docstring>
-        Notify the connection manager that an attempt to reacquire the
-        necessary hardware or software resources to unhold the stream,
-        in response to SetStreamHeld, has failed.
-      </tp:docstring>
-      <tp:added version="0.17.3"/>
-    </method>
-
-    <tp:struct name="RTCP_Feedback_Message_Properties">
-      <tp:added version="0.22.1"/>
-      <tp:changed version="0.23.4">This struct is also used by Call, but
-        in call, the CM should know about RTP profiles, and never use MAXUINT
-        as a default value, because it complicates things unnecessarily.
-      </tp:changed>
-      <tp:member type="u" name="RTCPMinimumInterval">
-        <tp:docstring>
-          The minimum interval between two regular RTCP packets in
-          milliseconds for this content. If no special value is desired, one
-          should put MAXUINT (0xFFFFFFFF).
-
-          Implementors and users of Call's <tp:dbus-ref
-          namespace="ofdT.Call1.Content.MediaDescription.Interface"
-          >RTCPFeedback</tp:dbus-ref> should not use the MAXUINT default.
-          Instead, in RTP/AVP, the default should be 5000 (5 seconds).
-          If using the RTP/AVPF profile, it can be set to a lower value,
-          the default being 0.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="a(sss)" tp:type="RTCP_Feedback_Message[]"
-                 name="Messages">
-        <tp:docstring>
-          The RTCP feedback messages for this codec.
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:struct name="RTCP_Feedback_Message"
-               array-name="RTCP_Feedback_Message_List">
-      <tp:added version="0.22.1"/>
-      <tp:docstring>
-        A struct defining an RTCP feedback message.
-      </tp:docstring>
-      <tp:member type="s" name="Type">
-        <tp:docstring>
-          Feedback type, for example "ack", "nack", or "ccm".
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="Subtype">
-        <tp:docstring>
-          Feedback subtype, according to the Type, can be an empty string (""),
-          if there is no subtype.
-          For example, generic nack is Type="nack" Subtype="".
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="Parameters">
-        <tp:docstring>
-          Feedback parameters as a string. Format is defined in the relevant RFC
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <tp:mapping name="RTCP_Feedback_Message_Map">
-      <tp:added version="0.22.1"/>
-      <tp:docstring>
-        A map of codec and its feedback properties.
-      </tp:docstring>
-      <tp:member type="u" name="Codec_Identifier">
-        <tp:docstring>
-          Numeric identifier for the codec. This will be used as the
-          PT in the SDP or content description.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="(ua(sss))" tp:type="RTCP_Feedback_Message_Properties"
-                 name="Properties">
-        <tp:docstring>
-          The RTCP feedback properties for this codec.
-        </tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <signal name="SetRemoteFeedbackMessages"
-            tp:name-for-bindings="Set_Remote_Feedback_Messages">
-      <tp:added version="0.22.1"/>
-      <arg name="Messages" type="a{u(ua(sss))}"
-           tp:type="RTCP_Feedback_Message_Map">
-        <tp:docstring>
-          Remote Feedback messages desired by the remote side
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client of the feedback messages supported by the remote end.
-        This signal is emitted before
-        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
-        supports any of these messages, it must call
-        <tp:member-ref>SupportedFeedbackMessages</tp:member-ref> before calling
-        <tp:member-ref>SupportedCodecs</tp:member-ref>.
-      </tp:docstring>
-    </signal>
-
-    <method name="SupportedFeedbackMessages"
-            tp:name-for-bindings="Supported_Feedback_Messages">
-      <tp:added version="0.22.1"/>
-      <arg name="Messages" direction="in" type="a{u(ua(sss))}"
-           tp:type="RTCP_Feedback_Message_Map">
-        <tp:docstring>
-          Locally supported feedback messages.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager of the supported feedback messages
-        for this session.
-        This is called a before calling
-        <tp:member-ref>SupportedCodecs</tp:member-ref>,
-        <tp:member-ref>Ready</tp:member-ref> or
-        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local,
-        or negotiated feedback messages.
-      </tp:docstring>
-    </method>
-
-    <tp:struct name="RTP_Header_Extension"
-      array-name="RTP_Header_Extensions_List">
-      <tp:added version="0.22.1"/>
-      <tp:docstring>
-        A struct defining a RTP Header extension
-      </tp:docstring>
-      <tp:member type="u" name="ID">
-        <tp:docstring>
-          Identifier to be negotiated
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="u" tp:type="Media_Stream_Direction"  name="Direction">
-        <tp:docstring>
-          Direction in which the Header Extension is negotiated.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="URI">
-        <tp:docstring>
-          URI defining the extension
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="Parameters">
-        <tp:docstring>
-          Feedback parameters as a string. Format is defined in the relevant RFC
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <signal name="SetRemoteHeaderExtensions"
-            tp:name-for-bindings="Set_Remote_Header_Extensions">
-      <tp:added version="0.22.1"/>
-      <arg name="Header_Extensions" type="a(uuss)"
-           tp:type="RTP_Header_Extension[]">
-        <tp:docstring>
-          Header extensions desired by the remote side
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Signal emitted when the connection manager wishes to inform the
-        client of the RTP header extensions supported by the remote end.
-        This signal is emitted before
-        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
-        supports any of these messages, it must call
-        <tp:member-ref>SupportedHeaderExtensions</tp:member-ref> before calling
-        <tp:member-ref>SupportedCodecs</tp:member-ref>.
-      </tp:docstring>
-    </signal>
-
-    <method name="SupportedHeaderExtensions"
-            tp:name-for-bindings="Supported_Header_Extensions">
-      <tp:added version="0.22.1"/>
-      <arg name="Header_Extensions" direction="in" type="a(uuss)"
-           tp:type="RTP_Header_Extension[]">
-        <tp:docstring>
-          Locally supported RTP header extensions.
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Inform the connection manager of the supported RTP header extensions
-        for this session.
-        This is called before calling
-        <tp:member-ref>SupportedCodecs</tp:member-ref>,
-        <tp:member-ref>Ready</tp:member-ref> or
-        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local
-        or negotiated RTP header extensions.
-      </tp:docstring>
-    </method>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Properties_Interface.xml b/spec/Properties_Interface.xml
deleted file mode 100644
index 09ce3b9c..00000000
--- a/spec/Properties_Interface.xml
+++ /dev/null
@@ -1,196 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Properties_Interface" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright (C) 2005-2007 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright (C) 2005, 2006 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright (C) 2006 INdT </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.Properties">
-    <tp:deprecated version="0.24.0">All uses of this interface have been
-      expunged, and it may now be laid to rest.</tp:deprecated>
-
-    <tp:struct name="Property_Spec" array-name="Property_Spec_List">
-      <tp:docstring>A struct (property ID, property name, D-Bus signature,
-        flags) representing a property, as returned by ListProperties on the
-        Properties interface.</tp:docstring>
-      <tp:member type="u" name="Property_ID"/>
-      <tp:member type="s" name="Name"/>
-      <tp:member type="s" tp:type="DBus_Signature" name="Signature"/>
-      <tp:member type="u" tp:type="Property_Flags" name="Flags"/>
-    </tp:struct>
-
-    <tp:struct name="Property_Flags_Change"
-      array-name="Property_Flags_Change_List">
-      <tp:docstring>A struct (property ID, flags) representing a change to
-        a property's flags, as seen in the PropertyFlagsChanged signal on
-        the Properties interface.</tp:docstring>
-      <tp:member type="u" name="Property_ID"/>
-      <tp:member type="u" name="New_Flags"/>
-    </tp:struct>
-
-    <tp:simple-type name="Property_ID" type="u" array-name="Property_ID_List">
-      <tp:docstring>
-        An unsigned integer used to represent a Telepathy property.
-      </tp:docstring>
-    </tp:simple-type>
-
-    <tp:struct name="Property_Value" array-name="Property_Value_List">
-      <tp:docstring>A struct (property ID, value) representing a
-        property's value, as seen in the PropertiesChanged signal on
-        the Properties interface, returned by the GetProperties method
-        and passed to the SetProperties method.</tp:docstring>
-      <tp:member type="u" tp:type="Property_ID" name="Identifier"/>
-      <tp:member type="v" name="Value"/>
-    </tp:struct>
-
-    <method name="GetProperties" tp:name-for-bindings="Get_Properties">
-      <tp:docstring>
-        Returns an array of (identifier, value) pairs containing the current
-        values of the given properties.
-      </tp:docstring>
-      <arg direction="in" name="Properties" type="au" tp:type="Property_ID[]">
-        <tp:docstring>An array of property identifiers</tp:docstring>
-      </arg>
-      <arg direction="out" type="a(uv)" tp:type="Property_Value[]"
-        name="Values">
-        <!-- XXX: if we're ever breaking API compatibility, make this a{uv} -->
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of structs containing:</p>
-          <ul>
-            <li>integer identifiers</li>
-            <li>variant boxed values</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            Some property identifier requested is invalid
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
-          <tp:docstring>
-            Some property requested does not have the PROPERTY_FLAG_READ flag
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-    <method name="ListProperties" tp:name-for-bindings="List_Properties">
-      <tp:docstring>
-        Returns a dictionary of the properties available on this channel.
-      </tp:docstring>
-      <arg direction="out" type="a(ussu)" tp:type="Property_Spec[]"
-        name="Available_Properties">
-        <!-- XXX: if we're ever breaking API compatibility, make this
-        a{u(ssu)} ? -->
-        <tp:docstring>
-          An array of structs containing:
-          <ul>
-            <li>an integer identifier</li>
-            <li>a string property name</li>
-            <li>a string representing the D-Bus signature of this property</li>
-            <li>a bitwise OR of the flags applicable to this property</li>
-          </ul>
-        </tp:docstring>
-      </arg>
-    </method>
-    <signal name="PropertiesChanged" tp:name-for-bindings="Properties_Changed">
-      <tp:docstring>
-        Emitted when the value of readable properties has changed.
-      </tp:docstring>
-      <arg name="Properties" type="a(uv)" tp:type="Property_Value[]">
-        <!-- XXX: if we're ever breaking API compatibility, make this a{uv} -->
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of structs containing:</p>
-          <ul>
-            <li>integer identifiers</li>
-            <li>variant boxed values</li>
-          </ul>
-          <p>The array should contain only properties whose values have
-            actually changed.</p>
-        </tp:docstring>
-      </arg>
-    </signal>
-    <signal name="PropertyFlagsChanged"
-      tp:name-for-bindings="Property_Flags_Changed">
-      <tp:docstring>
-        Emitted when the flags of some room properties have changed.
-      </tp:docstring>
-      <arg name="Properties" type="a(uu)" tp:type="Property_Flags_Change[]">
-        <!-- XXX: if we're ever breaking API compatibility, make this a{uu} -->
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of structs containing:</p>
-          <ul>
-            <li>integer identifiers</li>
-            <li>a bitwise OR of the current flags</li>
-          </ul>
-          <p>The array should contain only properties whose flags have actually
-            changed.</p>
-        </tp:docstring>
-      </arg>
-    </signal>
-    <method name="SetProperties" tp:name-for-bindings="Set_Properties">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Takes an array of (identifier, value) pairs containing desired
-          values to set the given properties. In the case of any errors, no
-          properties will be changed. When the changes have been acknowledged
-          by the server, the PropertiesChanged signal will be emitted.</p>
-
-        <p>All properties given must have the PROPERTY_FLAG_WRITE flag, or
-        PermissionDenied will be returned. If any variants are of the wrong
-        type, NotAvailable will be returned.  If any given property identifiers
-        are invalid, InvalidArgument will be returned.</p>
-      </tp:docstring>
-
-      <arg direction="in" name="Properties" type="a(uv)"
-        tp:type="Property_Value[]">
-        <!-- XXX: if we're ever breaking API compatibility, make this a{uv} -->
-      <tp:docstring>
-        An array mapping integer property identifiers to boxed values
-      </tp:docstring>
-      </arg>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>Interface for channels and other objects, to allow querying and setting
-    properties. ListProperties returns which properties are valid for
-    the given channel, including their type, and an integer handle used to
-    refer to them in GetProperties, SetProperties, and the PropertiesChanged
-    signal. The values are represented by D-Bus variant types, and are
-    accompanied by flags indicating whether or not the property is readable or
-    writable.</p>
-
-    <p>Each property also has a flags value to indicate what methods are
-    available. This is a bitwise OR of PropertyFlags values.</p>
-    </tp:docstring>
-    <tp:flags name="Property_Flags" value-prefix="Property_Flag" type="u">
-      <tp:flag suffix="Read" value="1">
-        <tp:docstring>The property can be read</tp:docstring>
-      </tp:flag>
-      <tp:flag suffix="Write" value="2">
-        <tp:docstring>The property can be written</tp:docstring>
-      </tp:flag>
-    </tp:flags>
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 6cc10aa6..8f26f628 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -20,31 +20,26 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Protocol">
+  <interface name="im.telepathy1.Protocol">
     <tp:added version="0.19.10">(as stable API)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An object representing a protocol for which this <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ConnectionManager</tp:dbus-ref>
+          namespace="im.telepathy1">ConnectionManager</tp:dbus-ref>
         can create <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>s.</p>
+          namespace="im.telepathy1">Connection</tp:dbus-ref>s.</p>
 
       <p>Each Protocol object has the same well-known bus name as its parent
         ConnectionManager. Its object path is formed by taking the
-        ConnectionManager's object path and appending '/', followed by the
-        <tp:type>Protocol</tp:type> name with any hyphen/minus '-' converted
-        to underscores '_'.</p>
-
-      <tp:rationale>
-        <p>This is the same as the representation of protocol names
-          in Account object paths, and in Connection object paths and bus
-          names. For instance, telepathy-gabble and telepathy-salut would
-          implement objects at
-          <code>/org/freedesktop/Telepathy/ConnectionManager/gabble/jabber</code>
-          and
-          <code>/org/freedesktop/Telepathy/ConnectionManager/salut/local_xmpp</code>,
-          respectively.</p>
-      </tp:rationale>
+        ConnectionManager's object path and appending '/' followed by the
+        <tp:type>Protocol_Name</tp:type>.</p>
+
+      <p>For instance, telepathy-gabble and telepathy-salut would
+        implement objects at
+        <code>/im/telepathy1/ConnectionManager/gabble/jabber</code>
+        and
+        <code>/im/telepathy1/ConnectionManager/salut/local_xmpp</code>,
+        respectively.</p>
 
       <p>If the ConnectionManager has a <tt>.manager</tt> file, each
         Protocol's immutable properties must be represented in that file;
@@ -58,19 +53,19 @@ Interfaces=
 
 [Protocol example]
 Interfaces=
-ConnectionInterfaces=org.freedesktop.Telepathy.Connection.Interface.Requests;
+ConnectionInterfaces=im.telepathy1.Connection.Interface.Requests;
 param-account=s required
 param-password=s required secret
 RequestableChannelClasses=text;
 VCardField=x-example
 EnglishName=Example
 Icon=im-example
-AuthenticationTypes=org.freedesktop.Telepathy.Channel.Type.ServerTLSConnection;org.freedesktop.Telepathy.Channel.Interface.SASLAuthentication;
+AuthenticationTypes=im.telepathy1.Channel.Type.ServerTLSConnection;im.telepathy1.Channel.Interface.SASLAuthentication;
 
 [text]
-org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
-org.freedesktop.Telepathy.Channel.TargetHandleType u=1
-allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
+im.telepathy1.Channel.ChannelType s=im.telepathy1.Channel.Type.Text
+im.telepathy1.Channel.TargetHandleType u=1
+allowed=im.telepathy1.Channel.TargetHandle;im.telepathy1.Channel.TargetID;
 </pre>
     </tp:docstring>
 
@@ -87,7 +82,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <p>Connection managers with a <code>.manager</code> file
           (as described as part of the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >ConnectionManager</tp:dbus-ref> interface) MUST cache this
           property in the protocol's section of the <code>.manager</code>
           file, using the key <code>Interfaces</code>. The corresponding value
@@ -100,23 +95,23 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The parameters which may be specified in the
-          <tp:dbus-ref namespace='ofdT.Account'>Parameters</tp:dbus-ref> of an
-          <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> (or, for
+          <tp:dbus-ref namespace='imt1.Account'>Parameters</tp:dbus-ref> of an
+          <tp:dbus-ref namespace='imt1'>Account</tp:dbus-ref> (or, for
           specialised applications which do not use the account manager, passed
           to <tp:dbus-ref
-          namespace='ofdT.ConnectionManager'>RequestConnection</tp:dbus-ref>).
+          namespace='imt1.ConnectionManager'>RequestConnection</tp:dbus-ref>).
           Some parameters are mandatory, and some parameters only make sense
           when registering new accounts with the server; see the
           <tp:type>Param_Spec</tp:type> documentation for more details.</p>
 
         <p>Connection managers with a <code>.manager</code> file
           (as described as part of the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >ConnectionManager</tp:dbus-ref> interface) MUST cache this
           property in the protocol's section of the <code>.manager</code>
           file via keys of the form <code>param-<em>p</em></code> and
           <code>default-<em>p</em></code>, as documented in the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >ConnectionManager</tp:dbus-ref> interface.</p>
       </tp:docstring>
     </property>
@@ -127,9 +122,9 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       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"
+          <tp:dbus-ref namespace="im.telepathy1.Connection"
             >Interfaces</tp:dbus-ref> property of a
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Connection</tp:dbus-ref> to this protocol. Whether a Connection
           will have all, some or none of these interfaces depends on server
           capabilities.</p>
@@ -151,10 +146,10 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       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"
+          <tp:dbus-ref namespace="im.telepathy1"
             >Connection</tp:dbus-ref> to this protocol (i.e. they will,
           or might, appear in the Connection's <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests"
+            namespace="im.telepathy1.Connection.Interface.Requests"
             >RequestableChannelClasses</tp:dbus-ref> property).</p>
 
         <p>Whether a Connection will have all, some or none of these
@@ -184,7 +179,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
           "<code><em>propertyname</em> <em>type</em></code>", and the value
           is encoded in the same way as for the <code>default-<em>p</em></code>
           keys described in the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy"
+            namespace="im.telepathy1"
             >ConnectionManager</tp:dbus-ref> documentation.</p>
 
         <p>Connection managers that have channel classes whose fixed
@@ -193,7 +188,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <p>For instance, this <code>.manager</code> file could represent
           a connection manager that supports 1-1 Text messages and
-          StreamedMedia audio calls:</p>
+          Call audio calls:</p>
 
 <pre>[Protocol jabber]
 param-account=s required
@@ -201,14 +196,14 @@ param-password=s required
 RequestableChannelClasses=rcc0;rcc1;
 
 [rcc0]
-org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Text
-org.freedesktop.Telepathy.Channel.TargetHandleType u=1
-allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
+im.telepathy1.Channel.ChannelType s=im.telepathy1.Channel.Type.Text
+im.telepathy1.Channel.TargetHandleType u=1
+allowed=im.telepathy1.Channel.TargetHandle;im.telepathy1.Channel.TargetID;
 
 [rcc1]
-org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.StreamedMedia
-org.freedesktop.Telepathy.Channel.TargetHandleType u=1
-allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;org.freedesktop.Telepathy.Channel.Type.StreamedMedia.InitialAudio;
+im.telepathy1.Channel.ChannelType s=im.telepathy1.Channel.Type.Call1
+im.telepathy1.Channel.TargetHandleType u=1
+allowed=im.telepathy1.Channel.TargetHandle;im.telepathy1.Channel.TargetID;im.telepathy1.Channel.Type.Call1.InitialAudio;
 </pre>
       </tp:docstring>
     </property>
@@ -226,7 +221,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <p>A more exhaustive list of addressable vCard fields can be found in
           the Protocol's Addressing interface's
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableVCardFields</tp:dbus-ref>.</p>
+          <tp:dbus-ref namespace="im.telepathy1.Protocol.Interface.Addressing1">AddressableVCardFields</tp:dbus-ref>.</p>
 
         <p>It is not necessarily valid to interpret contacts' identifiers
           as values of this vCard field. For instance, telepathy-sofiasip
@@ -235,7 +230,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
           both be represented by any single vCard field. Arbitrary
           handles/identifiers as vCard fields are represented
           through the Connection's
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">Addressing1</tp:dbus-ref>
+          <tp:dbus-ref namespace="im.telepathy1.Connection.Interface">Addressing1</tp:dbus-ref>
           contact attributes.</p>
 
         <tp:rationale>
@@ -268,9 +263,9 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
         <p>This is effectively in the C locale (international English);
           user interfaces requiring a localized protocol name SHOULD look
           one up in their own message catalog based on either the Telepathy
-          <tp:type>Protocol</tp:type> name or this property, but SHOULD use
-          this English version as a fallback if no translated version can be
-          found.</p>
+          <tp:type>Protocol_Name</tp:type> name or this property, but SHOULD
+          use this English version as a fallback if no translated version can
+          be found.</p>
 
         <tp:rationale>
           <p>Many protocols are named after a company or product which isn't
@@ -280,8 +275,8 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
         </tp:rationale>
 
         <p>If this property's value is empty, clients MAY fall back to using
-          the Telepathy <tp:type>Protocol</tp:type> name, possibly with its
-          capitalization adjusted.</p>
+          the Telepathy <tp:type>Protocol_Name</tp:type> name, possibly with
+          its capitalization adjusted.</p>
 
         <p>Connection managers with a <code>.manager</code> file
           MUST cache this property in the protocol's section of the
@@ -300,15 +295,15 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <tp:rationale>
           <p>This can be used as a default if the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Account">Icon</tp:dbus-ref>
+              namespace="im.telepathy1.Account">Icon</tp:dbus-ref>
             property is not set on an Account, or used by the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy">AccountManager</tp:dbus-ref>
+              namespace="im.telepathy1">AccountManager</tp:dbus-ref>
             to choose a default icon if none is set during account
             creation.</p>
         </tp:rationale>
 
         <p>If this property's value is empty, clients MAY fall back to
-          generating a name based on the <tp:type>Protocol</tp:type> name.</p>
+          generating a name based on the <tp:type>Protocol_Name</tp:type>.</p>
 
         <p>Connection managers with a <code>.manager</code> file
           MUST cache this property in the protocol's section of the
@@ -338,7 +333,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
         type="a{sv}" tp:type="String_Variant_Map">
         <tp:docstring>
           A set of parameters as would be provided to <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.ConnectionManager"
+            namespace="im.telepathy1.ConnectionManager"
             >RequestConnection</tp:dbus-ref>
         </tp:docstring>
       </arg>
@@ -346,7 +341,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       <arg direction="out" name="Account_ID" type="s">
         <tp:docstring>
           <p>An opaque string suitable for use as the account-specific part of
-            an <tp:dbus-ref namespace="org.freedesktop.Telepathy"
+            an <tp:dbus-ref namespace="im.telepathy1"
               >Account</tp:dbus-ref>'s object path. This is not necessarily
             globally unique, but should represent a "best-effort"
             identification of the account.</p>
@@ -363,7 +358,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The IdentifyAccount method is not supported by this connection
             manager. The caller SHOULD fall back to deriving identification
@@ -377,14 +372,14 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       tp:name-for-bindings="Normalize_Contact">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Attempt to normalize the given contact ID. Where possible, this
-          SHOULD return the same thing that would be returned by
-          InspectHandles(RequestHandles(CONTACT, [Contact_ID])) on a connected
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-            >Connection</tp:dbus-ref>.</p>
+          SHOULD return the same thing that would be returned by <tp:dbus-ref
+          namespace="imt1.Connection.Interface.Contacts">GetContactByID</tp:dbus-ref>
+           on a connected <tp:dbus-ref namespace="im.telepathy1"
+           >Connection</tp:dbus-ref>.</p>
 
         <p>If full normalization requires network activity or is otherwise
           impossible to do without a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
+            namespace="im.telepathy1">Connection</tp:dbus-ref>,
           this method SHOULD perform a best-effort normalization.</p>
 
         <tp:rationale>
@@ -428,7 +423,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The NormalizeContact method is not supported by this connection
             manager. The caller MAY recover by using the contact ID as-is.
@@ -449,14 +444,14 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
         <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>
+          <tp:dbus-ref namespace="imt1.Channel.Type">ServerTLSConnection1</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>
+          <tp:dbus-ref namespace="imt1.Channel.Type">ServerAuthentication1</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>
+          <tp:dbus-ref namespace="imt1.Channel.Type">ServerAuthentication1.AuthenticationMethod</tp:dbus-ref>
           property in this list.</p>
 
         <p>For example, if a protocol's
@@ -465,19 +460,19 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <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>
+[ ...<tp:dbus-ref namespace="imt1">Channel.Type.ServerTLSConnection1</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="imt1">Channel.Interface.SASLAuthentication1</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>
+          namespace="imt1.Channel.Type">ServerTLSConnection1</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>
+          namespace="imt1.Channel.Type">ServerAuthentication1</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
+          namespace="imt1.Channel.Type">ServerAuthentication1.AuthenticationMethod</tp:dbus-ref>=<tp:dbus-ref
+          namespace="imt1.Channel.Interface">SASLAuthentication1</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>
diff --git a/spec/Protocol_Interface_Addressing.xml b/spec/Protocol_Interface_Addressing1.xml
index 55ee71cb..d3abe062 100644
--- a/spec/Protocol_Interface_Addressing.xml
+++ b/spec/Protocol_Interface_Addressing1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Protocol_Interface_Addressing"
+<node name="/Protocol_Interface_Addressing1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -21,7 +21,7 @@
   </tp:license>
 
   <interface
-     name="org.freedesktop.Telepathy.Protocol.Interface.Addressing">
+     name="im.telepathy1.Protocol.Interface.Addressing1">
     <tp:added version="0.25.1">(as stable API). From the draft,
       NormalizeURI was renamed to NormalizeContactURI, clarifying that
       it removes any actions from the URI.</tp:added>
@@ -116,7 +116,7 @@ AddressableURISchemes=tel;sip;
           offline. When it is connected the addressable URI schemes should be
           retrieved from the
           <tp:dbus-ref
-             namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.RequestableChannelClasses</tp:dbus-ref>'s
+             namespace="im.telepathy1.Connection.Interface">Requests.RequestableChannelClasses</tp:dbus-ref>'s
              TargetURIScheme fixed-property instead.</p>
 
         <p>Connection managers with a <code>.manager</code> file
@@ -144,20 +144,20 @@ AddressableURISchemes=tel;sip;
             For example: <code>xmpp:julien@example.com</code>.</dd>
           <dt><code>msnim</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Protocol.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Addressing1</tp:dbus-ref>,
             and
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Channel.Interface.Addressing1</tp:dbus-ref>,
             the verb part is ignored, and SHOULD be <code>add</code>; the
             <code>contact</code> field in the query string is used to
             identify the contact.
             For example: <code>msnim:add?contact=julien</code>.</dd>
           <dt><code>aim</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Protocol.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Addressing1</tp:dbus-ref>,
             and
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Channel.Interface.Addressing1</tp:dbus-ref>,
             the verb part is ignored, and SHOULD be <code>addbuddy</code>; the
             <code>screenname</code> field in the query string is used to
             identify the contact.
@@ -167,10 +167,10 @@ AddressableURISchemes=tel;sip;
             For example: <code>skype:julien</code>.</dd>
           <dt><code>ymsgr</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Protocol.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Connection.Interface.Addressing1</tp:dbus-ref>,
             and
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing1</tp:dbus-ref>,
+            <tp:dbus-ref namespace="im.telepathy1">Channel.Interface.Addressing1</tp:dbus-ref>,
             the verb part is ignored, and SHOULD be <code>addfriend</code>; the
             query string is used to identify the contact.
             For example: <code>ymsgr:addfriend?julien</code>.</dd>
@@ -186,14 +186,14 @@ AddressableURISchemes=tel;sip;
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Attempt to normalize the given vCard address. Where possible, this
           SHOULD return an address that would appear in the
-          <code>org.freedesktop.Telepathy.Connection.Interface.Addressing1/addresses</code>
+          <code>im.telepathy1.Connection.Interface.Addressing1/addresses</code>
           attribute for a contact on a connected
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.
+          <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>.
         </p>
 
         <p>If full normalization requires network activity or is otherwise
           impossible to do without a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
+            namespace="im.telepathy1">Connection</tp:dbus-ref>,
           this method SHOULD perform a best-effort normalization.</p>
 
         <p>An example would be a vCard TEL field with a formatted
@@ -226,14 +226,14 @@ AddressableURISchemes=tel;sip;
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The vCard field is not supported (it is not in
             <tp:member-ref>AddressableVCardFields</tp:member-ref>).
           </tp:docstring>
         </tp:error>
 
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             The address is syntactically incorrect.
           </tp:docstring>
@@ -247,14 +247,14 @@ AddressableURISchemes=tel;sip;
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Attempt to normalize the given contact URI. Where possible, this
           SHOULD return an address that would appear in the
-          <code>org.freedesktop.Telepathy.Connection.Interface.Addressing1/uris</code>
+          <code>im.telepathy1.Connection.Interface.Addressing1/uris</code>
           attribute for a contact on a connected
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>.
+          <tp:dbus-ref namespace="im.telepathy1">Connection</tp:dbus-ref>.
         </p>
 
         <p>If full normalization requires network activity or is otherwise
           impossible to do without a <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
+            namespace="im.telepathy1">Connection</tp:dbus-ref>,
           this method SHOULD perform a best-effort normalization.</p>
 
         <p>If the URI has extra information beyond what's necessary to
@@ -308,14 +308,14 @@ AddressableURISchemes=tel;sip;
       </arg>
 
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:error name="im.telepathy1.Error.NotImplemented">
           <tp:docstring>
             The URI scheme is not supported (it is not in
             <tp:member-ref>AddressableURISchemes</tp:member-ref>).
           </tp:docstring>
         </tp:error>
 
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:error name="im.telepathy1.Error.InvalidArgument">
           <tp:docstring>
             <p>The URI is syntactically incorrect or cannot be interpreted
               as a reference to a contact.</p>
diff --git a/spec/Protocol_Interface_Avatars.xml b/spec/Protocol_Interface_Avatars1.xml
index 1bf0515e..9faefe64 100644
--- a/spec/Protocol_Interface_Avatars.xml
+++ b/spec/Protocol_Interface_Avatars1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Protocol_Interface_Avatars"
+<node name="/Protocol_Interface_Avatars1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
@@ -20,9 +20,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Avatars">
+  <interface name="im.telepathy1.Protocol.Interface.Avatars1">
     <tp:added version="0.21.5">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Protocol"/>
+    <tp:requires interface="im.telepathy1.Protocol"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for protocols where it might be possible to set the
@@ -32,9 +32,9 @@
       <tp:rationale>
         <p>If the avatar requirements cannot be discovered while offline,
           it's impossible to avoid setting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy"
+            namespace="im.telepathy1"
             >Account</tp:dbus-ref>'s <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Account.Interface.Avatar"
+            namespace="im.telepathy1.Account.Interface.Avatar1"
             >Avatar</tp:dbus-ref> property to an unsupported avatar.</p>
       </tp:rationale>
 
@@ -52,7 +52,7 @@
         <code>.manager</code> file:</p>
 
 <pre>[Protocol jabber]
-Interfaces=org.freedesktop.Telepathy.Protocol.Interface.Avatars;
+Interfaces=im.telepathy1.Protocol.Interface.Avatars;
 param-account=s required
 param-password=s required
 SupportedAvatarMIMETypes=image/png;image/jpeg;image/gif;
@@ -71,8 +71,8 @@ MaximumAvatarBytes=8192
       type="as" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.SupportedAvatarMIMETypes</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.SupportedAvatarMIMETypes</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -82,8 +82,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.MinimumAvatarHeight</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.MinimumAvatarHeight</tp:dbus-ref>
         property on connections to this protocol.
 </tp:docstring>
     </property>
@@ -93,8 +93,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.MinimumAvatarWidth</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.MinimumAvatarWidth</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -104,8 +104,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.RecommendedAvatarHeight</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.RecommendedAvatarHeight</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -115,8 +115,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.RecommendedAvatarWidth</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.RecommendedAvatarWidth</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -126,8 +126,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.MaximumAvatarHeight</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.MaximumAvatarHeight</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -137,8 +137,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.MaximumAvatarWidth</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.MaximumAvatarWidth</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
@@ -148,8 +148,8 @@ MaximumAvatarBytes=8192
       type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.Avatars.MaximumAvatarBytes</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Avatars1.MaximumAvatarBytes</tp:dbus-ref>
         property on connections to this protocol.
       </tp:docstring>
     </property>
diff --git a/spec/Protocol_Interface_Presence.xml b/spec/Protocol_Interface_Presence1.xml
index 447d2cee..a0cc1258 100644
--- a/spec/Protocol_Interface_Presence.xml
+++ b/spec/Protocol_Interface_Presence1.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Protocol_Interface_Presence"
+<node name="/Protocol_Interface_Presence1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
@@ -20,9 +20,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Protocol.Interface.Presence">
+  <interface name="im.telepathy1.Protocol.Interface.Presence1">
     <tp:added version="0.21.3">(as stable API)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Protocol"/>
+    <tp:requires interface="im.telepathy1.Protocol"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for protocols where it might be possible to set the
@@ -47,14 +47,14 @@
       <dl>
         <dt>settable</dt>
         <dd>If present, the user can set this status on themselves using
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.SimplePresence"
+          <tp:dbus-ref namespace="im.telepathy1.Connection.Interface.Presence1"
             >SetPresence</tp:dbus-ref>; this corresponds to May_Set_On_Self
-          in the <tp:type>Simple_Status_Spec</tp:type> struct.</dd>
+          in the <tp:type>Status_Spec</tp:type> struct.</dd>
 
         <dt>message</dt>
         <dd>If present, the user can set a non-empty message for this status;
           this corresponds to Can_Have_Message in the
-          <tp:type>Simple_Status_Spec</tp:type> struct.</dd>
+          <tp:type>Status_Spec</tp:type> struct.</dd>
       </dl>
 
       <p>Unrecognised tokens MUST be ignored.</p>
@@ -63,7 +63,7 @@
         <code>.manager</code> file:</p>
 
 <pre>[Protocol jabber]
-Interfaces=org.freedesktop.Telepathy.Protocol.Interface.Presence;
+Interfaces=im.telepathy1.Protocol.Interface.Presence;
 param-account=s required
 param-password=s required
 status-offline=1
@@ -96,14 +96,14 @@ status-chat=2 settable message
 
     <property name="Statuses"
       tp:name-for-bindings="Statuses"
-      type="a{s(ubb)}" tp:type="Simple_Status_Spec_Map" access="read"
+      type="a{s(ubb)}" tp:type="Status_Spec_Map" access="read"
       tp:immutable="yes">
       <tp:docstring>
         <p>The statuses that might appear in the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy"
-          >Connection.Interface.SimplePresence.Statuses</tp:dbus-ref>
+          namespace="im.telepathy1"
+          >Connection.Interface.Presence1.Statuses</tp:dbus-ref>
           property on a connection to this protocol that supports
-          SimplePresence. This property is immutable.</p>
+          Presence. This property is immutable.</p>
 
         <p>Depending on server capabilities, it is possible that not all
           of these will actually appear on the Connection.</p>
diff --git a/spec/all.xml b/spec/all.xml
index 6f770891..b18d77b3 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -3,9 +3,9 @@
   xmlns:xi="http://www.w3.org/2001/XInclude">
 
 <tp:title>Telepathy D-Bus Interface Specification</tp:title>
-<tp:version>0.27.3.1</tp:version>
+<tp:version>0.99.4</tp:version>
 
-<tp:copyright>Copyright © 2005-2012 Collabora Limited</tp:copyright>
+<tp:copyright>Copyright © 2005-2013 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2011 Nokia Corporation</tp:copyright>
 <tp:copyright>Copyright © 2006 INdT</tp:copyright>
 
@@ -32,11 +32,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </p>
  </tp:docstring>
  <xi:include href="Connection_Manager.xml"/>
- <xi:include href="Connection_Manager_Interface_Account_Storage.xml"/>
+ <xi:include href="Connection_Manager_Interface_Account_Storage1.xml"/>
  <xi:include href="Protocol.xml"/>
- <xi:include href="Protocol_Interface_Addressing.xml"/>
- <xi:include href="Protocol_Interface_Avatars.xml"/>
- <xi:include href="Protocol_Interface_Presence.xml"/>
+ <xi:include href="Protocol_Interface_Addressing1.xml"/>
+ <xi:include href="Protocol_Interface_Avatars1.xml"/>
+ <xi:include href="Protocol_Interface_Presence1.xml"/>
 
  <tp:section name="Connection Object">
   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -61,9 +61,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </p>
    </tp:docstring>
 
-   <xi:include href="Connection_Interface_Contact_List.xml"/>
-   <xi:include href="Connection_Interface_Contact_Groups.xml"/>
-   <xi:include href="Connection_Interface_Contact_Blocking.xml"/>
+   <xi:include href="Connection_Interface_Contact_List1.xml"/>
+   <xi:include href="Connection_Interface_Contact_Groups1.xml"/>
+   <xi:include href="Connection_Interface_Contact_Blocking1.xml"/>
   </tp:section>
 
   <tp:section name="Contact metadata interfaces">
@@ -76,17 +76,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </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"/>
+   <xi:include href="Connection_Interface_Aliasing1.xml"/>
+   <xi:include href="Connection_Interface_Avatars1.xml"/>
+   <xi:include href="Connection_Interface_Client_Types1.xml"/>
+   <xi:include href="Connection_Interface_Contact_Capabilities1.xml"/>
+   <xi:include href="Connection_Interface_Contact_Info1.xml"/>
+   <xi:include href="Connection_Interface_Location1.xml"/>
+   <xi:include href="Connection_Interface_Presence1.xml"/>
+   <xi:include href="Connection_Interface_Renaming1.xml"/>
+   <xi:include href="Connection_Interface_Resources1.xml"/>
   </tp:section>
 
   <tp:section name="Connection feature interfaces">
@@ -97,23 +95,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </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"/>
+   <xi:include href="Connection_Interface_Addressing1.xml"/>
+   <xi:include href="Connection_Interface_Anonymity1.xml"/>
+   <xi:include href="Connection_Interface_Balance1.xml"/>
+   <xi:include href="Connection_Interface_Cellular1.xml"/>
+   <xi:include href="Connection_Interface_Communication_Policy1.xml"/>
+   <xi:include href="Connection_Interface_Forwarding1.xml"/>
+   <xi:include href="Connection_Interface_Keepalive1.xml"/>
+   <xi:include href="Connection_Interface_Mail_Notification1.xml"/>
+   <xi:include href="Connection_Interface_Power_Saving1.xml"/>
+   <xi:include href="Connection_Interface_Service_Point1.xml"/>
    <xi:include href="Connection_Interface_Sidecars1.xml"/>
    <xi:include href="Connection_Interface_IRC_Command1.xml"/>
   </tp:section>
  </tp:section>
 
- <xi:include href="Channel_Bundle.xml"/>
-
  <tp:section name="Channel Object">
   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
    <p>
@@ -128,7 +124,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    </p>
   </tp:docstring>
   <xi:include href="Channel.xml"/>
-  <xi:include href="Channel_Future.xml"/>
 
   <tp:section name="Channel Types">
    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -136,18 +131,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
      Each Channel implements one of the following types:
     </p>
    </tp:docstring>
-   <xi:include href="Channel_Type_Call.xml"/>
-   <xi:include href="Channel_Type_Contact_List.xml"/>
-   <xi:include href="Channel_Type_Contact_Search.xml"/>
-   <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"/>
+   <xi:include href="Channel_Type_Call1.xml"/>
+   <xi:include href="Channel_Type_Contact_Search1.xml"/>
+   <xi:include href="Channel_Type_DBus_Tube1.xml"/>
+   <xi:include href="Channel_Type_File_Transfer1.xml"/>
+   <xi:include href="Channel_Type_Room_List1.xml"/>
+   <xi:include href="Channel_Type_Server_Authentication1.xml"/>
+   <xi:include href="Channel_Type_Server_TLS_Connection1.xml"/>
+   <xi:include href="Channel_Type_Stream_Tube1.xml"/>
    <xi:include href="Channel_Type_Text.xml"/>
-   <xi:include href="Channel_Type_Tubes.xml"/>
   </tp:section>
 
   <tp:section name="Channel interfaces">
@@ -160,65 +152,56 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </p>
    </tp:docstring>
 
-   <xi:include href="Channel_Interface_Addressing.xml"/>
-   <xi:include href="Channel_Interface_Anonymity.xml"/>
-   <xi:include href="Channel_Interface_Destroyable.xml"/>
-   <xi:include href="Channel_Interface_File_Transfer_Metadata.xml"/>
-   <xi:include href="Channel_Interface_Group.xml"/>
-   <xi:include href="Channel_Interface_Password.xml"/>
-   <xi:include href="Channel_Interface_Room.xml"/>
-   <xi:include href="Channel_Interface_Room_Config.xml"/>
-   <xi:include href="Channel_Interface_SASL_Authentication.xml"/>
-   <xi:include href="Channel_Interface_Captcha_Authentication.xml"/>
-   <xi:include href="Channel_Interface_Credentials_Storage.xml"/>
-   <xi:include href="Channel_Interface_Securable.xml"/>
-   <xi:include href="Channel_Interface_Service_Point.xml"/>
-   <xi:include href="Channel_Interface_Subject.xml"/>
-   <xi:include href="Channel_Interface_Picture.xml"/>
-   <xi:include href="Channel_Interface_Tube.xml"/>
+   <xi:include href="Channel_Interface_Addressing1.xml"/>
+   <xi:include href="Channel_Interface_Anonymity1.xml"/>
+   <xi:include href="Channel_Interface_Captcha_Authentication1.xml"/>
+   <xi:include href="Channel_Interface_Destroyable1.xml"/>
+   <xi:include href="Channel_Interface_File_Transfer_Metadata1.xml"/>
+   <xi:include href="Channel_Interface_Group1.xml"/>
+   <xi:include href="Channel_Interface_Password1.xml"/>
+   <xi:include href="Channel_Interface_Room1.xml"/>
+   <xi:include href="Channel_Interface_Room_Config1.xml"/>
+   <xi:include href="Channel_Interface_SASL_Authentication1.xml"/>
+   <xi:include href="Channel_Interface_Credentials_Storage1.xml"/>
+   <xi:include href="Channel_Interface_Securable1.xml"/>
+   <xi:include href="Channel_Interface_Service_Point1.xml"/>
+   <xi:include href="Channel_Interface_Subject1.xml"/>
+   <xi:include href="Channel_Interface_Picture1.xml"/>
+   <xi:include href="Channel_Interface_Tube1.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>
+        namespace='imt1.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"/>
+    <xi:include href="Channel_Interface_Chat_State1.xml"/>
+    <xi:include href="Channel_Interface_HTML1.xml"/>
+    <xi:include href="Channel_Interface_SMS1.xml"/>
    </tp:section>
 
-   <tp:section name="Streamed Media/Call-related interfaces">
+   <tp:section name="Call-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> and
-       <tp:dbus-ref namespace="ofdT.Channel.Interface">DTMF</tp:dbus-ref>
-       interfaces, which may also appear on <tp:dbus-ref
-       namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels.</p>
+       namespace='imt1.Channel.Type'>Call1</tp:dbus-ref>.</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"/>
+    <xi:include href="Channel_Interface_DTMF1.xml"/>
+    <xi:include href="Channel_Interface_Hold1.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'>Call1</tp:dbus-ref>
+       namespace='imt1.Channel.Type'>Text</tp:dbus-ref> and
+       <tp:dbus-ref namespace='imt1.Channel.Type'>Call1</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"/>
+    <xi:include href="Channel_Interface_Conference1.xml"/>
+    <xi:include href="Channel_Interface_Splittable1.xml"/>
+    <xi:include href="Channel_Interface_Mergeable_Conference1.xml"/>
    </tp:section>
   </tp:section>
  </tp:section>
@@ -234,42 +217,37 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <xi:include href="Authentication_TLS_Certificate.xml"/>
  </tp:section>
 
- <tp:section name="Media">
-  <xi:include href="Media_Session_Handler.xml"/>
-  <xi:include href="Media_Stream_Handler.xml"/>
- </tp:section>
-
  <tp:section name="Calls">
-   <xi:include href="Call_Content.xml"/>
-   <xi:include href="Call_Content_Interface_DTMF.xml"/>
-   <xi:include href="Call_Stream.xml"/>
-   <xi:include href="Call_Interface_Mute.xml"/>
+   <xi:include href="Call1_Content.xml"/>
+   <xi:include href="Call1_Stream.xml"/>
+   <xi:include href="Call1_Content_Interface_DTMF1.xml"/>
+   <xi:include href="Call1_Interface_Mute.xml"/>
  </tp:section>
 
  <tp:section name="Call media interfaces">
    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      <p>
        These interfaces are used when a <tp:dbus-ref
-       namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channel
+       namespace='imt1.Channel.Type'>Call1</tp:dbus-ref> channel
        doesn't have <tp:dbus-ref
-       namespace="ofdT.Channel.Type.Call1">HardwareStreaming</tp:dbus-ref> to
+       namespace="imt1.Channel.Type.Call1">HardwareStreaming</tp:dbus-ref> to
        implement the media streaming aspects of a call.
      </p>
    </tp:docstring>
-   <xi:include href="Call_Content_Interface_Media.xml"/>
-   <xi:include href="Call_Content_Interface_Video_Control.xml"/>
-   <xi:include href="Call_Content_Interface_Audio_Control.xml"/>
-   <xi:include href="Call_Content_Media_Description.xml"/>
-   <xi:include href="Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml"/>
-   <xi:include href="Call_Content_Media_Description_Interface_RTCP_Feedback.xml"/>
+   <xi:include href="Call1_Content_Interface_Media.xml"/>
+   <xi:include href="Call1_Content_Interface_Video_Control1.xml"/>
+   <xi:include href="Call1_Content_Interface_Audio_Control1.xml"/>
+   <xi:include href="Call1_Content_Media_Description.xml"/>
+   <xi:include href="Call1_Content_Media_Description_Interface_RTP_Header_Extensions1.xml"/>
+   <xi:include href="Call1_Content_Media_Description_Interface_RTCP_Feedback1.xml"/>
    <xi:include
-   href="Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml"/>
-   <xi:include href="Call_Stream_Interface_Media.xml"/>
-   <xi:include href="Call_Stream_Endpoint.xml"/>
+   href="Call1_Content_Media_Description_Interface_RTCP_Extended_Reports1.xml"/>
+   <xi:include href="Call1_Stream_Interface_Media.xml"/>
+   <xi:include href="Call1_Stream_Endpoint.xml"/>
  </tp:section>
 
  <tp:section name="Debugging">
-  <xi:include href="Debug.xml"/>
+  <xi:include href="Debug1.xml"/>
  </tp:section>
 </tp:section>
 
@@ -283,13 +261,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </p>
  </tp:docstring>
  <xi:include href="Account_Manager.xml"/>
- <xi:include href="Account_Manager_Interface_Hidden.xml"/>
+ <xi:include href="Account_Manager_Interface_Hidden1.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_Hidden.xml"/>
- <xi:include href="Account_Interface_Storage.xml"/>
- <xi:include href="Account_Interface_External_Password_Storage.xml"/>
+ <xi:include href="Account_Interface_Addressing1.xml"/>
+ <xi:include href="Account_Interface_Avatar1.xml"/>
+ <xi:include href="Account_Interface_Hidden1.xml"/>
+ <xi:include href="Account_Interface_Storage1.xml"/>
+ <xi:include href="Account_Interface_External_Password_Storage1.xml"/>
 </tp:section>
 
 <tp:section name="The Channel Dispatcher">
@@ -302,7 +280,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  </tp:docstring>
  <xi:include href="Channel_Dispatcher.xml"/>
  <xi:include href="Channel_Dispatcher_Interface_Messages1.xml"/>
- <xi:include href="Channel_Dispatcher_Interface_Operation_List.xml"/>
+ <xi:include href="Channel_Dispatcher_Interface_Operation_List1.xml"/>
  <xi:include href="Channel_Dispatch_Operation.xml"/>
  <xi:include href="Channel_Request.xml"/>
 </tp:section>
@@ -320,18 +298,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  <xi:include href="Client_Handler.xml"/>
  <xi:include href="Client_Handler_Future.xml"/>
  <xi:include href="Client_Interface_Requests.xml"/>
-
- <xi:include href="Channel_Handler.xml"/>
 </tp:section>
 
-<xi:include href="Properties_Interface.xml"/>
-
 <xi:include href="errors.xml"/>
 <xi:include href="generic-types.xml"/>
 
-<!-- Never implemented, vague
-<xi:include href="Connection_Interface_Privacy.xml"/> -->
-<!-- Causes havoc, never implemented, unclear requirements
-<xi:include href="Channel_Interface_Transfer.xml"/> -->
-
 </tp:spec>
diff --git a/spec/errors.xml b/spec/errors.xml
index d802152a..747dbe88 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -1,9 +1,9 @@
 <?xml version="1.0" ?>
-<tp:errors xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" namespace="org.freedesktop.Telepathy.Error">
+<tp:errors xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" namespace="im.telepathy1.Error">
 
   <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
     <p>The D-Bus errors used in Telepathy all start with
-      <code>org.freedesktop.Telepathy.Error.</code>. They are used in
+      <code>im.telepathy1.Error.</code>. They are used in
       D-Bus messages of type ERROR, and also as plain strings annotated with
       the <tp:type>DBus_Error_Name</tp:type> type.</p>
 
@@ -16,7 +16,7 @@
       indicate specialized failure conditions. For better interoperability,
       if a suitable Telepathy error exists, it should be preferred.</p>
 
-    <p>The namespace <code>org.freedesktop.Telepathy.Qt4.Error.</code>
+    <p>The namespace <code>im.telepathy1.Qt4.Error.</code>
       is reserved for use by the D-Bus client implementation in telepathy-qt4,
       which uses it to represent certain error situations that did not involve
       a D-Bus ERROR message. These errors are defined and documented as part of
@@ -58,7 +58,7 @@
       The connection is not currently connected and cannot be used.
       This error may also be raised when operations are performed on a
       Connection for which
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">StatusChanged</tp:dbus-ref>
+      <tp:dbus-ref namespace="im.telepathy1.Connection">StatusChanged</tp:dbus-ref>
       has signalled status Disconnected for reason None.
 
       <tp:rationale>
@@ -502,7 +502,7 @@
 
       <tp:rationale>
         For instance, the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
+          namespace="im.telepathy1">ChannelDispatcher</tp:dbus-ref>
         might raise this error for some or all channel requests if it has
         detected that there is not enough free memory.
       </tp:rationale>
@@ -515,10 +515,10 @@
       Raised if a request cannot be satisfied without violating an earlier
       request for anonymity, and the earlier request specified that raising
       an error is preferable to disclosing the user's identity (for instance
-      via <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-        >Connection.Interface.Anonymity.AnonymityMandatory</tp:dbus-ref> or
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy"
-        >Channel.Interface.Anonymity.AnonymityMandatory</tp:dbus-ref>).
+      via <tp:dbus-ref namespace="im.telepathy1"
+        >Connection.Interface.Anonymity1.AnonymityMandatory</tp:dbus-ref> or
+      <tp:dbus-ref namespace="im.telepathy1"
+        >Channel.Interface.Anonymity1.AnonymityMandatory</tp:dbus-ref>).
     </tp:docstring>
   </tp:error>
 
@@ -534,7 +534,7 @@
     <tp:added version="0.21.2"/>
     <tp:docstring>
       Raised when an incoming or outgoing <tp:dbus-ref
-      namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> is
+      namespace="imt1.Channel.Type">Call1</tp:dbus-ref> is
       rejected by the the receiver.
     </tp:docstring>
   </tp:error>
@@ -573,12 +573,13 @@
 
       <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:value-ref type="Media_Stream_Error">Invalid_CM_Behavior</tp:value-ref>,
+        errors bad-format, invalid-xml, etc., which can't happen
+        unless the local (or remote) XMPP implementation is
+        faulty. This is also analogous to
+        Media_Stream_Error_Invalid_CM_Behavior,
         <code>TP_DBUS_ERROR_INCONSISTENT</code> in telepathy-glib, and
-        <code>TELEPATHY_QT4_ERROR_INCONSISTENT</code> in telepathy-qt4.
+        <code>TELEPATHY_QT4_ERROR_INCONSISTENT</code> in
+        telepathy-qt4.
       </tp:rationale>
     </tp:docstring>
   </tp:error>
@@ -587,7 +588,7 @@
     <tp:added version="0.21.12"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Raised as a
-        <tp:dbus-ref namespace="ofdT.Connection">ConnectionError</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Connection">ConnectionError</tp:dbus-ref>
         when a Connection cannot be established because either the Connection
         Manager or its support library (e.g. wocky, papyon, sofiasip) requires
         upgrading to support a newer protocol version.</p>
@@ -624,14 +625,14 @@
     <tp:added version="0.22.1"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Raised if the user has insufficient
-        <tp:dbus-ref namespace="ofdT.Connection.Interface">Balance</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Connection.Interface">Balance1</tp:dbus-ref>
         to place a call or send a message.</p>
 
       <p>The key 'balance-required' MAY be included in
-        <tp:dbus-ref namespace="ofdT.Channel.Type.Call1">CallStateDetails</tp:dbus-ref>
+        <tp:dbus-ref namespace="imt1.Channel.Type.Call1">CallStateDetails</tp:dbus-ref>
         or a delivery report's <tp:type>Message_Part</tp:type>
         (with the same units and scale as
-        <tp:dbus-ref namespace="ofdT.Connection.Interface.Balance">AccountBalance</tp:dbus-ref>)
+        <tp:dbus-ref namespace="imt1.Connection.Interface.Balance1">AccountBalance</tp:dbus-ref>)
         to indicate how much credit is required to make this call or send
         this message.</p>
     </tp:docstring>
@@ -641,7 +642,7 @@
     <tp:added version="0.25.2"/>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Raised if the <tp:dbus-ref 
-        namespace="ofdT.Channel.Interface">CaptchaAuthentication1</tp:dbus-ref> 
+        namespace="imt1.Channel.Interface">CaptchaAuthentication1</tp:dbus-ref>
         Handler either has no UI to present captchas, or it does, but wasn't 
         able to answer any of the captchas given.</p>
     </tp:docstring>
diff --git a/spec/generic-types.xml b/spec/generic-types.xml
index 2676e453..4be8bec2 100644
--- a/spec/generic-types.xml
+++ b/spec/generic-types.xml
@@ -20,14 +20,14 @@
   <tp:simple-type name="DBus_Bus_Name" type="s"
     array-name="DBus_Bus_Name_List">
     <tp:docstring>A string representing a D-Bus bus name - either a well-known
-      name like "org.freedesktop.Telepathy.MissionControl" or a unique name
+      name like "im.telepathy1.MissionControl" or a unique name
       like ":1.123"</tp:docstring>
   </tp:simple-type>
 
   <tp:simple-type name="DBus_Well_Known_Name" type="s"
     array-name="DBus_Well_Known_Name_List">
     <tp:docstring>A string representing a D-Bus well-known
-      name like "org.freedesktop.Telepathy.MissionControl".</tp:docstring>
+      name like "im.telepathy1.MissionControl".</tp:docstring>
   </tp:simple-type>
 
   <tp:simple-type name="DBus_Unique_Name" type="s"
@@ -110,7 +110,7 @@
         as for <tp:type>Socket_Address_IPv6</tp:type>.
       </tp:docstring>
     </tp:member>
-    <tp:member type="q" name="Port">
+    <tp:member type="u" name="Port">
       <tp:docstring>The TCP or UDP port number.</tp:docstring>
     </tp:member>
   </tp:struct>
@@ -122,7 +122,7 @@
         numbers, each between 0 and 255 inclusive, e.g.
         "192.168.0.1".</tp:docstring>
     </tp:member>
-    <tp:member type="q" name="Port">
+    <tp:member type="u" name="Port">
       <tp:docstring>The TCP or UDP port number.</tp:docstring>
     </tp:member>
   </tp:struct>
@@ -133,7 +133,7 @@
       <tp:docstring>An IPv6 address literal as specified by RFC2373
         section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
     </tp:member>
-    <tp:member type="q" name="Port">
+    <tp:member type="u" name="Port">
       <tp:docstring>The TCP or UDP port number.</tp:docstring>
     </tp:member>
   </tp:struct>
diff --git a/spec/template.xml b/spec/template.xml
index 283804a9..f5a9529d 100644
--- a/spec/template.xml
+++ b/spec/template.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<node name="/Foo"
+<node name="/Foo1"
   xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
 
   <tp:copyright>Copyright © 2010 Collabora Ltd.</tp:copyright>
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Foo.DRAFT"
+  <interface name="im.telepathy1.Foo1"
     tp:causes-havoc="experimental">
     <tp:added version="0.UNRELEASED">(draft 1)</tp:added>
 
diff --git a/test/input/_Test.xml b/test/input/_Test.xml
index 891683ef..0eb9a0c8 100644
--- a/test/input/_Test.xml
+++ b/test/input/_Test.xml
@@ -17,7 +17,7 @@ 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.SpecAutoGenTest">
+  <interface name="im.telepathy1.SpecAutoGenTest">
 
     <tp:client-interest/>
     <tp:client-interest name="badgers"/>
@@ -41,8 +41,8 @@ USA.</p>
         <tp:docstring>Array of structs containing whatever seems appropriate.</tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.SpecAutoGenTest.MiscError"/>
-        <tp:error name="org.freedesktop.Telepathy.SpecAutoGenTest.OtherError">
+        <tp:error name="im.telepathy1.SpecAutoGenTest.MiscError"/>
+        <tp:error name="im.telepathy1.SpecAutoGenTest.OtherError">
           <tp:docstring>Raised if the badger or the snake eats the mushrooms</tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -72,12 +72,6 @@ USA.</p>
       </tp:docstring>
     </signal>
 
-    <tp:property name="wobbly" type="b">
-      <tp:docstring>
-        Whether or not this badger is wobbly.
-      </tp:docstring>
-    </tp:property>
-
     <property name="Introspective" tp:name-for-bindings="Introspective"
       type="b" access="read">
       <tp:docstring>
diff --git a/test/input/errors.xml b/test/input/errors.xml
index 7bfa1d66..69480496 100644
--- a/test/input/errors.xml
+++ b/test/input/errors.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" ?>
-<tp:errors xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" namespace='org.freedesktop.Telepathy'>
+<tp:errors xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" namespace='im.telepathy1'>
   <tp:error name="Spec AutoGen Test.Misc Error">
     <tp:docstring>
       Raised whenever appropriate.
diff --git a/test/test-specparser.py b/test/test-specparser.py
index 164b4df8..806d7fc8 100755..100644
--- a/test/test-specparser.py
+++ b/test/test-specparser.py
@@ -12,15 +12,15 @@ spec_path = os.path.join (test_dir, 'input/all.xml')
 
 def test_specparser ():
     """
->>> spec = specparser.parse (spec_path, 'org.freedesktop.Telepathy.SpecAutoGenTest')
+>>> spec = specparser.parse (spec_path, 'im.telepathy1.SpecAutoGenTest')
 >>> spec
 Spec(telepathy-spec tools test case)
 
 >>> spec.interfaces
-[Interface(org.freedesktop.Telepathy.SpecAutoGenTest)]
+[Interface(im.telepathy1.SpecAutoGenTest)]
 
->>> spec.errors
-{u'org.freedesktop.Telepathy.SpecAutoGenTest.OtherError': Error(org.freedesktop.Telepathy.SpecAutoGenTest.OtherError), u'org.freedesktop.Telepathy.SpecAutoGenTest.MiscError': Error(org.freedesktop.Telepathy.SpecAutoGenTest.MiscError)}
+>>> sorted(spec.errors.items())
+[(u'im.telepathy1.SpecAutoGenTest.MiscError', Error(im.telepathy1.SpecAutoGenTest.MiscError)), (u'im.telepathy1.SpecAutoGenTest.OtherError', Error(im.telepathy1.SpecAutoGenTest.OtherError))]
 
 >>> spec.generic_types
 []
@@ -29,36 +29,36 @@ Spec(telepathy-spec tools test case)
 
 >>> i = spec.interfaces[0]
 >>> i
-Interface(org.freedesktop.Telepathy.SpecAutoGenTest)
+Interface(im.telepathy1.SpecAutoGenTest)
 
 >>> print i.causes_havoc
 None
 
 >>> i.methods
-[Method(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff)]
+[Method(im.telepathy1.SpecAutoGenTest.DoStuff)]
 
 >>> i.methods[0].args
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 AttributeError: 'Method' object has no attribute 'args'
 >>> i.methods[0].in_args
-[Arg(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff.badger:b), Arg(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff.mushroom:a{sv}), Arg(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff.snake:s)]
+[Arg(im.telepathy1.SpecAutoGenTest.DoStuff.badger:b), Arg(im.telepathy1.SpecAutoGenTest.DoStuff.mushroom:a{sv}), Arg(im.telepathy1.SpecAutoGenTest.DoStuff.snake:s)]
 >>> i.methods[0].out_args
-[Arg(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff.misc:a(uv))]
+[Arg(im.telepathy1.SpecAutoGenTest.DoStuff.misc:a(uv))]
 
 >>> i.methods[0].possible_errors
-[PossibleError(org.freedesktop.Telepathy.SpecAutoGenTest.MiscError), PossibleError(org.freedesktop.Telepathy.SpecAutoGenTest.OtherError)]
+[PossibleError(im.telepathy1.SpecAutoGenTest.MiscError), PossibleError(im.telepathy1.SpecAutoGenTest.OtherError)]
 >>> map (lambda e: e.get_error (), i.methods[0].possible_errors)
-[Error(org.freedesktop.Telepathy.SpecAutoGenTest.MiscError), Error(org.freedesktop.Telepathy.SpecAutoGenTest.OtherError)]
+[Error(im.telepathy1.SpecAutoGenTest.MiscError), Error(im.telepathy1.SpecAutoGenTest.OtherError)]
 
 >>> i.signals
-[Signal(org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened)]
+[Signal(im.telepathy1.SpecAutoGenTest.StuffHappened)]
 
 >>> i.signals[0].args
-[Arg(org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened.stoat:ay), Arg(org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened.ferret:s), Arg(org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened.weasel:b)]
+[Arg(im.telepathy1.SpecAutoGenTest.StuffHappened.stoat:ay), Arg(im.telepathy1.SpecAutoGenTest.StuffHappened.ferret:s), Arg(im.telepathy1.SpecAutoGenTest.StuffHappened.weasel:b)]
 
 >>> i.properties
-[Property(org.freedesktop.Telepathy.SpecAutoGenTest.Introspective:b)]
+[Property(im.telepathy1.SpecAutoGenTest.Introspective:b)]
 
 >>> i.properties[0].type
 ''
@@ -81,13 +81,13 @@ None
 [(u'LowBit', u'1'), (u'HighBit', u'128')]
 
 >>> sorted(spec.everything.items())
-[(u'org.freedesktop.Telepathy.SpecAutoGenTest', ClientInterest(org.freedesktop.Telepathy.SpecAutoGenTest)), (u'org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff', Method(org.freedesktop.Telepathy.SpecAutoGenTest.DoStuff)), (u'org.freedesktop.Telepathy.SpecAutoGenTest.Introspective', Property(org.freedesktop.Telepathy.SpecAutoGenTest.Introspective:b)), (u'org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened', Signal(org.freedesktop.Telepathy.SpecAutoGenTest.StuffHappened)), (u'org.freedesktop.Telepathy.SpecAutoGenTest.wobbly', AwkwardTelepathyProperty(org.freedesktop.Telepathy.SpecAutoGenTest.wobbly:b)), (u'org.freedesktop.Telepathy.SpecAutoGenTest/badgers', ClientInterest(org.freedesktop.Telepathy.SpecAutoGenTest/badgers))]
+[(u'im.telepathy1.SpecAutoGenTest', ClientInterest(im.telepathy1.SpecAutoGenTest)), (u'im.telepathy1.SpecAutoGenTest.DoStuff', Method(im.telepathy1.SpecAutoGenTest.DoStuff)), (u'im.telepathy1.SpecAutoGenTest.Introspective', Property(im.telepathy1.SpecAutoGenTest.Introspective:b)), (u'im.telepathy1.SpecAutoGenTest.StuffHappened', Signal(im.telepathy1.SpecAutoGenTest.StuffHappened)), (u'im.telepathy1.SpecAutoGenTest/badgers', ClientInterest(im.telepathy1.SpecAutoGenTest/badgers))]
 
 
 >>> map (lambda o: i.added, spec.everything.values ())
-[None, None, None, None, None, None]
+[None, None, None, None, None]
 >>> map (lambda o: i.deprecated, spec.everything.values ())
-[None, None, None, None, None, None]
+[None, None, None, None, None]
     """
 
 if __name__ == '__main__':
diff --git a/tools/doc-generator.py b/tools/doc-generator.py
index 6117a6ca..6117a6ca 100755..100644
--- a/tools/doc-generator.py
+++ b/tools/doc-generator.py
diff --git a/tools/specparser.py b/tools/specparser.py
index 3ad1f9a3..a2791d5f 100644
--- a/tools/specparser.py
+++ b/tools/specparser.py
@@ -375,9 +375,9 @@ WARNING: Key '%s' not known in namespace '%s'
             namespace = n.getAttribute('namespace')
             key = getText(n)
 
-            if namespace.startswith('ofdT.') or namespace == 'ofdT':
-                namespace = namespace.replace('ofdT',
-                    'org.freedesktop.Telepathy')
+            if namespace.startswith('imt1.') or namespace == 'imt1':
+                namespace = namespace.replace('imt1',
+                    'im.telepathy1')
 
             try:
                 o = spec.lookup(key, namespace=namespace)
@@ -399,8 +399,8 @@ WARNING: Key '%s' not known in namespace '%s'
             namespace = n.getAttribute('namespace')
 
             if namespace:
-                if namespace.startswith('ofdT.'):
-                    namespace = 'org.freedesktop.Telepathy.' + namespace[5:]
+                if namespace.startswith('imt1.'):
+                    namespace = namespace.replace('imt1', 'im.telepathy1')
             else:
                 namespace = root_namespace
 
@@ -575,6 +575,10 @@ class Typed(Base):
         if self.dbus_type == '':
             raise UntypedItem("Node referred to by '%s' has no type" % dom.toxml())
 
+        if 'n' in self.dbus_type or 'q' in self.dbus_type:
+            raise UntypedItem("Node referred to by '%r' has type '%s' which is unsupported "
+                              "by dbus-glib; use 'u' instead" % (self, self.dbus_type))
+
     def get_type(self):
         return self.get_spec().lookup_type(self.type)
 
@@ -703,18 +707,6 @@ class Property(DBusConstruct, Typed, HasEmitsChangedAnnotation):
 
         return ', '.join(descriptions)
 
-class AwkwardTelepathyProperty(Typed):
-    def __init__(self, parent, namespace, dom):
-        Typed.__init__(self, parent, namespace, dom)
-
-        print >> sys.stderr, """
-WARNING: Old-style Telepathy properties are deprecated!
-         (<tp:property> in %s)
-        """.strip() % (parent)
-
-    def get_type_name(self):
-        return 'Telepathy Property'
-
 class Arg(Typed):
     DIRECTION_IN, DIRECTION_OUT, DIRECTION_UNSPECIFIED = range(3)
 
@@ -812,8 +804,6 @@ class Interface(Base, HasEmitsChangedAnnotation):
                                      dom.getElementsByTagName('property'))
         self.signals = build_list(self, Signal, self.name,
                                   dom.getElementsByTagName('signal'))
-        self.tpproperties = build_list(self, AwkwardTelepathyProperty,
-                self.name, dom.getElementsByTagNameNS(XMLNS_TP, 'property'))
 
         hct_elems = (
             dom.getElementsByTagNameNS(XMLNS_TP, 'handler-capability-token') +
@@ -1315,7 +1305,7 @@ class Spec(SectionBase):
                 self.everything[interface.name] = interface
 
                 for things in [ 'methods', 'signals', 'properties',
-                                'tpproperties', 'contact_attributes',
+                                'contact_attributes',
                                 'handler_capability_tokens',
                                 'client_interests' ]:
                     for thing in getattr(interface, things):
@@ -1372,7 +1362,7 @@ def build_dict(parent, type_, namespace, nodes):
     """Build a dictionary of D-Bus names to Python objects representing that
        name using the XML node for that item in the spec.
 
-       e.g. 'org.freedesktop.Telepathy.Channel' : Interface(Channel)
+       e.g. 'im.telepathy1.Channel' : Interface(Channel)
 
        Works for any Python object inheriting from 'Base' whose XML node
        implements the 'name' attribute.