Update to spec 0.23.4

Except for Call stuff because the example using extensions needs
update to new spec.

14 files changed, 318 insertions, 61 deletions

diff --git a/spec/Account_Manager.xml b/spec/Account_Manager.xml
index cd82e7f53..52cd42a1e 100644
--- a/spec/Account_Manager.xml
+++ b/spec/Account_Manager.xml
@@ -25,19 +25,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         details.</p>
 
       <p>The current account manager is defined to be the process that owns
-        the well-known bus name org.freedesktop.Telepathy.AccountManager on
+        the well-known bus name <tt>org.freedesktop.Telepathy.AccountManager</tt> on
         the session bus. This process must export an
-        /org/freedesktop/Telepathy/AccountManager object with the
+        <tt>/org/freedesktop/Telepathy/AccountManager</tt> object with the
         AccountManager interface.</p>
-
-      <p>Until a mechanism exists for making a reasonable automatic choice
-        of AccountManager implementation, implementations SHOULD NOT
-        register as an activatable service for the AccountManager's
-        well-known bus name. Instead, it is RECOMMENDED that some component
-        of the user's session will select and activate a particular
-        implementation, and that other Telepathy-enabled programs can
-        detect whether Telepathy is in use by checking whether the
-        AccountManager's well-known name is in use at runtime.</p>
     </tp:docstring>
     <tp:added version="0.17.2"/>
 
@@ -275,16 +266,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-            <p>The Connection_Manager is not installed or does not
-              implement the given Protocol, or one of the properties in the
-              Properties argument is unsupported.</p>
+            <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:docstring xmlns="http://www.w3.org/1999/xhtml">
-            <p>The Parameters provided omit a required parameter
-              or provide unsupported parameter, or the type of one
-              of the Parameters or Properties is inappropriate.</p>
+            <p>The <var>Parameters</var> provided were unacceptable: they might
+              omit a
+              <tp:value-ref type='Conn_Mgr_Param_Flags'>Required</tp:value-ref>
+              parameter, include an unsupported parameter, or have a value of
+              the wrong type.</p>
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
diff --git a/spec/Channel_Interface_DTMF.xml b/spec/Channel_Interface_DTMF.xml
index d74ea6fa7..bb579a113 100644
--- a/spec/Channel_Interface_DTMF.xml
+++ b/spec/Channel_Interface_DTMF.xml
@@ -21,12 +21,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <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.Call.DRAFT"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
     </tp:xor-requires>
     <tp:changed version="0.19.6">The <tp:type>Stream_ID</tp:type>s in this
       interface should now be ignored by CMs. This is primarily to allow this
       interface to be used with <tp:dbus-ref
-      namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+      namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
       channels.</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group.xml
index 92de9c5c4..890e84ebe 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group.xml
@@ -334,6 +334,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </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>
@@ -352,6 +356,44 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </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"/>
+
+      <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>
+      <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring>
+          The string identifiers for handles mentioned in this signal, to
+          give clients the minimal information necessary to create contacts
+          without waiting for round-trips. Connection managers MUST include at
+          least the identifiers for all handles in the Added map, and MAY
+          include those from Removed array.
+        </tp:docstring>
+      </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>
@@ -519,6 +561,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </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>
@@ -527,6 +573,29 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </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
+        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"/>
+
+      <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
+        <tp:docstring>
+          The new value of the SelfHandle property.
+        </tp:docstring>
+      </arg>
+      <arg type="s" name="Self_ID">
+        <tp:docstring>
+          The new value of the SelfHandle property's identifier.
+        </tp:docstring>
+      </arg>
+    </signal>
+
     <property name="SelfHandle" type="u" tp:type="Contact_Handle"
       access="read" tp:name-for-bindings="Self_Handle">
       <tp:docstring>
@@ -545,6 +614,23 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Channel_Group_Flag_Properties is not present.</tp:added>
     </property>
 
+    <property name="MemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
+      access="read" tp:name-for-bindings="Member_Identifiers">
+      <tp:docstring>
+        The string identifiers for handles mentioned in this channel, to
+        give clients the minimal information necessary to create contacts
+        without waiting for round-trips. Connection managers MUST include at
+        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"/>
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold.xml
index ef5a08f19..69d295d97 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold.xml
@@ -22,7 +22,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   <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.Call.DRAFT"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
     </tp:xor-requires>
     <tp:changed version="0.17.4">first API-stable version</tp:changed>
 
@@ -31,7 +32,8 @@ 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">CallState</tp:dbus-ref>.)</p>
+          namespace="org.freedesktop.Telepathy.Channel.Interface"
+        >CallState</tp:dbus-ref>.)</p>
 
       <p>If you place a channel on hold, this indicates that you do not wish
         to be sent media streams by any of its members and will be ignoring
