[telepathy-spec/master] Define Handler_Capability_Token in Handler rather than ContactCapabilities
Simon McVittie
simon.mcvittie at collabora.co.uk
Wed Aug 5 09:00:37 PDT 2009
These need to be "fast-tracked in" to all VoIP clients that are ported to
use MC 5, so they'll remain callable when MC and CMs migrate from
(Capabilities + ContactCapabilities.DRAFT1) to ContactCapabilities.DRAFT2.
---
spec/Client_Handler.xml | 91 ++++++++++++++++++++
spec/Connection_Interface_Contact_Capabilities.xml | 91 --------------------
2 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index 19231d5..06b490b 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -109,6 +109,97 @@
</tp:docstring>
</property>
+ <tp:simple-type name="Handler_Capability_Token" type="s"
+ array-name="Handler_Capability_Token_List">
+ <tp:docstring>
+ A <tp:type>DBus_Interface</tp:type>, followed by a slash '/' character
+ and an identifier for a capability defined by that interface. The
+ capability identifier SHOULD be in lower case. If an interface
+ references an external specification which is case-insensitive (such
+ as MIME), then names from that specification MUST be normalized to
+ lower-case before providing them to this Telepathy API, so that
+ implementations can safely rely on simple byte-by-byte comparison.
+
+ <tp:rationale>
+ These aren't D-Bus core Properties, and we want them to look visibly
+ different.
+ </tp:rationale>
+
+ <p>An initial set of client capabilities is defined here: when this
+ interface leaves draft status, these capabilities should be defined
+ by the MediaSignalling interface.</p>
+
+ <dl>
+
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/gtalk-p2p</dt>
+ <dd>
+ <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>
+ </dd>
+
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp</dt>
+ <dd>
+ <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>
+ </dd>
+
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/wlm-8.5</dt>
+ <dd>
+ <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>
+ </dd>
+
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/wlm-2009</dt>
+ <dd>
+ <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>
+ </dd>
+
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/<em>SUBTYPE</em></dt>
+ <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/<em>SUBTYPE</em></dt>
+ <dd>
+ <p>The client supports media streaming with the audio or video codec
+ whose MIME type is audio/<em>SUBTYPE</em> or
+ video/<em>SUBTYPE</em> (the subtype MUST appear in lower
+ case when used with this interface). Clients MAY support more
+ codecs than they explicitly advertise support for; clients SHOULD
+ explicitly advertise support for their preferred codec(s), and
+ for codecs 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>[FIXME: should we say the next paragraph, for completeness?]</p>
+
+ <p>Clients supporting video MUST advertise support for at least
+ one video codec, while clients supporting audio MUST advertise
+ support for at least one audio codec.</p>
+
+ <p>For example, a client could advertise support for
+ Speex, Theora and H264 by having three
+ Feature flags,
+ <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>.
+ .</p>
+ </dd>
+
+ </dl>
+ </tp:docstring>
+ </tp:simple-type>
+
<property name="Capabilities" tp:name-for-bindings="Capabilities"
type="as" tp:type="Handler_Capability_Token[]" access="read">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Connection_Interface_Contact_Capabilities.xml b/spec/Connection_Interface_Contact_Capabilities.xml
index 94eec98..a5c68b3 100644
--- a/spec/Connection_Interface_Contact_Capabilities.xml
+++ b/spec/Connection_Interface_Contact_Capabilities.xml
@@ -50,97 +50,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:rationale>
</tp:docstring>
- <tp:simple-type name="Handler_Capability_Token" type="s"
- array-name="Handler_Capability_Token_List">
- <tp:docstring>
- A <tp:type>DBus_Interface</tp:type>, followed by a slash '/' character
- and an identifier for a capability defined by that interface. The
- capability identifier SHOULD be in lower case. If an interface
- references an external specification which is case-insensitive (such
- as MIME), then names from that specification MUST be normalized to
- lower-case before providing them to this Telepathy API, so that
- implementations can safely rely on simple byte-by-byte comparison.
-
- <tp:rationale>
- These aren't D-Bus core Properties, and we want them to look visibly
- different.
- </tp:rationale>
-
- <p>An initial set of client capabilities is defined here: when this
- interface leaves draft status, these capabilities should be defined
- by the MediaSignalling interface.</p>
-
- <dl>
-
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/gtalk-p2p</dt>
- <dd>
- <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>
- </dd>
-
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp</dt>
- <dd>
- <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>
- </dd>
-
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/wlm-8.5</dt>
- <dd>
- <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>
- </dd>
-
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/wlm-2009</dt>
- <dd>
- <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>
- </dd>
-
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/<em>SUBTYPE</em></dt>
- <dt>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/<em>SUBTYPE</em></dt>
- <dd>
- <p>The client supports media streaming with the audio or video codec
- whose MIME type is audio/<em>SUBTYPE</em> or
- video/<em>SUBTYPE</em> (the subtype MUST appear in lower
- case when used with this interface). Clients MAY support more
- codecs than they explicitly advertise support for; clients SHOULD
- explicitly advertise support for their preferred codec(s), and
- for codecs 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>[FIXME: should we say the next paragraph, for completeness?]</p>
-
- <p>Clients supporting video MUST advertise support for at least
- one video codec, while clients supporting audio MUST advertise
- support for at least one audio codec.</p>
-
- <p>For example, a client could advertise support for
- Speex, Theora and H264 by having three
- Feature flags,
- <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>.
- .</p>
- </dd>
-
- </dl>
- </tp:docstring>
- </tp:simple-type>
-
<tp:struct name="Handler_Capabilities"
array-name="Handler_Capabilities_List">
<tp:docstring>
--
1.5.6.5
More information about the telepathy-commits
mailing list