Bump all call interfaces to DRAFT2

Note that some interfaces never had a DRAFT version merged into master,
but I think that having everything as DRAFT2 makes everyone's lives easier.

1 files changed, 33 insertions, 33 deletions

diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call_Content_Interface_Media.xml
index 95710c83..c3c85c0d 100644
--- a/spec/Call_Content_Interface_Media.xml
+++ b/spec/Call_Content_Interface_Media.xml
@@ -24,13 +24,13 @@
       name="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT2"
       tp:causes-havoc="experimental">
     <tp:added version="UNRELEASED">(draft 2)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT2"/>
 
     <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.Call">Content.DRAFT</tp:dbus-ref> interface is
+        namespace="ofdT.Call">Content.DRAFT2</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
@@ -40,9 +40,9 @@
       <h4>Codec Negotiation</h4>
 
       <p>When a new <tp:dbus-ref
-        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channel
+        namespace="ofdT.Channel.Type">Call.DRAFT2</tp:dbus-ref> channel
         appears (whether it was requested or not) a <tp:dbus-ref
-        namespace="ofdT.Call.Content">MediaDescription.DRAFT</tp:dbus-ref>
+        namespace="ofdT.Call.Content">MediaDescription.DRAFT2</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
@@ -50,31 +50,31 @@
 
       <p>If nothing is known about the remote side's Media capabilities,
         (e.g. outgoing SIP/XMPP call, this <tp:dbus-ref namespace="ofdT.Call.Content"
-        >MediaDescription.DRAFT</tp:dbus-ref> will pop up with {<tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        >MediaDescription.DRAFT2</tp:dbus-ref> will pop up with {<tp:dbus-ref
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >HasRemoteInformation</tp:dbus-ref> = false, <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >FurtherNegotiationRequired</tp:dbus-ref> = true}, and the local
         user's streaming implementation SHOULD call 
-        <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
         >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.Call.Content.MediaDescription.DRAFT"
+          namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >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.Call.Content"
-         >MediaDescription.DRAFT</tp:dbus-ref> will appear, with {<tp:dbus-ref
-         namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+         >MediaDescription.DRAFT2</tp:dbus-ref> will appear, with {<tp:dbus-ref
+         namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
          >HasRemoteInformation</tp:dbus-ref> = true, <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >FurtherNegotiationRequired</tp:dbus-ref> = false},
         and the <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >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
@@ -84,9 +84,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.Call.Content.MediaDescription.DRAFT"
+        Note that if <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
         >Accept</tp:dbus-ref> is called, with <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >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
@@ -106,7 +106,7 @@
       </p>
       <p> If parameters requiring negotiation are changed, then the
         <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >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
@@ -114,7 +114,7 @@
 
       <p>If the other side decides to update his or her codec list
         during a call, a new <tp:dbus-ref
-        namespace="ofdT.Call.Content">MediaDescription.DRAFT</tp:dbus-ref>
+        namespace="ofdT.Call.Content">MediaDescription.DRAFT2</tp:dbus-ref>
         object will appear through
         <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> which should be
         acted on as documented above.</p>
@@ -122,12 +122,12 @@
       <h4>Protocols without negotiation</h4>
 
       <p>For protocols where the codecs are not negotiable, the initial content's <tp:dbus-ref
-        namespace="ofdT.Call.Content">MediaDescription.DRAFT</tp:dbus-ref>
+        namespace="ofdT.Call.Content">MediaDescription.DRAFT2</tp:dbus-ref>
         object will appear with <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >HasRemoteInformation</tp:dbus-ref>,
         set to true and the known supported codec values in <tp:dbus-ref
-        namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+        namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >Codecs</tp:dbus-ref>.
       </p>
     </tp:docstring>
@@ -160,7 +160,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.Call.Content.MediaDescription.DRAFT"
+              namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >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
@@ -201,10 +201,10 @@
       <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.Call.Content.MediaDescription.DRAFT"
+          <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
             >RemoteContact</tp:dbus-ref> property on
           <tp:dbus-ref namespace="ofdT.Call.Content"
-                    >MediaDescription.DRAFT</tp:dbus-ref>
+                    >MediaDescription.DRAFT2</tp:dbus-ref>
         </tp:docstring>
       </tp:member>
       <tp:member name="Media_Description_Properties" type="a{sv}"
@@ -222,7 +222,7 @@
       <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.Call.Content"
-          >MediaDescription.DRAFT</tp:dbus-ref>
+          >MediaDescription.DRAFT2</tp:dbus-ref>
         </tp:docstring>
       </tp:member>
       <tp:member name="Remote_Contact" type="u" tp:type="Contact_Handle">
@@ -294,8 +294,8 @@
           contact.</p>
 
         <p>Keys of this map will appear in at most one <tp:dbus-ref
-          namespace="ofdT.Call.Stream.DRAFT">RemoteMembers</tp:dbus-ref>.
-          See <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+          namespace="ofdT.Call.Stream.DRAFT2">RemoteMembers</tp:dbus-ref>.
+          See <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >RemoteContact</tp:dbus-ref> for more details on how to map between
           MediaDescriptions and Streams.</p>
       </tp:docstring>
@@ -314,11 +314,11 @@
         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.Call.Content"
-          >MediaDescription.DRAFT</tp:dbus-ref> appears. The streaming
+          >MediaDescription.DRAFT2</tp:dbus-ref> appears. The streaming
           >implementation MUST respond by calling the
-          <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+          <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >Accept</tp:dbus-ref> or <tp:dbus-ref
-          namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+          namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
           >Reject</tp:dbus-ref> method on the description object appeared.</p>
 
         <p>Emission of this signal indicates that the
@@ -364,7 +364,7 @@
         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.Call.Content"
-          >MediaDescription.DRAFT</tp:dbus-ref> has been handled. </p>
+          >MediaDescription.DRAFT2</tp:dbus-ref> has been handled. </p>
         <p>Emission of this signal indicates that the
           <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
           changed to
@@ -444,8 +444,8 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The object path to the current
           <tp:dbus-ref namespace="ofdT.Call.Content"
-           >MediaDescription.DRAFT</tp:dbus-ref> object, its
-            <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT"
+           >MediaDescription.DRAFT2</tp:dbus-ref> object, its
+            <tp:dbus-ref namespace="ofdT.Call.Content.MediaDescription.DRAFT2"
             >RemoteContact</tp:dbus-ref> and
             a mapping of the MediaDescriptions properties.
             If the object path is "/" then there isn't an outstanding
@@ -453,7 +453,7 @@
 
         <tp:rationale>
           Having all <tp:dbus-ref
-          namespace="ofdT.Call.Content">MediaDescription.DRAFT</tp:dbus-ref>
+          namespace="ofdT.Call.Content">MediaDescription.DRAFT2</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.