@@ -40,6 +42,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         an actively used channel (e.g. in a GSM or PBX call, it will be
         necessary to place an active call on hold before you can start
         another call).</p>
+
+      <p>This can also be used for putting a single Content on hold, if the
+        protocol supports it (This interface is in the Channel namespace for
+        historical reasons).</p>
     </tp:docstring>
 
     <method name="GetHoldState" tp:name-for-bindings="Get_Hold_State">
@@ -107,14 +113,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The connection manager is attempting to move to state Held, but
           has not yet completed that operation. It is unspecified whether
           any, all or none of the streams making up the channel are on hold.
+          Examining the Hold state of Call Contents (if applicable) may
+          provide more useful information.
         </tp:docstring>
       </tp:enumvalue>
 
       <tp:enumvalue value="3" suffix="Pending_Unhold">
         <tp:docstring>
-          The connection manager is attempting to move to state Held, but
+          The connection manager is attempting to move to state Unheld, but
           has not yet completed that operation. It is unspecified whether
           any, all or none of the streams making up the channel are on hold.
+          Examining the Hold state of Call Contents (if applicable) may
+          provide more useful information.
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index 62e83846a..a88576dc8 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -599,15 +599,66 @@ USA.</p>
 
             <dt>supersedes (s – <tp:type>Protocol_Message_Token</tp:type>)</dt>
             <dd>If present, this message supersedes a previous message,
-              identified by its <tt>protocol-token</tt> or
-              <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.
+              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>
-              </dd>
+
+              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
@@ -996,7 +1047,7 @@ USA.</p>
           recipient. If a delivery failure is detected later, this is
           signalled by receiving a message whose <code>message-type</code>
           header maps to
-          <tp:type>Channel_Text_Message_Type</tp:type>_Delivery_Report.
+          <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>
diff --git a/spec/Channel_Interface_SMS.xml b/spec/Channel_Interface_SMS.xml
index 480a2a77c..497e94519 100644
--- a/spec/Channel_Interface_SMS.xml
+++ b/spec/Channel_Interface_SMS.xml
@@ -50,7 +50,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 { ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
       ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
   ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
-      <tp:type>Handle_Type</tp:type>_Contact,<br/>
+      <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
   ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
       True,<br/>
 }</code></blockquote>
@@ -74,7 +74,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
      ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
     ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
-       <tp:type>Handle_Type</tp:type>_Contact,<br/>
+       <tp: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/>
@@ -82,7 +82,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
        ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
     ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
-       <tp:type>Handle_Type</tp:type>_Contact,<br/>
+       <tp: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>,
diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml
index fbb67925e..dd10049e1 100644
--- a/spec/Channel_Request.xml
+++ b/spec/Channel_Request.xml
@@ -218,7 +218,7 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A dictionary of metadata provided by the channel
           requester, which the handler and other clients MAY choose to
-          interpret.  Currently no standard keys are defined; clients MAY
+          interpret.  Clients MAY
           choose to use platform-specific keys for their own purposes, but MUST
           ignore unknown keys and MUST cope with expected keys being
           missing. Clients SHOULD namespace hint names by having them
@@ -249,6 +249,48 @@
           namespace="ofdT.Client.Interface.Requests">AddRequest</tp:dbus-ref>
           by the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>.</p>
+        <p>The following standardised hints are defined:</p>
+
+        <dl>
+          <dt>org.freedesktop.Telepathy.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:rationale>
+              This hint allows the user to request a channel in their
+              preferred client in a situation where there are two chat
+              handlers (for example: requesting a channel in Empathy which is
+              currently being handled by gnome-shell).
+            </tp:rationale>
+
+            If the channel is currently unhandled, clients SHOULD ignore this
+            hint.
+
+            <tp:rationale>
+              It is assumed that Mission Control will correctly delegate an
+              unhandled channel to the preferred Handler. This allows
+              requesting clients to always include this hint in their channel
+              request.
+            </tp:rationale>
+
+            The Handler should check each
+            <tp:dbus-ref namespace="ofdT">ChannelRequest</tp:dbus-ref>
+            of the Requests_Satisfied parameter of
+            <tp:dbus-ref namespace="ofdT.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>
+              satisfies two separate requests which have different
+              <tp:member-ref>PreferredHandler</tp:member-ref>s.
+            </tp:rationale>
+          </dd>
+        </dl>
+
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Type_File_Transfer.xml b/spec/Channel_Type_File_Transfer.xml
index 6963d2133..f50b96344 100644
--- a/spec/Channel_Type_File_Transfer.xml
+++ b/spec/Channel_Type_File_Transfer.xml
@@ -96,7 +96,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentType" type="s" access="read"
-      tp:name-for-bindings="Content_Type">
+      tp:name-for-bindings="Content_Type" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The file's MIME type. This cannot change once the channel has
         been created.</p>
