[Telepathy-commits] [telepathy-glib/master] Update to spec 0.17.22
Simon McVittie
simon.mcvittie at collabora.co.uk
Tue Mar 24 12:17:22 PDT 2009
---
docs/reference/telepathy-glib-sections.txt | 13 ++-
spec/Channel_Dispatch_Operation.xml | 2 +-
...Channel_Dispatcher_Interface_Operation_List.xml | 2 +-
spec/Channel_Future.xml | 2 +-
spec/Channel_Interface_Call_State.xml | 17 ++-
spec/Channel_Interface_Group.xml | 2 +-
spec/Channel_Interface_Hold.xml | 4 +-
spec/Channel_Interface_Media_Signalling.xml | 54 ++++----
spec/Channel_Interface_Media_Signalling_Future.xml | 115 ++++++----------
spec/Channel_Interface_Messages.xml | 3 +-
spec/Channel_Interface_Tube.xml | 8 +-
spec/Channel_Type_Contact_Search.xml | 85 ++++++++----
spec/Channel_Type_Room_List.xml | 2 +-
spec/Channel_Type_Streamed_Media.xml | 137 ++++++++++++++++---
spec/Channel_Type_Streamed_Media_Future.xml | 19 +---
spec/Channel_Type_Text.xml | 7 +-
spec/Channel_Type_Tubes.xml | 55 +-------
spec/Client.xml | 6 +-
spec/Client_Approver.xml | 2 +-
spec/Client_Handler.xml | 7 +-
spec/Client_Observer.xml | 2 +-
spec/Connection.xml | 14 ++-
spec/Connection_Interface_Avatars.xml | 126 +++++++++++++++++-
spec/Connection_Interface_Contact_Info.xml | 3 +-
spec/Connection_Interface_Presence.xml | 2 +-
spec/Connection_Interface_Simple_Presence.xml | 3 +-
spec/Connection_Manager.xml | 2 +-
spec/Media_Stream_Handler.xml | 146 +++++++++++++++++++-
spec/Properties_Interface.xml | 2 +-
spec/all.xml | 2 +-
spec/generic-types.xml | 80 ++++++++++-
31 files changed, 662 insertions(+), 262 deletions(-)
diff --git a/docs/reference/telepathy-glib-sections.txt b/docs/reference/telepathy-glib-sections.txt
index eb694b4..75dddbe 100644
--- a/docs/reference/telepathy-glib-sections.txt
+++ b/docs/reference/telepathy-glib-sections.txt
@@ -1004,10 +1004,17 @@ tp_strv_contains
# Generic
tp_dbus_specialized_value_slice_new
TP_HASH_TYPE_STRING_STRING_MAP
+TP_ARRAY_TYPE_STRING_STRING_MAP_LIST
TP_HASH_TYPE_STRING_VARIANT_MAP
TP_ARRAY_TYPE_STRING_VARIANT_MAP_LIST
TP_HASH_TYPE_QUALIFIED_PROPERTY_VALUE_MAP
TP_ARRAY_TYPE_QUALIFIED_PROPERTY_VALUE_MAP_LIST
+TP_STRUCT_TYPE_SOCKET_ADDRESS_IP
+TP_ARRAY_TYPE_SOCKET_ADDRESS_IP_LIST
+TP_STRUCT_TYPE_SOCKET_ADDRESS_IPV4
+TP_STRUCT_TYPE_SOCKET_ADDRESS_IPV6
+TP_STRUCT_TYPE_SOCKET_NETMASK_IPV4
+TP_STRUCT_TYPE_SOCKET_NETMASK_IPV6
<SUBSECTION>
# Connection Manager
TP_STRUCT_TYPE_PARAM_SPEC
@@ -1073,10 +1080,6 @@ TP_ARRAY_TYPE_MESSAGE_PART_LIST
TP_HASH_TYPE_MESSAGE_PART_CONTENT_MAP
<SUBSECTION>
# Channel - Tubes
-TP_STRUCT_TYPE_SOCKET_ADDRESS_IPV4
-TP_STRUCT_TYPE_SOCKET_ADDRESS_IPV6
-TP_STRUCT_TYPE_SOCKET_NETMASK_IPV4
-TP_STRUCT_TYPE_SOCKET_NETMASK_IPV6
TP_HASH_TYPE_SUPPORTED_SOCKET_MAP
TP_STRUCT_TYPE_TUBE_INFO
TP_ARRAY_TYPE_TUBE_INFO_LIST
@@ -1111,9 +1114,11 @@ TP_STRUCT_TYPE_ROOM_INFO
tp_type_dbus_array_a_7bsv_7das
tp_type_dbus_array_oa_7bsv_7d
tp_type_dbus_array_of_a_7bsv_7d
+tp_type_dbus_array_of_a_7bss_7d
tp_type_dbus_array_os
tp_type_dbus_array_osuu
tp_type_dbus_array_sa_28usuussduss_29
+tp_type_dbus_array_sq
tp_type_dbus_array_su
tp_type_dbus_array_susv
tp_type_dbus_array_us
diff --git a/spec/Channel_Dispatch_Operation.xml b/spec/Channel_Dispatch_Operation.xml
index 6f728c3..fdee944 100644
--- a/spec/Channel_Dispatch_Operation.xml
+++ b/spec/Channel_Dispatch_Operation.xml
@@ -191,7 +191,7 @@
The well known bus names (starting with
<code>org.freedesktop.Telepathy.Client.</code>) of the possible
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
+ namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>s
for these channels. The channel dispatcher MUST place the most
preferred handlers first, according to some reasonable heuristic.
As a result, approvers SHOULD use the first handler by default.
diff --git a/spec/Channel_Dispatcher_Interface_Operation_List.xml b/spec/Channel_Dispatcher_Interface_Operation_List.xml
index b59ef72..7a1c0e1 100644
--- a/spec/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/spec/Channel_Dispatcher_Interface_Operation_List.xml
@@ -51,7 +51,7 @@
<tp:docstring>
The object path of the
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>.
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>.
</tp:docstring>
</tp:member>
diff --git a/spec/Channel_Future.xml b/spec/Channel_Future.xml
index 823d8a0..5bbca17 100644
--- a/spec/Channel_Future.xml
+++ b/spec/Channel_Future.xml
@@ -50,7 +50,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
pseudo-interface)</tp:added>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle.DRAFT</tp:dbus-ref>
to which this channel belongs.</p>
<p>A channel's Bundle property can never change.</p>
diff --git a/spec/Channel_Interface_Call_State.xml b/spec/Channel_Interface_Call_State.xml
index 0df6e34..eec6a4b 100644
--- a/spec/Channel_Interface_Call_State.xml
+++ b/spec/Channel_Interface_Call_State.xml
@@ -20,12 +20,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<interface name="org.freedesktop.Telepathy.Channel.Interface.CallState">
<tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
- <tp:docstring>
- An interface for streamed media channels that can indicate call
- progress or call states. The presence of this interface is no guarantee
- that call states will actually be signalled (for instance, SIP
- implementations are not guaranteed to generate status 180 Ringing,
- so a call can be accepted without the Ringing flag ever having been set).
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>An interface for streamed media channels that can indicate call
+ progress or call states. The presence of this interface is no guarantee
+ that call states will actually be signalled (for instance, SIP
+ implementations are not guaranteed to generate status 180 Ringing, so a
+ call can be accepted without the Ringing flag ever having been set).</p>
+
+ <p>To notify the other participant in the call that they are on hold,
+ see <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Interface"
+ >Hold</tp:dbus-ref>.</p>
</tp:docstring>
<tp:added version="0.17.2"/>
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group.xml
index 9c7e254..db17a0b 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group.xml
@@ -242,7 +242,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</tp:flag>
<tp:flag suffix="Message_Depart" value="8192">
- <tp:added version="0.17.UNRELEASED"/>
+ <tp:added version="0.17.21"/>
<tp:docstring>
A message may be sent to the server when calling
<tp:member-ref>RemoveMembers</tp:member-ref> on
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold.xml
index 835aff9..1e3a832 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold.xml
@@ -26,7 +26,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Interface for channels where you may put the channel on hold.
This only makes sense for channels where
- you are streaming media to or from the members.</p>
+ 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>
<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
diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml
index b69e5b3..5c29316 100644
--- a/spec/Channel_Interface_Media_Signalling.xml
+++ b/spec/Channel_Interface_Media_Signalling.xml
@@ -103,43 +103,49 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
within.
</tp:docstring>
</signal>
- <tp:property name="nat-traversal" type="s">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>A string indicating the NAT traversal techniques employed by the
- streams within this channel. Can be protocol-specific values, but the
- following values should be used if appropriate:</p>
-
- <dl>
- <dt>none</dt>
- <dd>No attempt should be made at NAT traversal.</dd>
-
- <dt>stun</dt>
- <dd>If appropriate, a STUN request should be made to the given server
- to open a UDP port mapping and determine the external IP.</dd>
- <dt>gtalk-p2p</dt>
- <dd>Google Talk peer-to-peer connectivity establishment should be used,
- as implemented in libjingle 0.3.</dd>
-
- <dt>ice-udp</dt>
- <dd>
- Interactive Connectivity Establishment should be used, as defined by
- the IETF MMUSIC working group.
- </dd>
- </dl>
+ <tp:property name="nat-traversal" type="s">
+ <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
+ property on the Media.StreamHandler, if available; use this
+ as a fallback.</tp:deprecated>
+ <tp:docstring>
+ A string indicating the NAT traversal techniques employed by the
+ streams within this channel if they do not have a <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
+ property. The possible values are the same as for the NATTraversal
+ property on the streams.
</tp:docstring>
</tp:property>
+
<tp:property name="stun-server" type="s">
+ <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
+ property on the Media.StreamHandler, if available; use this
+ as a fallback.</tp:deprecated>
<tp:docstring>
- The IP address or hostname of the STUN server to use for NAT traversal.
+ The IP address or hostname of the STUN server to use for NAT traversal
+ if the individual streams do not specify one.
</tp:docstring>
</tp:property>
+
<tp:property name="stun-port" type="q">
+ <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
+ property on the Media.StreamHandler, if available; use this
+ as a fallback.</tp:deprecated>
<tp:docstring>
The UDP port number to use on the provided STUN server.
</tp:docstring>
</tp:property>
+
<tp:property name="gtalk-p2p-relay-token" type="s">
+ <tp:deprecated version="0.17.22">XMPP connection managers
+ supporting the Google Talk relay server SHOULD make the necessary
+ HTTP requests to find a username and password, and use those
+ to populate the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Media.StreamHandler">RelayInfo</tp:dbus-ref>
+ property on the Media.StreamHandler.</tp:deprecated>
<tp:docstring>
The authentication token for use with the Google Talk peer-to-peer relay
server.
diff --git a/spec/Channel_Interface_Media_Signalling_Future.xml b/spec/Channel_Interface_Media_Signalling_Future.xml
index d908450..102f206 100644
--- a/spec/Channel_Interface_Media_Signalling_Future.xml
+++ b/spec/Channel_Interface_Media_Signalling_Future.xml
@@ -67,9 +67,31 @@
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
+ <p>Clients SHOULD NOT pass ICETransportAvailable and similar
+ properties to <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
+ or similar functions. If they do, the connection manager MUST
+ accept and ignore any such property that is in the allowed properties
+ list.</p>
+
+ <tp:rationale>
+ <p>There is currently no way for clients to influence the choice
+ of transport: in general, a client making a call can't know the
+ capabilities of the streaming implementation, or even which
+ streaming implementation will be used (channels will often be
+ requested by an address book or similar application that will not
+ handle the channel itself).</p>
+
+ <p>If a mechanism for transport negotiation is added, it should be
+ something that happens after the request, but before calling
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Media.SessionHandler.Ready</tp:dbus-ref>,
+ so that it is the streaming implementation that chooses the
+ transport, rather than the requesting client.</p>
+ </tp:rationale>
+
+ <p>Clients that are able to receive calls with particular transports
+ MUST 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>
@@ -87,71 +109,13 @@
</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>
+ transports for which they advertise support to other contacts.</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>
+ <p>In particular, in XMPP, the connection manager will not be
+ callable unless a client has told it to advertise support for
+ at least one transport.</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>
@@ -165,8 +129,8 @@
</tp:docstring>
</property>
- <property name="GoogleP2PTransportAvailable"
- tp:name-for-bindings="Google_P2P_Transport_Available"
+ <property name="GTalkP2PTransportAvailable"
+ tp:name-for-bindings="GTalk_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>,
@@ -176,12 +140,23 @@
</tp:docstring>
</property>
- <property name="MSNTransportAvailable"
- tp:name-for-bindings="MSN_Transport_Available"
+ <property name="WLM85TransportAvailable"
+ tp:name-for-bindings="WLM_8_5_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 transport implemented by Windows Live Messenger 8.5 or
+ later (which resembles ICE draft 6).</p>
+ </tp:docstring>
+ </property>
+
+ <property name="WLM2009TransportAvailable"
+ tp:name-for-bindings="WLM_2009_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>
+ but for the transport implemented by Windows Live Messenger 2009
+ or later (which resembles ICE draft 19).</p>
</tp:docstring>
</property>
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index c012f2f..c668067 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -706,7 +706,8 @@ USA.</p>
</tp:member>
</tp:mapping>
- <tp:simple-type type="u" name="Message_Part_Index">
+ <tp:simple-type type="u" name="Message_Part_Index"
+ array-name="Message_Part_Index_List">
<tp:added version="0.17.17"/>
<tp:docstring>
The index of a message part within a message.
diff --git a/spec/Channel_Interface_Tube.xml b/spec/Channel_Interface_Tube.xml
index 8e6eb65..5d1eda7 100644
--- a/spec/Channel_Interface_Tube.xml
+++ b/spec/Channel_Interface_Tube.xml
@@ -26,9 +26,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
systems to communicate without having to establish network
connections themselves. Currently, two types of tube exist:
<tp:dbus-ref namespace="org.freedesktop.Telepathy"
- >Channel.Type.DBusTube</tp:dbus-ref> and
+ >Channel.Type.DBusTube.DRAFT</tp:dbus-ref> and
<tp:dbus-ref namespace="org.freedesktop.Telepathy"
- >Channel.Type.StreamTube</tp:dbus-ref>. This interface contains
+ >Channel.Type.StreamTube.DRAFT</tp:dbus-ref>. This interface contains
the properties, signals and methods common to both types of tube;
you can only create channels of a specific tube type, not of this
type. A tube channel contains exactly one tube; if you need several
@@ -42,8 +42,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
<p>As an exception to the usual handling of capabilities, connection managers
for protocols with capability discovery, such as XMPP, SHOULD advertise the
capability representing each Tube type that they support
- (<tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.DBusTube</tp:dbus-ref> and/or
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.StreamTube</tp:dbus-ref>)
+ (<tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.DBusTube.DRAFT</tp:dbus-ref> and/or
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Type.StreamTube.DRAFT</tp:dbus-ref>)
even if no client has indicated via
<tp:dbus-ref
namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
diff --git a/spec/Channel_Type_Contact_Search.xml b/spec/Channel_Type_Contact_Search.xml
index 204ecf1..b0e905f 100644
--- a/spec/Channel_Type_Contact_Search.xml
+++ b/spec/Channel_Type_Contact_Search.xml
@@ -43,6 +43,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
running search can be cancelled by calling
<tp:member-ref>Stop</tp:member-ref>.</p>
+ <p>If the protocol supports limiting the number of results returned by a
+ search and subsequently requesting more results, after
+ <tp:member-ref>Limit</tp:member-ref> results have been received the
+ search state will be set to <code>More_Available</code>. Clients may
+ call <tp:member-ref>More</tp:member-ref> to request another
+ <tp:member-ref>Limit</tp:member-ref> results. If allowed by the
+ connection manager, clients may specify the "page size" by specifying
+ <tp:member-ref>Limit</tp:member-ref> when calling
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
+ </p>
+
<p>The client should call the channel's <tp:dbus-ref
namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
method when it is finished with the channel, so that any handles held
@@ -73,10 +84,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:enumvalue suffix="In_Progress" value="1">
<tp:docstring>The search is in progress</tp:docstring>
</tp:enumvalue>
- <tp:enumvalue suffix="Completed" value="2">
+ <tp:enumvalue suffix="More_Available" value="2">
+ <tp:docstring>The search has paused, but more results can be retrieved
+ by calling <tp:member-ref>More</tp:member-ref>.</tp:docstring>
+ </tp:enumvalue>
+ <tp:enumvalue suffix="Completed" value="3">
<tp:docstring>The search has been completed</tp:docstring>
</tp:enumvalue>
- <tp:enumvalue suffix="Failed" value="3">
+ <tp:enumvalue suffix="Failed" value="4">
<tp:docstring>The search has failed</tp:docstring>
</tp:enumvalue>
</tp:enum>
@@ -127,6 +142,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<ul>
<li><code>Not_Started</code> → <code>In_Progress</code></li>
+ <li><code>In_Progress</code> → <code>More_Available</code></li>
+ <li><code>More_Available</code> → <code>In_Progress</code></li>
<li><code>In_Progress</code> → <code>Completed</code></li>
<li><code>In_Progress</code> → <code>Failed</code></li>
</ul>
@@ -215,35 +232,33 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
Gadu-Gadu and TOC appear to support this.
</tp:rationale>
</dd>
-
- <dt><code>x-search-offset</code></dt>
- <dd>
- <p>For protocols that support paging results, the offset from the
- start of the results that should be returned, i.e. the number of
- contacts from the beginning that should be omitted.</p>
-
- <p>For example, if the search terms match 50 contacts, this key
- is set to <code>"20"</code> and <code>x-search-limit</code>
- is set to <code>"10"</code>, then the ten contacts from the 21st
- to the 30th should be returned.</p>
-
- <p>Connection managers for protocols which do not natively support
- restricting the number of results returned MUST NOT support
- either this term or <code>x-search-limit</code>: all results
- should be signalled, and the client can provide its own paging as
- desired.</p>
- </dd>
-
- <dt><code>x-search-limit</code></dt>
- <dd>For protocols that support limiting results, the maximum number
- of results that should be returned. For example, if the search
- terms match <i>Antonius</i>, <i>Bridget</i> and <i>Charles</i> and
- this key is set to <code>"2"</code>, the search service SHOULD only
- return <i>Antonius</i> and <i>Bridget</i>.</dd>
</dl>
</tp:docstring>
</tp:simple-type>
+ <property name="Limit" type="u" access="read"
+ tp:name-for-bindings="Limit">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>If supported by the protocol, the maximum number of results that
+ should be returned, where <code>0</code> represents no limit. If the
+ protocol does not support limiting results, this should be
+ <code>0</code>.</p>
+
+ <p>For example, if the terms passed to
+ <tp:member-ref>Search</tp:member-ref> match <i>Antonius</i>,
+ <i>Bridget</i> and <i>Charles</i> and this property is
+ <code>2</code>, the search service SHOULD only return <i>Antonius</i>
+ and <i>Bridget</i>.</p>
+
+ <p>This property cannot change during the lifetime of the channel.
+ This property SHOULD be in the Allowed_Properties of a
+ <tp:type>Requestable_Channel_Class</tp:type> if and only if the
+ protocol supports specifying a limit; implementations SHOULD use
+ <code>0</code> as the default if possible, or a protocol-specific
+ sensible default otherwise.</p>
+ </tp:docstring>
+ </property>
+
<property name="AvailableSearchKeys" type="as" access="read"
tp:name-for-bindings="Available_Search_Keys">
<tp:docstring>
@@ -310,6 +325,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:possible-errors>
</method>
+ <method name="More" tp:name-for-bindings="More">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ Request that a search in <tp:member-ref>SearchState</tp:member-ref>
+ <code>More_Available</code> move back to state <code>In_Progress</code>
+ and continue listing up to <tp:member-ref>Limit</tp:member-ref> more results.
+ </tp:docstring>
+ <tp:possible-errors>
+ <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+ <tp:docstring>
+ The <tp:member-ref>SearchState</tp:member-ref> is not
+ <code>More_Available</code>.
+ </tp:docstring>
+ </tp:error>
+ </tp:possible-errors>
+ </method>
+
<method name="Stop" tp:name-for-bindings="Stop">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Stop the current search. This may not be called while the
diff --git a/spec/Channel_Type_Room_List.xml b/spec/Channel_Type_Room_List.xml
index 4170fce..93ea777 100644
--- a/spec/Channel_Type_Room_List.xml
+++ b/spec/Channel_Type_Room_List.xml
@@ -87,7 +87,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<dd>The current subject of conversation in the room</dd>
<dt>members (u)</dt>
- <dd>The number of members of the room</dd>
+ <dd>The number of members in the room</dd>
<dt>password (b)</dt>
<dd>True if the room requires a password to enter</dd>
diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml
index 701c8a5..c4ddea7 100644
--- a/spec/Channel_Type_Streamed_Media.xml
+++ b/spec/Channel_Type_Streamed_Media.xml
@@ -22,7 +22,8 @@ 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.Interface.Group"/>
- <tp:enum name="Media_Stream_Type" type="u">
+ <tp:enum name="Media_Stream_Type" type="u"
+ array-name="Media_Stream_Type_List">
<tp:enumvalue suffix="Audio" value="0">
<tp:docstring>An audio stream</tp:docstring>
</tp:enumvalue>
@@ -86,7 +87,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
name="Pending_Send_Flags"/>
</tp:struct>
- <tp:simple-type name="Stream_ID" type="u"/>
+ <tp:simple-type name="Stream_ID" type="u"
+ array-name="Stream_ID_List">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>An unsigned integer identifying a stream within a channel.</p>
+ </tp:docstring>
+ </tp:simple-type>
<method name="ListStreams" tp:name-for-bindings="List_Streams">
<arg direction="out" type="a(uuuuuu)" tp:type="Media_Stream_Info[]"
@@ -118,9 +124,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:member-ref>ListStreams</tp:member-ref>)
</tp:docstring>
</arg>
- <tp:docstring>
- Request that the given streams are removed.
+
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Request that the given streams are removed. If all streams are
+ removed, the channel MAY close.</p>
+
+ <p>Clients SHOULD NOT attempt to terminate calls by removing all the
+ streams; instead, clients SHOULD terminate calls by removing the
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref>
+ from the channel, using either
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembers</tp:dbus-ref>
+ or
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>.
+ </p>
</tp:docstring>
+
<tp:possible-errors>
<tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
A stream identifier is unknown
@@ -209,11 +230,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
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>
+ <p>If streams of the requested types already exist, calling this
+ method results in the creation of additional streams. Accordingly,
+ clients wishing to have exactly one audio stream or exactly one
+ video stream SHOULD check for the current streams using
+ <tp:member-ref>ListStreams</tp:member-ref> before calling this
+ method.</p>
</tp:docstring>
<tp:changed version="0.17.2">
<p>It is valid to use a handle which is neither
@@ -257,8 +279,54 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
The stream type (a value from MediaStreamType)
</tp:docstring>
</arg>
- <tp:docstring>
- Emitted when a new stream has been added to this channel.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Emitted when a new stream has been added to this channel.
+ Clients SHOULD assume that the stream's
+ <tp:type>Media_Stream_State</tp:type> is initially Disconnected.</p>
+
+ <p>If a connection manager needs to represent the addition of a stream
+ whose state is already Connecting or Connected, it MUST do this
+ by emitting StreamAdded, closely followed by
+ <tp:member-ref>StreamStateChanged</tp:member-ref> indicating a
+ change to the appropriate state.</p>
+
+ <tp:rationale>
+ <p>Historically, it was not clear from the StreamAdded signal what
+ the state of the stream was. telepathy-spec 0.17.22
+ clarified this.</p>
+ </tp:rationale>
+
+ <p>Similarly, clients SHOULD assume that the initial
+ <tp:type>Media_Stream_Direction</tp:type> of a newly added stream
+ is Receive, and that the initial
+ <tp:type>Media_Stream_Pending_Send</tp:type> is
+ Pending_Local_Send.</p>
+
+ <p>If a connection manager needs to represent the addition of a stream
+ whose direction or pending-send differs from those initial values,
+ it MUST do so by emitting StreamAdded, closely followed by
+ <tp:member-ref>StreamDirectionChanged</tp:member-ref> indicating a
+ change to the appropriate direction and pending-send state.</p>
+
+ <tp:rationale>
+ <p>StreamAdded doesn't itself indicate the stream's direction; this
+ is unfortunate, but is preserved for compatibility.</p>
+
+ <p>This is the appropriate direction for streams added by a remote
+ contact on existing connection managers, and does not violate
+ user privacy by automatically sending audio or video (audio streams
+ start off muted, video streams start off not sending). For
+ streams added by the local user using the client receiving the
+ signal, the true direction can also be determined from the return
+ value of the <tp:member-ref>RequestStreams</tp:member-ref>
+ method.</p>
+
+ <p>Existing clients typically operate by maintaining a separate
+ idea of the directions that they would like the streams to have,
+ and enforcing these intended directions by calling
+ <tp:member-ref>RequestStreamDirection</tp:member-ref> whenever
+ needed.</p>
+ </tp:rationale>
</tp:docstring>
</signal>
@@ -279,12 +347,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
The new pending send flags (as defined in ListStreams)
</tp:docstring>
</arg>
- <tp:docstring>
- Emitted when the direction or pending flags of a stream are changed. If
- the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user has
- requested that we begin sending on this stream.
- <tp:member-ref>RequestStreamDirection</tp:member-ref>
- should be called to indicate whether or not this change is acceptable.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Emitted when the direction or pending flags of a stream are
+ changed.</p>
+
+ <p>If the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user
+ has requested that we begin sending on this stream.
+ <tp:member-ref>RequestStreamDirection</tp:member-ref>
+ should be called to indicate whether or not this change is
+ acceptable.</p>
+
+ <tp:rationale>
+ <p>This allows for a MSN-style user interface, "Fred has asked you
+ to enable your webcam. (Accept | Reject)", if desired.</p>
+ </tp:rationale>
</tp:docstring>
</signal>
@@ -367,6 +443,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
which point the contact should appear in the channel's <tp:dbus-ref
namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemotePendingMembers</tp:dbus-ref>).</p>
+ <p>In the past, several other patterns have been used to place outgoing
+ calls; see
+ <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
+ for the details.</p>
+
<p>Incoming calls should be signalled as <tp:dbus-ref
namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
= Contact, <tp:dbus-ref
@@ -377,10 +458,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
namespace="org.freedesktop.Telepathy.Channel.Interface.Group">AddMembers</tp:dbus-ref>
can be used to move the local user to the group's members.</p>
- <p>In the past, several other patterns have been used to place outgoing
- calls; see
- <a href="http://telepathy.freedesktop.org/wiki/Requesting%20StreamedMedia%20channels">'Requesting StreamedMedia Channels' on the Telepathy wiki</a>
- for the details.</p>
+ <p>When the local user accepts an incoming call, the connection manager
+ SHOULD change the direction of any streams with pending local send
+ to be sending, without altering whether those streams are
+ receiving.</p>
+
+ <tp:rationale>
+ <p>This matches existing practice, and means that a client
+ can answer incoming calls and get an unmuted microphone/activated
+ webcam without having to take additional action to accept the
+ stream directions.</p>
+
+ <p>It does, however, introduce a race condition: a client believing
+ that it is accepting an audio-only call by calling AddMembers
+ can inadvertantly accept an audio + video call (and hence activate
+ sending from a webcam without the user's permission) if a video
+ stream is added just before AddMembers is processed. This race
+ should be removed when this specification is revised.</p>
+ </tp:rationale>
<p>In general this should be used in conjunction with the <tp:dbus-ref
namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref>
diff --git a/spec/Channel_Type_Streamed_Media_Future.xml b/spec/Channel_Type_Streamed_Media_Future.xml
index fa8a015..5b75c5f 100644
--- a/spec/Channel_Type_Streamed_Media_Future.xml
+++ b/spec/Channel_Type_Streamed_Media_Future.xml
@@ -118,9 +118,9 @@
<ul>
<li>{ ChannelType = StreamedMedia }</li>
<li>{ ChannelType = StreamedMedia, InitialAudio = true }
- if receiving audio-only or audio+video calls is supported</li>
+ if receiving calls with audio is supported</li>
<li>{ ChannelType = StreamedMedia, InitialVideo = true }
- if receiving video-only or audio+video calls is supported</li>
+ if receiving calls with video is supported</li>
</ul>
<tp:rationale>
@@ -128,21 +128,6 @@
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>
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index f5828a4..7d6e314 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -21,7 +21,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<interface name="org.freedesktop.Telepathy.Channel.Type.Text">
<tp:requires interface="org.freedesktop.Telepathy.Channel"/>
- <tp:simple-type name="Message_ID" type="u">
+ <tp:simple-type name="Message_ID" type="u" array-name="Message_ID_List">
<tp:docstring>
A unique-per-channel identifier for an incoming message. These
SHOULD be allocated in a way that minimizes collisions (in particular,
@@ -87,7 +87,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:member-ref>AcknowledgePendingMessages</tp:member-ref> had also
been called.
</tp:docstring>
- <tp:deprecated since="0.17.3">
+ <tp:deprecated version="0.17.3">
Setting this to true is NOT RECOMMENDED for clients that
have some sort of persistent message storage - clients SHOULD only
acknowledge messages after they have actually stored them, which is
@@ -290,7 +290,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</signal>
- <tp:enum name="Channel_Text_Message_Type" type="u">
+ <tp:enum name="Channel_Text_Message_Type" type="u"
+ array-name="Channel_Text_Message_Type_List">
<tp:docstring>
The type of message.
</tp:docstring>
diff --git a/spec/Channel_Type_Tubes.xml b/spec/Channel_Type_Tubes.xml
index 925ae1b..2cc0131 100644
--- a/spec/Channel_Type_Tubes.xml
+++ b/spec/Channel_Type_Tubes.xml
@@ -71,57 +71,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
</tp:member>
</tp:struct>
- <tp:struct name="Socket_Address_IPv4">
- <tp:docstring>An IPv4 address and port.</tp:docstring>
- <tp:member type="s" name="Address">
- <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
- numbers, each between 0 and 255 inclusive, e.g.
- "192.168.0.1".</tp:docstring>
- </tp:member>
- <tp:member type="q" name="Port">
- <tp:docstring>The TCP or UDP port number.</tp:docstring>
- </tp:member>
- </tp:struct>
-
- <tp:struct name="Socket_Address_IPv6">
- <tp:docstring>An IPv6 address and port.</tp:docstring>
- <tp:member type="s" name="Address">
- <tp:docstring>An IPv6 address literal as specified by RFC2373
- section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
- </tp:member>
- <tp:member type="q" name="Port">
- <tp:docstring>The TCP or UDP port number.</tp:docstring>
- </tp:member>
- </tp:struct>
-
- <tp:struct name="Socket_Netmask_IPv4">
- <tp:docstring>An IPv4 network or subnet.</tp:docstring>
- <tp:member type="s" name="Address">
- <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
- numbers, each between 0 and 255 inclusive, e.g.
- "192.168.0.1".</tp:docstring>
- </tp:member>
- <tp:member type="y" name="Prefix_Length">
- <tp:docstring>The number of leading bits of the address that must
- match, for this netmask to be considered to match an
- address.</tp:docstring>
- </tp:member>
- </tp:struct>
-
- <tp:struct name="Socket_Netmask_IPv6">
- <tp:docstring>An IPv6 network or subnet.</tp:docstring>
- <tp:member type="s" name="Address">
- <tp:docstring>An IPv6 address literal as specified by RFC2373
- section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
- </tp:member>
- <tp:member type="y" name="Prefix_Length">
- <tp:docstring>The number of leading bits of the address that must
- match, for this netmask to be considered to match an
- address.</tp:docstring>
- </tp:member>
- </tp:struct>
-
- <tp:enum name="Tube_Type" type="u">
+ <tp:enum name="Tube_Type" type="u" array-name="Tube_Type_List">
<tp:enumvalue suffix="DBus" value="0">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The tube is D-Bus tube as described by the
@@ -193,7 +143,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
</tp:enum>
- <tp:enum name="Socket_Access_Control" type="u">
+ <tp:enum name="Socket_Access_Control" type="u"
+ array-name="Socket_Access_Control_List">
<tp:enumvalue suffix="Localhost" value="0">
<tp:docstring>
The IP or Unix socket can be accessed by any local user (e.g.
diff --git a/spec/Client.xml b/spec/Client.xml
index d0bb8e5..5307efa 100644
--- a/spec/Client.xml
+++ b/spec/Client.xml
@@ -105,9 +105,9 @@
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A list of the extra interfaces provided by this client.
This SHOULD include at least one of
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer</tp:dbus-ref>,
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver</tp:dbus-ref> or
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>.</p>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.DRAFT</tp:dbus-ref>,
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver.DRAFT</tp:dbus-ref> or
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler.DRAFT</tp:dbus-ref>.</p>
<p>In the <code>.client</code> file, this is represented by key
"<code>Interfaces</code>" in the group named after this interface.
diff --git a/spec/Client_Approver.xml b/spec/Client_Approver.xml
index 8f59a19..8725c81 100644
--- a/spec/Client_Approver.xml
+++ b/spec/Client_Approver.xml
@@ -107,7 +107,7 @@
<arg name="DispatchOperation" type="o" direction="in">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>
to be processed.</p>
</tp:docstring>
</arg>
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index b29ffac..3d75f0b 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -34,7 +34,7 @@
<p>When a new incoming channel (one with
<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
= FALSE) is offered to
- <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver.DRAFT</tp:dbus-ref>s
by the channel dispatcher, it also offers the Approvers a list of all
the running or activatable handlers whose
<tp:member-ref>HandlerChannelFilter</tp:member-ref> property
@@ -140,7 +140,8 @@
</tp:docstring>
</arg>
- <arg name="Channels" type="a(oa{sv})" direction="in">
+ <arg name="Channels" type="a(oa{sv})" direction="in"
+ tp:type="Channel_Details[]">
<tp:docstring>
The channels and their immutable properties. Their well-known
bus name is the same as that of the Connection.
@@ -190,7 +191,7 @@
<arg name="Request" type="o" direction="in">
<tp:docstring>
The <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
object, which MUST have been returned by <tp:dbus-ref
namespace="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT">CreateChannel</tp:dbus-ref>
or <tp:dbus-ref
diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml
index 40c71e7..c06f83d 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -56,7 +56,7 @@
channels, doing the actual data transfer for file transfers,
setting up the out-of-band connection for Tubes). The
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>
is responsible for such tasks.</p>
<p>Handlers MAY, of course, delegate responsibility for these
diff --git a/spec/Connection.xml b/spec/Connection.xml
index ec0cc2e..39fb738 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -534,27 +534,31 @@ USA.</p>
</tp:enumvalue>
</tp:enum>
- <tp:simple-type name="Handle" type="u">
+ <tp:simple-type name="Handle" type="u" array-name="Handle_List">
<tp:docstring>An unsigned 32-bit integer representing a
handle</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="Contact_Handle" type="u">
+ <tp:simple-type name="Contact_Handle" type="u"
+ array-name="Contact_Handle_List">
<tp:docstring>An unsigned 32-bit integer representing a handle of type
Handle_Type_Contact</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="Room_Handle" type="u">
+ <tp:simple-type name="Room_Handle" type="u"
+ array-name="Room_Handle_List">
<tp:docstring>An unsigned 32-bit integer representing a handle of type
Handle_Type_Room</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="List_Handle" type="u">
+ <tp:simple-type name="List_Handle" type="u"
+ array-name="List_Handle_List">
<tp:docstring>An unsigned 32-bit integer representing a handle of type
Handle_Type_List</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="Group_Handle" type="u">
+ <tp:simple-type name="Group_Handle" type="u"
+ array-name="Group_Handle_List">
<tp:docstring>An unsigned 32-bit integer representing a handle of type
Handle_Type_Group</tp:docstring>
</tp:simple-type>
diff --git a/spec/Connection_Interface_Avatars.xml b/spec/Connection_Interface_Avatars.xml
index acc44de..e6f7ac5 100644
--- a/spec/Connection_Interface_Avatars.xml
+++ b/spec/Connection_Interface_Avatars.xml
@@ -21,7 +21,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<interface name="org.freedesktop.Telepathy.Connection.Interface.Avatars">
<tp:requires interface="org.freedesktop.Telepathy.Connection"/>
- <tp:simple-type name="Avatar_Token" type="s">
+ <tp:simple-type name="Avatar_Token" type="s"
+ array-name="Avatar_Token_List">
<tp:changed version="0.17.16">strengthened uniqueness requirements
so (CM name, protocol, token) is unique; previously only
(our Account, remote contact identifier, token) was required to be
@@ -124,8 +125,131 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</signal>
+ <property name="SupportedAvatarMIMETypes"
+ tp:name-for-bindings="Supported_Avatar_MIME_Types"
+ type="as" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ An array of supported MIME types (e.g. "image/jpeg").
+ Clients MAY assume that the first type in this array is preferred.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
+ <property name="MinimumAvatarHeight"
+ tp:name-for-bindings="Minimum_Avatar_Height"
+ type="u" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ The minimum height in pixels of an avatar on this protocol, which MAY
+ be 0.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
+ <property name="MinimumAvatarWidth"
+ tp:name-for-bindings="Minimum_Avatar_Width"
+ type="u" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ The minimum width in pixels of an avatar on this protocol, which MAY
+ be 0.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
+ <property name="RecommendedAvatarHeight"
+ tp:name-for-bindings="Recommended_Avatar_Height"
+ type="u" access="read">
+ <tp:added version="0.17.22"/>
+ <tp:docstring>
+ The recommended height in pixels of an avatar on this protocol, or 0 if
+ there is no preferred height.
+ This property cannot change after the Connection goes to the Connected
+ state.
+
+ <tp:rationale>
+ In XMPP a recommended width is given by the protocol specification;
+ in proprietary protocols, using the same avatar size as the
+ proprietary client is likely to lead to the best display to other
+ users.
+ </tp:rationale>
+ </tp:docstring>
+ </property>
+
+ <property name="RecommendedAvatarWidth"
+ tp:name-for-bindings="Recommended_Avatar_Width"
+ type="u" access="read">
+ <tp:added version="0.17.22"/>
+ <tp:docstring>
+ The recommended width in pixels of an avatar on this protocol, or 0 if
+ there is no preferred width.
+ This property cannot change after the Connection goes to the Connected
+ state.
+
+ <tp:rationale>
+ The rationale is the same as for
+ <tp:member-ref>RecommendedAvatarHeight</tp:member-ref>.
+ </tp:rationale>
+ </tp:docstring>
+ </property>
+
+ <property name="MaximumAvatarHeight"
+ tp:name-for-bindings="Maximum_Avatar_Height"
+ type="u" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ The maximum height in pixels of an avatar on this protocol, or 0 if
+ there is no limit.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
+ <property name="MaximumAvatarWidth"
+ tp:name-for-bindings="Maximum_Avatar_Width"
+ type="u" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ The maximum width in pixels of an avatar on this protocol, or 0 if
+ there is no limit.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
+ <property name="MaximumAvatarBytes"
+ tp:name-for-bindings="Maximum_Avatar_Bytes"
+ type="u" access="read">
+ <tp:added version="0.17.22">Fall back to calling
+ <tp:member-ref>GetAvatarRequirements</tp:member-ref> if getting this
+ property fails.</tp:added>
+ <tp:docstring>
+ The maximum size in bytes of an avatar on this protocol, or 0 if
+ there is no limit.
+ This property cannot change after the Connection goes to the Connected
+ state.
+ </tp:docstring>
+ </property>
+
<method name="GetAvatarRequirements"
tp:name-for-bindings="Get_Avatar_Requirements">
+ <tp:deprecated version="0.17.22">Use GetAll to retrieve the
+ D-Bus properties on this interface, falling back to this method
+ on failure.</tp:deprecated>
<arg direction="out" type="as" name="MIME_Types">
<tp:docstring>
An array of supported MIME types (eg image/jpeg)
diff --git a/spec/Connection_Interface_Contact_Info.xml b/spec/Connection_Interface_Contact_Info.xml
index a9d086a..d085454 100644
--- a/spec/Connection_Interface_Contact_Info.xml
+++ b/spec/Connection_Interface_Contact_Info.xml
@@ -300,7 +300,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="VCard_Type_Parameter" type="s">
+ <tp:simple-type name="VCard_Type_Parameter" type="s"
+ array-name="VCard_Type_Parameter_List">
<tp:docstring>
A type parameter as defined by RFC 2426, such as "type=cell" or
"language=en".
diff --git a/spec/Connection_Interface_Presence.xml b/spec/Connection_Interface_Presence.xml
index ecf96f8..100ec36 100644
--- a/spec/Connection_Interface_Presence.xml
+++ b/spec/Connection_Interface_Presence.xml
@@ -281,7 +281,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:possible-errors>
</method>
- <tp:deprecated version="0.17.UNRELEASED">New client implementations
+ <tp:deprecated version="0.17.21">New client implementations
SHOULD use <tp:dbus-ref
namespace="org.freedesktop.Telepathy.Connection.Interface">SimplePresence</tp:dbus-ref>
instead. New connection managers SHOULD implement both Presence
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Simple_Presence.xml
index 7acea32..8446050 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Simple_Presence.xml
@@ -349,7 +349,8 @@
</tp:enumvalue>
</tp:enum>
- <tp:enum name="Rich_Presence_Access_Control_Type" type="u">
+ <tp:enum name="Rich_Presence_Access_Control_Type" type="u"
+ array-name="Rich_Presence_Access_Control_Type_List">
<tp:docstring>
A type of access control for Rich_Presence_Access_Control.
For most types, the exact access control is given by an associated
diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml
index 46b56ac..ad8f058 100644
--- a/spec/Connection_Manager.xml
+++ b/spec/Connection_Manager.xml
@@ -55,7 +55,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
characters were not specified</tp:changed>
</tp:simple-type>
- <tp:simple-type name="Protocol" type="s">
+ <tp:simple-type name="Protocol" type="s" array-name="Protocol_List">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>An instant messaging protocol. It must consist only of ASCII
letters, digits and hyphen/minus signs (U+002D "-"), and must start
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index cb7c793..d335e38 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -70,6 +70,150 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:member>
</tp:struct>
+ <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
+ type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
+ <tp:added version="0.17.22"/>
+ <tp:docstring>
+ The IP addresses of possible STUN servers to use for NAT traversal, as
+ dotted-quad IPv4 address literals or RFC2373 IPv6 address literals.
+ This property cannot change once the stream has been created, so there
+ is no change notification. The IP addresses MUST NOT be given as DNS
+ hostnames.
+
+ <tp:rationale>
+ High-quality connection managers already need an asynchronous
+ DNS resolver, so they might as well resolve this name to an IP
+ to make life easier for streaming implementations.
+ </tp:rationale>
+ </tp:docstring>
+ </property>
+
+ <property name="CreatedLocally" tp:name-for-bindings="Created_Locally"
+ type="b" access="read">
+ <tp:added version="0.17.22"/>
+ <tp:docstring>
+ True if we were the creator of this stream, false otherwise.
+ <tp:rationale>
+ This information is needed for some nat traversal mechanisms, such
+ as ICE-UDP, where the creator gets the role of the controlling agent.
+ </tp:rationale>
+ </tp:docstring>
+ </property>
+
+ <property name="NATTraversal" tp:name-for-bindings="NAT_Traversal"
+ type="s" access="read">
+ <tp:added version="0.17.22"/>
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The transport (NAT traversal technique) to be used for this
+ stream. Well-known values include:</p>
+
+ <dl>
+ <dt>none</dt>
+ <dd>Raw UDP, with or without STUN, should be used. If the
+ <tp:member-ref>STUNServers</tp:member-ref> property is non-empty,
+ STUN SHOULD be used.</dd>
+
+ <dt>stun</dt>
+ <dd>A deprecated synonym for 'none'.</dd>
+
+ <dt>gtalk-p2p</dt>
+ <dd>Google Talk peer-to-peer connectivity establishment should be
+ used, as implemented in libjingle 0.3.</dd>
+
+ <dt>ice-udp</dt>
+ <dd>Interactive Connectivity Establishment should be used,
+ as defined by the IETF MMUSIC working group.</dd>
+
+ <dt>wlm-8.5</dt>
+ <dd>The transport used by Windows Live Messenger 8.5 or later,
+ which resembles ICE draft 6, should be used.</dd>
+
+ <dt>wlm-2009</dt>
+ <dd>The transport used by Windows Live Messenger 2009 or later,
+ which resembles ICE draft 19, should be used.</dd>
+ </dl>
+
+ <p>This property cannot change once the stream has been created, so
+ there is no change notification.</p>
+ </tp:docstring>
+ </property>
+
+ <property name="RelayInfo" type="aa{sv}" access="read"
+ tp:type="String_Variant_Map[]" tp:name-for-bindings="Relay_Info">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>A list of mappings describing TURN or Google relay servers
+ available for the client to use in its candidate gathering, as
+ determined from the protocol. Map keys are:</p>
+
+ <dl>
+ <dt><code>ip</code> - s</dt>
+ <dd>The IP address of the relay server as a dotted-quad IPv4
+ address literal or an RFC2373 IPv6 address literal. This MUST NOT
+ be a DNS hostname.
+
+ <tp:rationale>
+ High-quality connection managers already need an asynchronous
+ DNS resolver, so they might as well resolve this name to an IP
+ and make life easier for streaming implementations.
+ </tp:rationale>
+ </dd>
+
+ <dt><code>type</code> - s</dt>
+ <dd>
+ <p>Either <code>udp</code> for UDP (UDP MUST be assumed if this
+ key is omitted), <code>tcp</code> for TCP, or
+ <code>tls</code>.</p>
+
+ <p>The precise meaning of this key depends on the
+ <tp:member-ref>NATTraversal</tp:member-ref> property: if
+ NATTraversal is <code>ice-udp</code>, <code>tls</code> means
+ TLS over TCP as referenced by ICE draft 19, and if
+ NATTraversal is <code>gtalk-p2p</code>, <code>tls</code> means
+ a fake SSL session over TCP as implemented by libjingle.</p>
+ </dd>
+
+ <dt><code>port</code> - q</dt>
+ <dd>The UDP or TCP port of the relay server as an ASCII unsigned
+ integer</dd>
+
+ <dt><code>username</code> - s</dt>
+ <dd>The username to use</dd>
+
+ <dt><code>password</code> - s</dt>
+ <dd>The password to use</dd>
+
+ <dt><code>component</code> - u</dt>
+ <dd>The component number to use this relay server for, as an
+ ASCII unsigned integer; if not included, this relay server
+ may be used for any or all components.
+
+ <tp:rationale>
+ In ICE draft 6, as used by Google Talk, credentials are only
+ valid once, so each component needs relaying separately.
+ </tp:rationale>
+ </dd>
+ </dl>
+
+ <tp:rationale>
+ <p>An equivalent of the gtalk-p2p-relay-token property on
+ MediaSignalling channels is not included here. The connection
+ manager should be responsible for making the necessary HTTP
+ requests to turn the token into a username and password.</p>
+ </tp:rationale>
+
+ <p>The type of relay server that this represents depends on
+ the value of the <tp:member-ref>NATTraversal</tp:member-ref>
+ property. If NATTraversal is ice-udp, this is a TURN server;
+ if NATTraversal is gtalk-p2p, this is a Google relay server;
+ otherwise, the meaning of RelayInfo is undefined.</p>
+
+ <p>If relaying is not possible for this stream, the list is empty.</p>
+
+ <p>This property cannot change once the stream has been created, so
+ there is no change notification.</p>
+ </tp:docstring>
+ </property>
+
<signal name="AddRemoteCandidate"
tp:name-for-bindings="Add_Remote_Candidate">
<arg name="Candidate_ID" type="s">
@@ -246,7 +390,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
String identifier for remote candidate to drop
</tp:docstring>
</arg>
- <tp:deprecated>
+ <tp:deprecated version="0.17.18">
There is no case where you want to release candidates (except
for an ICE reset, and there you'd want to replace then all,
using <tp:member-ref>SetRemoteCandidateList</tp:member-ref>).
diff --git a/spec/Properties_Interface.xml b/spec/Properties_Interface.xml
index 91423c1..aaa4602 100644
--- a/spec/Properties_Interface.xml
+++ b/spec/Properties_Interface.xml
@@ -39,7 +39,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
<tp:member type="u" name="New_Flags"/>
</tp:struct>
- <tp:simple-type name="Property_ID" type="u">
+ <tp:simple-type name="Property_ID" type="u" array-name="Property_ID_List">
<tp:docstring>
An unsigned integer used to represent a Telepathy property.
</tp:docstring>
diff --git a/spec/all.xml b/spec/all.xml
index 1c377df..952ff6b 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.21</tp:version>
+<tp:version>0.17.22</tp:version>
<tp:copyright>Copyright © 2005-2009 Collabora Limited</tp:copyright>
<tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright>
diff --git a/spec/generic-types.xml b/spec/generic-types.xml
index fba6a9f..d4dce15 100644
--- a/spec/generic-types.xml
+++ b/spec/generic-types.xml
@@ -17,23 +17,27 @@
interfaces.</tp:rationale>
</tp:simple-type>
- <tp:simple-type name="DBus_Bus_Name" type="s">
+ <tp:simple-type name="DBus_Bus_Name" type="s"
+ array-name="DBus_Bus_Name_List">
<tp:docstring>A string representing a D-Bus bus name - either a well-known
name like "org.freedesktop.Telepathy.MissionControl" or a unique name
like ":1.123"</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="DBus_Well_Known_Name" type="s">
+ <tp:simple-type name="DBus_Well_Known_Name" type="s"
+ array-name="DBus_Well_Known_Name_List">
<tp:docstring>A string representing a D-Bus well-known
name like "org.freedesktop.Telepathy.MissionControl".</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="DBus_Unique_Name" type="s">
+ <tp:simple-type name="DBus_Unique_Name" type="s"
+ array-name="DBus_Unique_Name_List">
<tp:docstring>A string representing a D-Bus unique name, such as
":1.123"</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="DBus_Interface" type="s">
+ <tp:simple-type name="DBus_Interface" type="s"
+ array-name="DBus_Interface_List">
<tp:docstring>An ASCII string representing a D-Bus interface - two or more
elements separated by dots, where each element is a non-empty
string of ASCII letters, digits and underscores, not starting with
@@ -60,7 +64,8 @@
characters. For example, "Ping".</tp:docstring>
</tp:simple-type>
- <tp:simple-type name="DBus_Qualified_Member" type="s">
+ <tp:simple-type name="DBus_Qualified_Member" type="s"
+ array-name="DBus_Qualified_Member_List">
<tp:docstring>A string representing the full name of a D-Bus method,
signal or property, consisting of a DBus_Interface, followed by
a dot, followed by a DBus_Member. For example,
@@ -90,11 +95,74 @@
<tp:member type="v" name="Value"/>
</tp:mapping>
- <tp:mapping name="String_String_Map">
+ <tp:mapping name="String_String_Map" array-name="String_String_Map_List">
<tp:docstring>A mapping from strings to strings representing extra
key-value pairs.</tp:docstring>
<tp:member type="s" name="Key"/>
<tp:member type="s" name="Value"/>
</tp:mapping>
+ <tp:struct name="Socket_Address_IP" array-name="Socket_Address_IP_List">
+ <tp:docstring>An IP address and port.</tp:docstring>
+ <tp:member type="s" name="Address">
+ <tp:docstring>Either a dotted-quad IPv4 address literal as for
+ <tp:type>Socket_Address_IPv4</tp:type>, or an RFC2373 IPv6 address
+ as for <tp:type>Socket_Address_IPv6</tp:type>.
+ </tp:docstring>
+ </tp:member>
+ <tp:member type="q" name="Port">
+ <tp:docstring>The TCP or UDP port number.</tp:docstring>
+ </tp:member>
+ </tp:struct>
+
+ <tp:struct name="Socket_Address_IPv4">
+ <tp:docstring>An IPv4 address and port.</tp:docstring>
+ <tp:member type="s" name="Address">
+ <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
+ numbers, each between 0 and 255 inclusive, e.g.
+ "192.168.0.1".</tp:docstring>
+ </tp:member>
+ <tp:member type="q" name="Port">
+ <tp:docstring>The TCP or UDP port number.</tp:docstring>
+ </tp:member>
+ </tp:struct>
+
+ <tp:struct name="Socket_Address_IPv6">
+ <tp:docstring>An IPv6 address and port.</tp:docstring>
+ <tp:member type="s" name="Address">
+ <tp:docstring>An IPv6 address literal as specified by RFC2373
+ section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
+ </tp:member>
+ <tp:member type="q" name="Port">
+ <tp:docstring>The TCP or UDP port number.</tp:docstring>
+ </tp:member>
+ </tp:struct>
+
+ <tp:struct name="Socket_Netmask_IPv4">
+ <tp:docstring>An IPv4 network or subnet.</tp:docstring>
+ <tp:member type="s" name="Address">
+ <tp:docstring>A dotted-quad IPv4 address literal: four ASCII decimal
+ numbers, each between 0 and 255 inclusive, e.g.
+ "192.168.0.1".</tp:docstring>
+ </tp:member>
+ <tp:member type="y" name="Prefix_Length">
+ <tp:docstring>The number of leading bits of the address that must
+ match, for this netmask to be considered to match an
+ address.</tp:docstring>
+ </tp:member>
+ </tp:struct>
+
+ <tp:struct name="Socket_Netmask_IPv6">
+ <tp:docstring>An IPv6 network or subnet.</tp:docstring>
+ <tp:member type="s" name="Address">
+ <tp:docstring>An IPv6 address literal as specified by RFC2373
+ section 2.2, e.g. "2001:DB8::8:800:200C:4171".</tp:docstring>
+ </tp:member>
+ <tp:member type="y" name="Prefix_Length">
+ <tp:docstring>The number of leading bits of the address that must
+ match, for this netmask to be considered to match an
+ address.</tp:docstring>
+ </tp:member>
+ </tp:struct>
+
</tp:generic-types>
--
1.5.6.5
More information about the telepathy-commits
mailing list