[Telepathy-commits] [telepathy-python/master] Upgrade to spec 0.17.19
Guillaume Desmottes
guillaume.desmottes at collabora.co.uk
Tue Feb 17 02:50:15 PST 2009
---
spec/Channel_Interface_Group.xml | 143 +++++++++--
spec/Channel_Interface_Media_Signalling.xml | 46 +++-
spec/Channel_Interface_Media_Signalling_Future.xml | 189 ++++++++++++++
spec/Channel_Interface_Tube.xml | 6 +-
spec/Channel_Type_DBus_Tube.xml | 2 +-
spec/Channel_Type_File_Transfer.xml | 2 +-
spec/Channel_Type_Streamed_Media.xml | 12 +-
spec/Channel_Type_Streamed_Media_Future.xml | 166 +++++++++++++
spec/Connection.xml | 260 +++++++++++++++++---
spec/Connection_Interface_Contact_Info.xml | 2 +-
spec/Connection_Interface_Location.xml | 2 +-
spec/Connection_Interface_Requests.xml | 18 +-
spec/all.xml | 4 +-
spec/errors.xml | 223 +++++++++++++++++-
14 files changed, 996 insertions(+), 79 deletions(-)
create mode 100644 spec/Channel_Interface_Media_Signalling_Future.xml
create mode 100644 spec/Channel_Type_Streamed_Media_Future.xml
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group.xml
index 019e848..490258f 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group.xml
@@ -572,29 +572,81 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Offline" value="1">
- <tp:docstring>
- The change is due to a user going offline. Also used when
- user is already offline, but this wasn't known previously.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>
+
+ <tp:rationale>
+ For 1-1 calls, the call terminates as a result of removing the
+ remote contact, so the SelfHandle should be removed at the same
+ time as the remote contact and for the same reason.
+ </tp:rationale>
+
+ <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>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Kicked" value="2">
- <tp:docstring>
- The change is due to a kick operation.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The change is due to a kick operation.</p>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Busy" value="3">
- <tp:docstring>
- The change is due to a busy indication.
+ <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>
+
+ <tp:rationale>
+ For 1-1 calls, the call terminates as a result of removing the
+ remote contact, so the SelfHandle should be removed at the same
+ time as the remote contact and for the same reason.
+ </tp:rationale>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Invited" value="4">
<tp:docstring>
- The change is due to an invitation.
+ The change is due to an invitation. This reason SHOULD only be used
+ when contacts are added to the remote-pending set (to indicate that
+ the contact has been invited) or to the members (to indicate that
+ the contact has accepted the invitation).
+
+ <tp:rationale>
+ Otherwise, what would it mean?
+ </tp:rationale>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Banned" value="5">
- <tp:docstring>
- The change is due to a kick+ban operation.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The change is due to a kick+ban operation.</p>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Error" value="6">
@@ -603,18 +655,53 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Invalid_Contact" value="7">
- <tp:docstring>
- The change is because the requested contact does not exist.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The change is because the requested contact does not exist.</p>
+
+ <p>For instance, if the user invites a nonexistent contact to a
+ chatroom or attempts to call a nonexistent contact, this could
+ be indicated by the CM adding that contact's handle to
+ remote-pending for reason None or Invited, then removing it for
+ reason Invalid_Contact. In the case of a 1-1 StreamedMedia
+ call, the CM SHOULD remove the self handle from the Group
+ in the same signal.</p>
+
+ <tp:rationale>
+ For 1-1 calls, the call terminates as a result of removing the
+ remote contact, so the SelfHandle should be removed at the same
+ time as the remote contact and for the same reason.
+ </tp:rationale>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="No_Answer" value="8">
- <tp:docstring>
- The change is because the requested contact did not respond.
+ <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, 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.
+ </tp:rationale>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Renamed" value="9">
- <tp:docstring>
- The change is because a contact's unique identifier changed.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>
@@ -622,13 +709,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:dbus-ref
namespace="org.freedesktop.Telepathy.Connection.Interface">Renaming</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.
+ shortly before this <tp:member-ref>MembersChanged</tp:member-ref> signal is emitted.</p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Permission_Denied" value="10">
- <tp:docstring>
- The change is because there was no permission to contact the
- requested handle.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The change is because there was no permission to contact the
+ requested handle.</p>
+
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
<tp:enumvalue suffix="Separated" value="11">
@@ -657,6 +749,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
the group with reason Separated. Application protocols in Tubes
should be prepared to cope with this situation.
</p>
+
+ <p>The <tp:member-ref>SelfHandle</tp:member-ref> SHOULD NOT be
+ removed from channels with this reason.</p>
</tp:docstring>
</tp:enumvalue>
</tp:enum>
@@ -937,6 +1032,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
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
+ 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>
+
<p>Addition of members to the channel may be requested by using
<tp:member-ref>AddMembers</tp:member-ref>. If
remote acknowledgement is required, use of the AddMembers method will cause
diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml
index 05b618b..8249331 100644
--- a/spec/Channel_Interface_Media_Signalling.xml
+++ b/spec/Channel_Interface_Media_Signalling.xml
@@ -22,6 +22,41 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:requires interface="org.freedesktop.Telepathy.Channel"/>
<tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+ <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>
@@ -105,17 +140,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</tp:property>
- <tp:docstring>
- An interface for signalling a channel containing synchronised media
- sessions which can contain an arbitrary number of streams. The negotiation
- interface is based closely around the API of the Farsight library
- (http://farsight.sourceforge.net/). 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.
- </tp:docstring>
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Media_Signalling_Future.xml b/spec/Channel_Interface_Media_Signalling_Future.xml
new file mode 100644
index 0000000..e1d2d25
--- /dev/null
+++ b/spec/Channel_Interface_Media_Signalling_Future.xml
@@ -0,0 +1,189 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Media_Signalling_Future"
+ xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+ <tp:copyright> Copyright (C) 2009 Collabora Limited </tp:copyright>
+ <tp:copyright> Copyright (C) 2009 Nokia Corporation </tp:copyright>
+ <tp:license xmlns="http://www.w3.org/1999/xhtml">
+ <p>This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.</p>
+
+ <p>This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.</p>
+
+ <p>You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ USA.</p>
+ </tp:license>
+ <interface name="org.freedesktop.Telepathy.Channel.Interface.MediaSignalling.FUTURE">
+ <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.MediaSignalling"/>
+
+ <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.Interface.MediaSignalling</tp:dbus-ref>
+ interface in future. It should be considered to be conceptually part
+ of the core MediaSignalling interface, but without API or ABI
+ guarantees.</p>
+
+ <tp:rationale>
+ <p>The rationale is the same as for <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel.FUTURE</tp:dbus-ref>.</p>
+ </tp:rationale>
+ </tp:docstring>
+
+ <property name="ICETransportAvailable"
+ tp:name-for-bindings="ICE_Transport_Available"
+ type="b" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>True if this channel supports the use of the ICE-UDP transport
+ (<a href="http://xmpp.org/extensions/xep-0176.html">XEP-0176</a>,
+ <a href="http://tools.ietf.org/html/draft-ietf-mmusic-ice">ICE RFC
+ draft)</a>. Various other transports have boolean properties
+ that work in the same way as this one, so this description covers
+ all such transports.</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>
+
+ <p>Connection managers capable of signalling streamed media calls to
+ contacts SHOULD include the properties representing all supported
+ transports in the allowed properties list of the channel class
+ in <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+ that advertises support for streamed media channels.</p>
+
+ <p>Similarly, connection managers that support the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities.DRAFT</tp:dbus-ref>
+ interface SHOULD include all supported transports in the allowed
+ properties list of the channel class that advertises a contact's
+ ability to receive streamed media calls.</p>
+
+ <p>Clients that are able to receive calls with particular NAT
+ traversal mechanisms MAY include the following filters if
+ calling <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
+ (clients of a <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</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.DRAFT">HandlerChannelFilter</tp:dbus-ref>
+ properties):</p>
+
+ <ul>
+ <li>{ ChannelType = StreamedMedia, ICETransportAvailable = true }
+ if the ICE transport is supported</li>
+ <li>{ ChannelType = StreamedMedia, RawUDPTransportAvailable = true }
+ if the raw UDP transport is supported</li>
+ <li>... and so on, one filter per available transport.</li>
+ </ul>
+
+ <p>Connection managers MAY use this information to adjust the
+ transports for which they advertise support to other contacts.
+ If a client has indicated support for any particular transports,
+ the connection manager SHOULD advertise support for
+ each transport that is supported by any client, and also
+ supported by the CM itself.</p>
+
+ <tp:rationale>
+ <p>This minimizes the possibility that a call will be started that
+ cannot in fact succeed, because the intersection of the contacts'
+ available transports is empty.</p>
+ </tp:rationale>
+
+ <p>If no client has mentioned any of the transports known to the
+ connection manager in a call to SetSelfCapabilities, the connection
+ manager SHOULD advertise support for every transport that it can
+ signal.</p>
+
+ <tp:rationale>
+ <p>This simplifies implementation on integrated platforms like Maemo,
+ where it can be assumed that client libraries will support all the
+ "standard" transports known to any connection manager, and
+ lowers the "barrier to entry" for new Telepathy clients.</p>
+ </tp:rationale>
+
+ <p>Clients making outgoing calls for which the same client that made
+ the request will handle the streaming MAY indicate their ability or
+ inability to handle particular transports by including
+ <code>ICETransportAvailable = true</code>,
+ <code>RawUDPTransportAvailable = false</code>, etc.
+ in the request properties parameter of their call to <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
+ or similar functions. When they do so, the connection manager
+ SHOULD attempt to use a transport that the client has indicated
+ it is able to handle; if this is not possible, the connection
+ manager SHOULD raise an error instead of creating a channel.</p>
+
+ <tp:rationale>
+ <p>This enables such clients to restrict the CM to the subset of
+ transports supported by that particular client.</p>
+ </tp:rationale>
+
+ <p>Clients making outgoing calls for which they will not themselves
+ handle the streaming (e.g. an address book starting a call which
+ will be streamed by a separate call UI) SHOULD NOT include those
+ properties in the request.</p>
+
+ <tp:rationale>
+ <p>In general, such a client can't know the capabilities of the
+ streaming implementation, or even which streaming implementation
+ will be used.</p>
+ </tp:rationale>
+
+ <p>In the absence of any indication of supported transports from the
+ client, the connection manager SHOULD assume that the transports
+ indicated by calling SetSelfCapabilities are available. If
+ no transports were indicated as supported by calling
+ SetSelfCapabilities either, it SHOULD assume that any transport
+ that it can signal will be acceptable.</p>
+
+ <p>If this property, or any of the similar transport availability
+ properties, 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>
+ </tp:docstring>
+ </property>
+
+ <property name="RawUDPTransportAvailable"
+ tp:name-for-bindings="Raw_UDP_Transport_Available"
+ type="b" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
+ but for raw UDP streaming as described by <a
+ href="http://xmpp.org/extensions/xep-0177.html">XEP-0177</a>.</p>
+ </tp:docstring>
+ </property>
+
+ <property name="GoogleP2PTransportAvailable"
+ tp:name-for-bindings="Google_P2P_Transport_Available"
+ type="b" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
+ but for the variant of ICE used by the Google Talk peer-to-peer
+ connectivity establishment mechanism (as implemented in libjingle
+ 0.3).</p>
+ </tp:docstring>
+ </property>
+
+ <property name="MSNTransportAvailable"
+ tp:name-for-bindings="MSN_Transport_Available"
+ type="b" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
+ but for the variant of ICE used by MSN.</p>
+ </tp:docstring>
+ </property>
+
+ </interface>
+</node>
diff --git a/spec/Channel_Interface_Tube.xml b/spec/Channel_Interface_Tube.xml
index ff249eb..b2d0f31 100644
--- a/spec/Channel_Interface_Tube.xml
+++ b/spec/Channel_Interface_Tube.xml
@@ -68,10 +68,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
</tp:docstring>
</property>
- <property name="Status" type="u" tp:type="Tube_Channel_State" access="read"
- tp:name-for-bindings="Status">
+ <property name="State" type="u" tp:type="Tube_Channel_State" access="read"
+ tp:name-for-bindings="State">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>Status of the tube in this channel.</p>
+ <p>State of the tube in this channel.</p>
<p>When requesting a channel with
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
this property MUST NOT be included in the request.</p>
diff --git a/spec/Channel_Type_DBus_Tube.xml b/spec/Channel_Type_DBus_Tube.xml
index 34130c2..2671a17 100644
--- a/spec/Channel_Type_DBus_Tube.xml
+++ b/spec/Channel_Type_DBus_Tube.xml
@@ -128,7 +128,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
For a multi-user (i.e. Handle_Type_Room) D-Bus tube, a mapping
between contact handles and their unique bus names on this tube.
For a peer-to-peer (i.e. Handle_Type_Contact) D-Bus tube, the empty
- list. Change notification is via
+ dictionary. Change notification is via
<tp:member-ref>DBusNamesChanged</tp:member-ref>.
</tp:docstring>
</property>
diff --git a/spec/Channel_Type_File_Transfer.xml b/spec/Channel_Type_File_Transfer.xml
index f5268c8..c88834c 100644
--- a/spec/Channel_Type_File_Transfer.xml
+++ b/spec/Channel_Type_File_Transfer.xml
@@ -20,7 +20,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:license>
<interface name="org.freedesktop.Telepathy.Channel.Type.FileTransfer">
<tp:requires interface="org.freedesktop.Telepathy.Channel"/>
- <tp:added version="0.17.UNRELEASED">(as stable API)</tp:added>
+ <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
transmission of data between contacts is achieved by reading from
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
index 599fe16..b89065b 100644
--- a/spec/Channel_Type_Streamed_Media.xml
+++ b/spec/Channel_Type_Streamed_Media.xml
@@ -208,6 +208,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
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 have already been requested
+ via this method or <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">FUTURE.InitialAudio</tp:dbus-ref>/<tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">FUTURE.InitialVideo</tp:dbus-ref>,
+ this method SHOULD return successfully.</p>
</tp:docstring>
<tp:changed version="0.17.2">
<p>It is valid to use a handle which is neither
@@ -373,7 +379,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<p>In the past, several other patterns have been used to place outgoing
calls; see
- <tt>http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels</tt>
+ <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
for the details.</p>
<p>In general this should be used in conjunction with the <tp:dbus-ref
@@ -391,7 +397,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
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.
+ interface. See the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">FUTURE.InitialAudio</tp:dbus-ref>
+ property for details of the mechanisms that will replace this.
</tp:docstring>
<tp:flag suffix="Audio" value="1">
<tp:docstring>
diff --git a/spec/Channel_Type_Streamed_Media_Future.xml b/spec/Channel_Type_Streamed_Media_Future.xml
new file mode 100644
index 0000000..2421ed6
--- /dev/null
+++ b/spec/Channel_Type_Streamed_Media_Future.xml
@@ -0,0 +1,166 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Type_Streamed_Media_Future"
+ xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+ <tp:copyright> Copyright (C) 2009 Collabora Limited </tp:copyright>
+ <tp:copyright> Copyright (C) 2009 Nokia Corporation </tp:copyright>
+ <tp:license xmlns="http://www.w3.org/1999/xhtml">
+ <p>This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.</p>
+
+ <p>This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.</p>
+
+ <p>You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ USA.</p>
+ </tp:license>
+ <interface name="org.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTURE">
+ <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+
+ <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.Type.StreamedMedia</tp:dbus-ref>
+ interface in future. It should be considered to be conceptually part
+ of the core StreamedMedia interface, but without API or ABI
+ guarantees.</p>
+
+ <tp:rationale>
+ <p>The rationale is the same as for <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel.FUTURE</tp:dbus-ref>.</p>
+ </tp:rationale>
+ </tp:docstring>
+
+ <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.DRAFT</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 filters if calling <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
+ (clients of a <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</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.DRAFT">HandlerChannelFilter</tp:dbus-ref>
+ properties):</p>
+
+ <ul>
+ <li>{ ChannelType = StreamedMedia }</li>
+ <li>{ ChannelType = StreamedMedia, InitialAudio = true }
+ if receiving audio-only or audio+video calls is supported</li>
+ <li>{ ChannelType = StreamedMedia, InitialVideo = true }
+ if receiving video-only or audio+video calls 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>
+
+ <p>If { ChannelType = StreamedMedia } is passed to
+ SetSelfCapabilities, but no more specific channel class for
+ audio or video has been passed to that method (in the presence
+ of a ChannelDispatcher, this would mean that there is at least one
+ client with that channel class in its HandlerChannelFilter, but
+ no installed client has the more specific channel classes in its
+ HandlerChannelFilter), then the connection manager SHOULD advertise
+ support for every content type (audio or video) that it
+ supports.</p>
+
+ <tp:rationale>
+ <p>This lowers the "barrier to entry" by allowing a simple client
+ to say merely that it supports streamed media at all.</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>
+
+ </interface>
+</node>
diff --git a/spec/Connection.xml b/spec/Connection.xml
index bc46ecf..97a3c4c 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -492,6 +492,12 @@ USA.</p>
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"/>
@@ -633,83 +639,275 @@ USA.</p>
</tp:docstring>
</tp:enumvalue>
</tp:enum>
+
<tp:enum name="Connection_Status_Reason" type="u">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>A reason why the status of the connection changed. Apart from
+ Requested, the values of this enumeration only make sense as
+ reasons why the status changed to Disconnected.</p>
+ </tp:docstring>
+
<tp:enumvalue suffix="None_Specified" value="0">
- <tp:docstring>
- There is no reason set for this state change.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>There is no reason set for this state change. Unknown status
+ 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.Disconnected</code>.</p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Requested" value="1">
- <tp:docstring>
- The change is in response to a user request.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The change is in response to a user request. Changes to the
+ Connecting or Connected status SHOULD always indicate this reason;
+ changes to the Disconnected status SHOULD indicate this reason
+ 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>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Network_Error" value="2">
- <tp:docstring>
- There was an error sending or receiving on the network socket.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>There was an error sending or receiving on the network socket.</p>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.NetworkError</code>.</p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Authentication_Failed" value="3">
- <tp:docstring>
- The username or password was invalid.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Encryption_Error" value="4">
- <tp:docstring>
- There was an error negotiating SSL on this connection, or
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>There was an error negotiating SSL on this connection, or
encryption was unavailable and require-encryption was set when the
- connection was created.
+ connection was created.</p>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.EncryptionNotAvailable</code>
+ if encryption was not available at all, or
+ <code>org.freedesktop.Telepathy.Error.EncryptionError</code>
+ if encryption failed.</p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Name_In_Use" value="5">
- <tp:docstring>
- Someone is already connected to the server using the name
- you are trying to connect with.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>In general, this reason indicates that the requested account
+ name or other identification could not be used due to conflict
+ with another connection. It can be divided into three cases:</p>
+
+ <ul>
+ <li>If the status change is from Connecting to Disconnected
+ and the 'register' parameter to RequestConnection was present
+ and true, the requested account could not be created on the
+ server because it already exists.</li>
+
+ <li>If the status change is from Connecting to Disconnected
+ but the 'register' parameter is absent or false, the connection
+ manager could not connect to the specified account because
+ a connection to that account already exists.
+
+ <tp:rationale>
+ In some protocols, like XMPP (when connecting with the same
+ JID and resource as an existing connection), the existing
+ connection "wins" and the new one fails to connect.
+ </tp:rationale>
+ </li>
+
+ <li>If the status change is from Connected to Disconnected,
+ the existing connection was automatically disconnected because
+ a new connection to the same account (perhaps from a different
+ client or location) was established.
+
+ <tp:rationale>
+ In some protocols, like MSNP (when connecting twice with the
+ same Passport), the new connection "wins" and the
+ existing one is automatically disconnected.
+ </tp:rationale>
+ </li>
+ </ul>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.NotYours</code>.
+ </p>
+
+ <tp:rationale>
+ These three errors are distinct but very similar, and can be
+ distinguished by other factors.
+ </tp:rationale>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Not_Provided" value="6">
- <tp:docstring>
- The server did not provide a SSL certificate.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Untrusted" value="7">
- <tp:docstring>
- The server's SSL certificate could not be trusted.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The server's SSL certificate is signed by an untrusted certifying
+ authority. This error SHOULD NOT be used to represent a self-signed
+ certificate: use the more specific Cert_Self_Signed reason for
+ that.</p>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.Cert.Untrusted</code>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Expired" value="8">
- <tp:docstring>
- The server's SSL certificate has expired.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Not_Activated" value="9">
- <tp:docstring>
- The server's SSL certificate is not yet valid.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Hostname_Mismatch" value="10">
- <tp:docstring>
- The server's SSL certificate did not match its hostname.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Fingerprint_Mismatch" value="11">
- <tp:docstring>
- The server's SSL certificate does not have the expected
- fingerprint.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The server's SSL certificate does not have the expected
+ fingerprint.</p>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.Cert.FingerprintMismatch</code>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Self_Signed" value="12">
- <tp:docstring>
- The server's SSL certificate is self-signed.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <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.HostnameMismatch</code>.
+ </p>
</tp:docstring>
</tp:enumvalue>
+
<tp:enumvalue suffix="Cert_Other_Error" value="13">
- <tp:docstring>
- There was some other error validating the server's SSL certificate.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>There was some other error validating the server's SSL
+ certificate.</p>
+
+ <p>When disconnected for this reason, the equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.Cert.Invalid</code>.
+ </p>
</tp:docstring>
</tp:enumvalue>
</tp:enum>
+ <signal name="ConnectionError" tp:name-for-bindings="Connection_Error">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Emitted when an error occurs that renders this connection unusable.
+ </p>
+
+ <p>Whenever this signal is emitted, it MUST immediately be followed by
+ a <tp:member-ref>StatusChanged</tp:member-ref> signal with status
+ Connection_Status_Reason_Disconnected and an appropriate reason
+ code.</p>
+
+ <p>Connection managers SHOULD emit this signal on disconnection, but
+ need not do so. Clients MUST support connection managers that emit
+ StatusChanged(Disconnected, ...) without first emitting
+ ConnectionError.</p>
+
+ <tp:rationale>
+ <p>This signal provides additional information about the reason
+ for disconnection. The reason for connection is always
+ straightforward - it was requested - so it does not need further
+ explanation. However, on errors, it can be useful to provide
+ additional information.</p>
+
+ <p>The <tp:type>Connection_Status_Reason</tp:type> is not given
+ here, since it will be signalled in
+ <tp:member-ref>StatusChanged</tp:member-ref>. A reasonable client
+ implementation would be to store the information given by this
+ signal until StatusChanged is received, at which point the
+ information given by this signal can be used to supplement the
+ StatusChanged signal.</p>
+ </tp:rationale>
+ </tp:docstring>
+
+ <arg name="Error" type="s" tp:type="DBus_Error_Name">
+ <tp:docstring>
+ The name of a D-Bus error describing the error that occurred,
+ which may correspond to a
+ <tp:type>Connection_Status_Reason</tp:type> or be a
+ protocol-specific or connection-manager-specific error in a
+ suitable namespace.
+
+ <tp:rationale>
+ For instance, a SIP connection manager could signal
+ "402 Payment Required" as an error in a
+ connection-manager-specific namespace, or a link-local
+ XMPP implementation that used Avahi could provide the error
+ given to it by the avahi-daemon.
+ </tp:rationale>
+ </tp:docstring>
+ </arg>
+
+ <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Additional information about the error, which may include
+ the following well-known keys:</p>
+
+ <dl>
+ <dt>debug-message (s)</dt>
+ <dd>Debugging information on the change, corresponding to the
+ message part of a D-Bus error message, which SHOULD NOT be
+ displayed to users under normal circumstances</dd>
+ </dl>
+
+ <tp:rationale>
+ <p>This argument allows for future extensions. For instance,
+ if indicating DNS lookup failure, we could define a key
+ that indicates the hostname that could not be found.</p>
+ </tp:rationale>
+ </tp:docstring>
+ </arg>
+
+ </signal>
+
<signal name="StatusChanged" tp:name-for-bindings="Status_Changed">
<arg name="Status" type="u" tp:type="Connection_Status">
<tp:docstring>
diff --git a/spec/Connection_Interface_Contact_Info.xml b/spec/Connection_Interface_Contact_Info.xml
index c29f9fe..e7b033b 100644
--- a/spec/Connection_Interface_Contact_Info.xml
+++ b/spec/Connection_Interface_Contact_Info.xml
@@ -19,7 +19,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:license>
<interface name="org.freedesktop.Telepathy.Connection.Interface.ContactInfo.DRAFT"
tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED">(as a draft)</tp:added>
+ <tp:added version="0.17.18">(as a draft)</tp:added>
<tp:requires interface="org.freedesktop.Telepathy.Connection"/>
<tp:struct name="Contact_Info_Field" array-name="Contact_Info_Field_List">
diff --git a/spec/Connection_Interface_Location.xml b/spec/Connection_Interface_Location.xml
index dbd8d83..8821ec0 100644
--- a/spec/Connection_Interface_Location.xml
+++ b/spec/Connection_Interface_Location.xml
@@ -20,7 +20,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:license>
<interface name="org.freedesktop.Telepathy.Connection.Interface.Location.DRAFT"
tp:causes-havoc='experimental'>
- <tp:added version="0.17.UNRELEASED">(as a draft)</tp:added>
+ <tp:added version="0.17.18">(as a draft)</tp:added>
<tp:requires interface="org.freedesktop.Telepathy.Connection"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
index 203421b..3e47262 100644
--- a/spec/Connection_Interface_Requests.xml
+++ b/spec/Connection_Interface_Requests.xml
@@ -211,6 +211,12 @@
property provided was not a valid DNS name.
</tp:docstring>
</tp:error>
+ <tp:error name="org.freedesktop.Telepathy.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.NotAvailable">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The requested channel cannot be created, but in
@@ -218,8 +224,6 @@
For instance, this might be because:</p>
<ul>
- <li>the requested contact is using a client
- that lacks a particular feature</li>
<li>a channel matching the request already exists and the
protocol requires that only one such channel can exist at a
time</li>
@@ -346,12 +350,16 @@
property provided was not a valid DNS name.
</tp:docstring>
</tp:error>
+ <tp:error name="org.freedesktop.Telepathy.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.NotAvailable">
<tp:docstring>
The requested channel cannot be created, but in
- principle, a similar request might succeed in future. For instance,
- this might be because the requested contact is using a client
- that lacks a particular feature.
+ principle, a similar request might succeed in future.
</tp:docstring>
</tp:error>
<tp:error name="org.freedesktop.Telepathy.Error.Channel.Banned"/>
diff --git a/spec/all.xml b/spec/all.xml
index cee9b92..7745d54 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.17.18</tp:version>
+<tp:version>0.17.19</tp:version>
<tp:copyright>Copyright (C) 2005-2008 Collabora Limited</tp:copyright>
<tp:copyright>Copyright (C) 2005-2008 Nokia Corporation</tp:copyright>
@@ -45,6 +45,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<xi:include href="Channel_Future.xml"/>
<xi:include href="Channel_Type_Contact_List.xml"/>
<xi:include href="Channel_Type_Streamed_Media.xml"/>
+<xi:include href="Channel_Type_Streamed_Media_Future.xml"/>
<xi:include href="Channel_Type_Room_List.xml"/>
<xi:include href="Channel_Type_Text.xml"/>
<xi:include href="Channel_Type_Tubes.xml"/>
@@ -62,6 +63,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<xi:include href="Channel_Interface_HTML.xml"/>
<xi:include href="Channel_Interface_Password.xml"/>
<xi:include href="Channel_Interface_Media_Signalling.xml"/>
+<xi:include href="Channel_Interface_Media_Signalling_Future.xml"/>
<xi:include href="Channel_Interface_Messages.xml"/>
<xi:include href="Channel_Interface_Tube.xml"/>
diff --git a/spec/errors.xml b/spec/errors.xml
index 679e3f4..0a2d7d2 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -35,7 +35,17 @@
<tp:error name="Disconnected">
<tp:docstring>
- The connection is not currently connected and cannot be used.
+ 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>
+ has signalled status Disconnected for reason None.
+
+ <tp:rationale>
+ The second usage corresponds to None in the
+ <tp:type>Connection_Status_Reason</tp:type> enum; if a better reason
+ is available, the corresponding error should be used instead.
+ </tp:rationale>
</tp:docstring>
</tp:error>
@@ -73,7 +83,216 @@
<tp:error name="Cancelled">
<tp:docstring>
Raised by an ongoing request if it is cancelled by user request before
- it has completed.
+ it has completed, or when operations are performed on an object which
+ the user has asked to close (for instance, a Connection where the user
+ has called Disconnect, or a Channel where the user has called Close).
+
+ <tp:rationale>
+ The second form can be used to correspond to the Requested member in
+ the <tp:type>Connection_Status_Reason</tp:type> enum, or to
+ to represent the situation where disconnecting a Connection,
+ closing a Channel, etc. has been requested by the user but this
+ request has not yet been acted on, for instance because the
+ service will only act on the request when it has finished processing
+ an event queue.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Authentication Failed">
+ <tp:docstring>
+ Raised when authentication with a service was unsuccessful.
+ <tp:rationale>
+ This corresponds to Authentication_Failed in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Encryption Not Available">
+ <tp:docstring>
+ Raised if a user request insisted that encryption should be used,
+ but encryption was not actually available.
+
+ <tp:rationale>
+ This corresponds to part of Encryption_Error in the
+ <tp:type>Connection_Status_Reason</tp:type> enum. It's been separated
+ into a distinct error here because the two concepts that were part
+ of EncryptionError seem to be things that could reasonably appear
+ differently in the UI.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Encryption Error">
+ <tp:docstring>
+ Raised if encryption appears to be available, but could not actually be
+ used (for instance if SSL/TLS negotiation fails).
+ <tp:rationale>
+ This corresponds to part of Encryption_Error in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Not Provided">
+ <tp:docstring>
+ Raised if the server did not provide a SSL/TLS certificate. This error
+ MUST NOT be used to represent the absence of a client certificate
+ provided by the Telepathy connection manager.
+ <tp:rationale>
+ This corresponds to Cert_Not_Provided in the
+ <tp:type>Connection_Status_Reason</tp:type> enum. That error
+ explicitly applied only to server SSL certificates, so this one
+ is similarly limited; having the CM present a client certificate
+ is a possible future feature, but it should have its own error
+ handling.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Untrusted">
+ <tp:docstring>
+ Raised if the server provided a SSL/TLS certificate signed by an
+ untrusted certifying authority. This error SHOULD NOT be used to
+ represent a self-signed certificate: see the Self Signed error for that.
+ <tp:rationale>
+ This corresponds to Cert_Untrusted in the
+ <tp:type>Connection_Status_Reason</tp:type> enum, with a clarification
+ to avoid ambiguity.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Expired">
+ <tp:docstring>
+ Raised if the server provided an expired SSL/TLS certificate.
+ <tp:rationale>
+ This corresponds to Cert_Expired in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Not Activated">
+ <tp:docstring>
+ Raised if the server provided an SSL/TLS certificate that will become
+ valid at some point in the future.
+ <tp:rationale>
+ This corresponds to Cert_Not_Activated in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Fingerprint Mismatch">
+ <tp:docstring>
+ Raised if the server provided an SSL/TLS certificate that did not have
+ the expected fingerprint.
+ <tp:rationale>
+ This corresponds to Cert_Fingerprint_Mismatch in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Hostname Mismatch">
+ <tp:docstring>
+ Raised if the server provided an SSL/TLS certificate that did not match
+ its hostname.
+ <tp:rationale>
+ This corresponds to Cert_Hostname_Mismatch in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Self Signed">
+ <tp:docstring>
+ Raised if the server provided an SSL/TLS certificate that is self-signed
+ and untrusted.
+ <tp:rationale>
+ This corresponds to Cert_Hostname_Mismatch in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Cert.Invalid">
+ <tp:docstring>
+ Raised if the server provided an SSL/TLS certificate that is
+ unacceptable in some way that does not have a more specific error.
+ <tp:rationale>
+ This corresponds to Cert_Other_Error in the
+ <tp:type>Connection_Status_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Not Capable">
+ <tp:docstring>
+ Raised when requested functionality is unavailable due to contact
+ not having required capabilities.
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Offline">
+ <tp:docstring>
+ Raised when requested functionality is unavailable because a contact is
+ offline.
+
+ <tp:rationale>
+ This corresponds to Offline in the
+ <tp:type>Channel_Group_Change_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Channel.Kicked">
+ <tp:docstring>
+ Used to represent a user being ejected from a channel by another user,
+ for instance being kicked from a chatroom.
+
+ <tp:rationale>
+ This corresponds to Kicked in the
+ <tp:type>Channel_Group_Change_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Busy">
+ <tp:docstring>
+ Used to represent a user being removed from a channel because of a
+ "busy" indication.
+
+ <tp:rationale>
+ This corresponds to Busy in the
+ <tp:type>Channel_Group_Change_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="No Answer">
+ <tp:docstring>
+ Used to represent a user being removed from a channel because they did
+ not respond, e.g. to a StreamedMedia call.
+
+ <tp:rationale>
+ This corresponds to No_Answer in the
+ <tp:type>Channel_Group_Change_Reason</tp:type> enum.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:error>
+
+ <tp:error name="Does Not Exist">
+ <tp:docstring>
+ Raised when the requested user does not, in fact, exist.
+
+ <tp:rationale>
+ This corresponds to Invalid_Contact in the
+ <tp:type>Channel_Group_Change_Reason</tp:type> enum, but can also be
+ used to represent other things not existing (like chatrooms, perhaps).
+ </tp:rationale>
</tp:docstring>
</tp:error>
--
1.5.6.5
More information about the telepathy-commits
mailing list