@@ -109,7 +109,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Filename" type="s" access="read"
-      tp:name-for-bindings="Filename">
+      tp:name-for-bindings="Filename" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of the file on the sender's side. This is therefore given
         as a suggested filename for the receiver. This cannot change
@@ -126,7 +126,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Size" type="t" access="read"
-      tp:name-for-bindings="Size">
+      tp:name-for-bindings="Size" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The size of the file. If this property is set, then the file
         transfer is guaranteed to be this size. This cannot change once
@@ -145,7 +145,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentHashType" type="u" tp:type="File_Hash_Type"
-      access="read" tp:name-for-bindings="Content_Hash_Type">
+      access="read" tp:name-for-bindings="Content_Hash_Type" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The type of the <tp:member-ref>ContentHash</tp:member-ref> property.</p>
 
@@ -168,7 +169,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentHash" type="s" access="read"
-      tp:name-for-bindings="Content_Hash">
+      tp:name-for-bindings="Content_Hash" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Hash of the contents of the file transfer, of type described
         in the value of the <tp:member-ref>ContentHashType</tp:member-ref>
@@ -184,7 +186,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Description" type="s" access="read"
-      tp:name-for-bindings="Description">
+      tp:name-for-bindings="Description" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Description of the file transfer. This cannot change once the
         channel has been created.</p>
@@ -197,7 +199,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Date" type="x" access="read"
-      tp:type="Unix_Timestamp64" tp:name-for-bindings="Date">
+      tp:type="Unix_Timestamp64" tp:name-for-bindings="Date" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The last modification time of the file being transferred. This
         cannot change once the channel has been created</p>
@@ -210,7 +213,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <property name="AvailableSocketTypes" type="a{uau}"
       tp:type="Supported_Socket_Map" access="read"
-      tp:name-for-bindings="Available_Socket_Types">
+      tp:name-for-bindings="Available_Socket_Types"
+      tp:immutable="yes" tp:requestable="yes">
       <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)
@@ -243,7 +247,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="InitialOffset" type="t" access="read"
-      tp:name-for-bindings="Initial_Offset">
+      tp:name-for-bindings="Initial_Offset" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The offset in bytes from where the file should be sent. This MUST
         be respected by both the receiver and the sender after the state
@@ -276,7 +280,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>For incoming file transfers, this property MAY be set by the channel
         handler before calling <tp:member-ref>AcceptFile</tp:member-ref> to
-        inform observers where the incoming file will be saved.
+        inform observers where the incoming file will be saved. If set by an
+        approver, the handler MUST save the file to that location.
         Setting this property once <tp:member-ref>AcceptFile</tp:member-ref>
         has been called MUST fail. Once this property has been set
         <tp:member-ref>URIDefined</tp:member-ref> is emitted.</p>
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index 0cd4d5bb2..86bf567fc 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -555,14 +555,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>Simple one-to-one chats (such as streams of private messages in
         XMPP or IRC) should be represented by a Text channel whose
         <tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>
-        is <tp:type>Handle_Type</tp:type>_Contact. The expected way to
-        request such a channel is to set the ChannelType, TargetHandleType,
-        and either TargetHandle or TargetID in a call to EnsureChannel.</p>
+        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>,
+        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
+        <tp:dbus-ref
+        namespace='ofdT.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:type>Handle_Type</tp:type>_Room and the <tp:dbus-ref
-          namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        channels with <tp:dbus-ref
+        namespace="ofdT.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>
         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>
@@ -571,7 +579,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>Unnamed, transient chat rooms which cannot be rejoined by their
         unique identifier (e.g. a conversation on MSN which has, or once had,
         three or more participants) are expected to be represented by Text
-        channels with Handle_Type_None (and hence TargetHandle 0), the
+        channels with <tp:dbus-ref
+        namespace="ofdT.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>
         interface, and optionally the
         <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
@@ -580,7 +591,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>On protocols like MSN where a conversation with a user is actually
         just a nameless chat room starting with exactly two members, to which
         more members can be invited, the initial one-to-one conversation
-        SHOULD be represented with Handle_Type_Contact. If a third participant
+        SHOULD be represented with <tp:dbus-ref
+        namespace="ofdT.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
@@ -606,8 +620,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:dbus-ref
           namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
         signal. The new channel should resemble the old channel, but have
-        Requested = FALSE regardless of its previous value; the InitiatorHandle
-        and InitiatorID should correspond to the sender of one of the pending
+        <tp:dbus-ref namespace='ofdT.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>
+        should correspond to the sender of one of the pending
         messages.</p>
 
       <tp:rationale>
diff --git a/spec/Connection_Interface_Forwarding.xml b/spec/Connection_Interface_Forwarding.xml
index e5457b1ea..32c7e1cbb 100644
--- a/spec/Connection_Interface_Forwarding.xml
+++ b/spec/Connection_Interface_Forwarding.xml
@@ -92,7 +92,7 @@
         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'>Call.DRAFT</tp:dbus-ref> channels, the
+        namespace='ofdT.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>
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index dbcaf816e..0a833709a 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -723,11 +723,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <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[]"
diff --git a/spec/all.xml b/spec/all.xml
index ca6689f60..18b8b3295 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -3,7 +3,7 @@
   xmlns:xi="http://www.w3.org/2001/XInclude">
 
 <tp:title>Telepathy D-Bus Interface Specification</tp:title>
-<tp:version>0.23.2</tp:version>
+<tp:version>0.23.4</tp:version>
 
 <tp:copyright>Copyright © 2005-2011 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2011 Nokia Corporation</tp:copyright>
@@ -191,7 +191,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
        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'>Call.DRAFT</tp:dbus-ref> channels.</p>
+       namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels.</p>
     </tp:docstring>
 
     <xi:include href="Channel_Interface_Call_State.xml"/>
@@ -206,7 +206,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
        chat rooms. They are primarily intended for <tp:dbus-ref
        namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>, <tp:dbus-ref
        namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref> and
-       <tp:dbus-ref namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+       <tp:dbus-ref namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
        channels, but may also appear on other types of channel.</p>
     </tp:docstring>
 
@@ -236,9 +236,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  <tp:section name="Calls">
    <xi:include href="Call_Content.xml"/>
    <xi:include href="Call_Content_Interface_Media.xml"/>
-   <xi:include href="Call_Content_Interface_Mute.xml"/>
+   <xi:include href="Call_Interface_Mute.xml"/>
    <xi:include href="Call_Content_Interface_Video_Control.xml"/>
-   <xi:include href="Call_Content_Codec_Offer.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="Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml"/>
    <xi:include href="Call_Stream.xml"/>
    <xi:include href="Call_Stream_Interface_Media.xml"/>
    <xi:include href="Call_Stream_Endpoint.xml"/>
diff --git a/spec/errors.xml b/spec/errors.xml
index a5271b5b6..7726f3cfd 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -386,6 +386,45 @@
     </tp:docstring>
   </tp:error>
 
+  <tp:error name="Media.Codecs Incompatible">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      Raised when the local streaming implementation has no codecs in common
+      with the remote side.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Media.Unsupported Type">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      The media stream type requested is not supported by either the
+      local or remote side.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Media.Streaming Error">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      Raised when the call's streaming implementation has some kind of internal
+      error.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Internal_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
   <tp:error name="Connection Refused">
     <tp:docstring>
       Raised when a connection is refused.
@@ -495,7 +534,7 @@
     <tp:added version="0.21.2"/>
     <tp:docstring>
       Raised when an incoming or outgoing <tp:dbus-ref
-      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
+      namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> is
       rejected by the the receiver.
     </tp:docstring>
   </tp:error>
@@ -537,7 +576,7 @@
         errors bad-format, invalid-xml, etc., which can't happen unless
         the local (or remote) XMPP implementation is faulty. This is
         also analogous to
-        <tp:type>Media_Stream_Error</tp:type>_Invalid_CM_Behavior,
+        <tp:value-ref type="Media_Stream_Error">Invalid_CM_Behavior</tp:value-ref>,
         <code>TP_DBUS_ERROR_INCONSISTENT</code> in telepathy-glib, and
         <code>TELEPATHY_QT4_ERROR_INCONSISTENT</code> in telepathy-qt4.
       </tp:rationale>
@@ -589,7 +628,7 @@
         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.Call.DRAFT">CallStateDetails</tp:dbus-ref>
+        <tp:dbus-ref namespace="ofdT.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>)
diff --git a/spec/template.xml b/spec/template.xml
index 726472070..283804a94 100644
--- a/spec/template.xml
+++ b/spec/template.xml
@@ -22,7 +22,7 @@
 
   <interface name="org.freedesktop.Telepathy.Foo.DRAFT"
     tp:causes-havoc="experimental">
-    <tp:added version="0.21.UNRELEASED">(draft 1)</tp:added>
+    <tp:added version="0.UNRELEASED">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Foo.</p>