telepathy-spec issueshttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues2019-12-03T20:24:23Zhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/119spec xml should have <tp:rfc-ref> for referring to rfcs2019-12-03T20:24:23ZBugzilla Migration Userspec xml should have <tp:rfc-ref> for referring to rfcs## Submitted by David Laban `@alsuren`
Assigned to **Telepathy bugs list**
**[Link to original bug (#38787)](https://bugs.freedesktop.org/show_bug.cgi?id=38787)**
## Description
Currently, we have a mixture of links to faqs.org an...## Submitted by David Laban `@alsuren`
Assigned to **Telepathy bugs list**
**[Link to original bug (#38787)](https://bugs.freedesktop.org/show_bug.cgi?id=38787)**
## Description
Currently, we have a mixture of links to faqs.org and ietf. I would love to be able to replace them all with something of the form:
<tp:rfc-ref rfc="5245" section="9.1.1.1"/>
so that we can standardise the formatting of spec text (e.g. "RFC 5245 § 9.1.1.1") and link to the same reference site (e.g. http://tools.ietf.org/html/rfc5245#section-9.1.1.1)
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/118Add Protocol.Interface.PeerSecurity interface2019-12-03T20:24:19ZBugzilla Migration UserAdd Protocol.Interface.PeerSecurity interface## Submitted by Stef Walter
Assigned to **Telepathy bugs list**
**[Link to original bug (#38404)](https://bugs.freedesktop.org/show_bug.cgi?id=38404)**
## Description
This will allow a protocol to build a connection and get securi...## Submitted by Stef Walter
Assigned to **Telepathy bugs list**
**[Link to original bug (#38404)](https://bugs.freedesktop.org/show_bug.cgi?id=38404)**
## Description
This will allow a protocol to build a connection and get security information about a peer. This will primarily be used to retrieve certificates for a connection, so the user can 'Pin' them in account configuration dialog.
See: https://bugzilla.gnome.org/show_bug.cgi?id=652814
Version: git master
### Blocking
* [Bug 38405](https://bugs.freedesktop.org/show_bug.cgi?id=38405)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/117clarify whether Approvers are called for channels with no Handler2019-12-03T20:24:17ZBugzilla Migration Userclarify whether Approvers are called for channels with no Handler## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#37373)](https://bugs.freedesktop.org/show_bug.cgi?id=37373)**
## Description
+++ This bug was initially created as a clone of Bug #29022 ...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#37373)](https://bugs.freedesktop.org/show_bug.cgi?id=37373)**
## Description
+++ This bug was initially created as a clone of Bug #29022 +++
By inspection of the source code, if a dispatch operation has no PossibleHandlers, MC doesn't seem to dispatch it to observers or to approvers.
test/twisted/dispatcher/undispatchable.py should create a Text Observer and a Text Approver, and assert whether their methods are called. However, it doesn't.
I think Observers should be invoked for undispatchable operations (rationale: implementing ObserveChannels should be like listening for NewChannels). I'm not so sure about Approvers.
In favour of running Approvers if there's no Handler:
+ consistent with observers
+ maybe the Approver can arrange for a non-service-activatable Handler to be started out-of-band
+ maybe the Approver knows out-of-band that an existing Handler can secretly handle the channel, even though its filter says otherwise (symmetry with the PreferredHandler overriding filters)
Against running Approvers if there's no Handler:
- until now, if the Approver calls HandleChannels("") and gets an error, it's always an error from the Handler; now, HandleChannels("") has to be able to return a specified error that means "actually, I can't do that"
- if the Approver blindly calls HandleChannels(Possible_Handlers[0]), it'll crash itself ("don't do that then" is a reasonable answer)
- Approvers are for interactive approval: is it really appropriate for an interactive approver to pop up if approval is impossible anyway? If you have some UI for "smcv is sending you a file [Save] [Reject]", would it ever make sense for it to pop up to say "smcv is sending you a file but you can't receive it [OK]", and would Approver authors actually deal with this correctly anyway?
(It would be rubbish UI to have a popup that says "smcv is sending you a file [Save] [Reject]", and then when you click Save, have an error message "you can't receive files".)
One possible solution is to let Approvers set a flag for whether they want to be nagged about undispatchable channels, with the default being FALSE (because that's the one that doesn't need the Approver author to take any other special action).
Version: git master
### Depends on
* [Bug 29022](https://bugs.freedesktop.org/show_bug.cgi?id=29022)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/116Add a flag in Message_Key for message sent form another terminal2019-12-03T20:24:14ZBugzilla Migration UserAdd a flag in Message_Key for message sent form another terminal## Submitted by Nicolas Dufresne `@ndufresne`
Assigned to **Telepathy bugs list**
**[Link to original bug (#37298)](https://bugs.freedesktop.org/show_bug.cgi?id=37298)**
## Description
On some protocols, like Skype, when messages ...## Submitted by Nicolas Dufresne `@ndufresne`
Assigned to **Telepathy bugs list**
**[Link to original bug (#37298)](https://bugs.freedesktop.org/show_bug.cgi?id=37298)**
## Description
On some protocols, like Skype, when messages are sent from another protocol, the messages are also sent to all other connected terminals. This allow keeping all the computers/phone/tablet on sync in a way you can switch from one to another and not loose the context.
On the N900 those messages are simply sent as new messages with the annoying side effect that the phone notify you of a new message, while in fact it is you that sent the message from you computer.
What I'm proposing is to add a flag to Message_Key headers that would serve this purpose. I have two options in mind.
1) A very specific flag similar to "echoed", that would applied for the type of message described before
2) Or a more generic one like "no-notify", that can be used for any new messages that do not really require user attention.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/115Clarify transitions and semantics of Call.Stream.LocalSendingState with regar...2019-12-03T20:24:12ZBugzilla Migration UserClarify transitions and semantics of Call.Stream.LocalSendingState with regard to remotely requested changes## Submitted by Mikhail Zabaluev
Assigned to **Telepathy bugs list**
**[Link to original bug (#37291)](https://bugs.freedesktop.org/show_bug.cgi?id=37291)**
## Description
In SIP, an offer to stop sending media over a stream is bi...## Submitted by Mikhail Zabaluev
Assigned to **Telepathy bugs list**
**[Link to original bug (#37291)](https://bugs.freedesktop.org/show_bug.cgi?id=37291)**
## Description
In SIP, an offer to stop sending media over a stream is binding: when the local endpoint receives SDP with one or more streams restricted to "sendonly" or "inactive" (from the sender's POV), it cannot answer with these streams allowed to send. Therefore, it would seem reasonable to change the LocalSendingState on the corresponding Stream objects to Pending_Stop_Sending (and stop sending on the Media face?). Upon this, the client can: 1) change nothing; 2) disable sending from its end with SetSending(false). In the first case, the local sending state can transition immediately back to Sending when the remote party allows sending again. In the second case, the local sending state will switch to None, from where it can transition to Pending_Send when the remote party allows sending.
If this interpretation is correct, the described transitions and client behaviour ought to be documented as the recommended practice. However, this would suggest that the name "Pending_Stop_Sending" is misleading, because this state does not necessarily prompt a reaction from the client signalling-wise, but it does mean that sending of media should already be stopped. Are there in fact protocols where an offer to stop sending may be constructively refused? I can't see how it can make practical sense.
This is complicated by the hold use case, which in SIP signalling is realized as requesting to stop sending on all streams without specific indication for the reason. Thus in case of SIP, the same logic should complement the CallState signalling about remote hold, as hiding it for this special case would produce ugly inconsistencies and corner cases.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/114properties' is-a-parameter boilerplate is misleading2019-12-03T20:24:09ZBugzilla Migration Userproperties' is-a-parameter boilerplate is misleading## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#37005)](https://bugs.freedesktop.org/show_bug.cgi?id=37005)**
## Description
> MessageNationalCharacterSet — s
...
> Note: Connections im...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#37005)](https://bugs.freedesktop.org/show_bug.cgi?id=37005)**
## Description
> MessageNationalCharacterSet — s
...
> Note: Connections implementing this property SHOULD provide a corresponding
> parameter named org.freedesktop.Telepathy.Connection.Interface.Cellular
> with the DBus_Property flag.
That should say "... named org.freedesktop.Telepathy.Connection.Interface.Cellular.MessageNationalCharacterSet with ...", and similar for any other property with the is-parameter attribute (or whatever it's called).
Version: 0.13https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/113specify Chan.I.DTMF signal/method-return ordering2019-12-03T20:24:06ZBugzilla Migration Userspecify Chan.I.DTMF signal/method-return ordering## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#36880)](https://bugs.freedesktop.org/show_bug.cgi?id=36880)**
## Description
The DTMF spec doesn't specify whether the signals...## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#36880)](https://bugs.freedesktop.org/show_bug.cgi?id=36880)**
## Description
The DTMF spec doesn't specify whether the signals should be emitted before or after the method call returns.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/112Chan.I.DTMF default pause duration seems to be protocol dependent2019-12-03T20:24:01ZBugzilla Migration UserChan.I.DTMF default pause duration seems to be protocol dependent## Submitted by Nicolas Dufresne `@ndufresne`
Assigned to **Telepathy bugs list**
**[Link to original bug (#36031)](https://bugs.freedesktop.org/show_bug.cgi?id=36031)**
## Description
Chan.I.DTMF recommend 3 seconds for pause whi...## Submitted by Nicolas Dufresne `@ndufresne`
Assigned to **Telepathy bugs list**
**[Link to original bug (#36031)](https://bugs.freedesktop.org/show_bug.cgi?id=36031)**
## Description
Chan.I.DTMF recommend 3 seconds for pause which seems too long and is against RFC 3601 (Text String Notation for Dial Sequences and Global Sw) recommendations of 1 second.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/111spec doesn't define how to indicate unsupported DTMF tone2019-12-03T20:23:59ZBugzilla Migration Userspec doesn't define how to indicate unsupported DTMF tone## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35478)](https://bugs.freedesktop.org/show_bug.cgi?id=35478)**
## Description
DTMF_Event includes tones for [ABCD] but these ar...## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35478)](https://bugs.freedesktop.org/show_bug.cgi?id=35478)**
## Description
DTMF_Event includes tones for [ABCD] but these are not supported on all protocols (at least one protocol only supports [0-9*#]).
The spec does not specify what error to return (if any) when requesting an unsupported tone.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/2Ability to set nick when joining e.g. XMPP chat2019-12-03T20:23:58ZBugzilla Migration UserAbility to set nick when joining e.g. XMPP chat## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#13348)](https://bugs.freedesktop.org/show_bug.cgi?id=13348)**
## Description
how do you specify the server and your nickname when joining...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#13348)](https://bugs.freedesktop.org/show_bug.cgi?id=13348)**
## Description
how do you specify the server and your nickname when joining a chat?
(from telepathy-spec TODO)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/1Consider adding StopOfferingTube() that corresponds to only close()ing the li...2019-12-03T20:23:57ZBugzilla Migration UserConsider adding StopOfferingTube() that corresponds to only close()ing the listening socket## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#13272)](https://bugs.freedesktop.org/show_bug.cgi?id=13272)**
## Description
The model in the current Tubes spec is that when you close t...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#13272)](https://bugs.freedesktop.org/show_bug.cgi?id=13272)**
## Description
The model in the current Tubes spec is that when you close the stream tube you were offering, it's because you want to stop offering the service at all. The use case we were thinking of was something like:
* you're in a chatroom with Alice, Bob and Chris
* you offer your desktop over VNC so they can help you with something
* Alice and Bob connect
* when they've helped you with whatever it was you wanted, you close the stream tube
* Alice and Bob automatically get disconnected
* You open confidential files that Alice and Bob shouldn't see, but that's OK because you know they've been disconnected
However, with normal TCP sockets, it's also possible to close() the listening socket while keeping Alice and Bob's connections open. For instance, you might have a two-player game that only wants to listen() until a second player joins, then give ECONNREFUSED to anyone who tries to join thereafter, while keeping a TCP stream going between the two players.
I think we should keep the current CloseTube() semantics, for least astonishment, but we should consider adding a StopOfferingTube() method that stops accepting new connections but leaves existing connections as they are.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/110Need a way to get MaySaveResponse without having a SASL channel2019-12-03T20:23:56ZBugzilla Migration UserNeed a way to get MaySaveResponse without having a SASL channel## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35382)](https://bugs.freedesktop.org/show_bug.cgi?id=35382)**
## Description
From https://bugzilla.gnome.org/show_bug.cg...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35382)](https://bugs.freedesktop.org/show_bug.cgi?id=35382)**
## Description
From https://bugzilla.gnome.org/show_bug.cgi?id=643690#c8:
"""
MaySaveResponse [1] is a property on the SASL channel, but we don't have such
channel when the account has just be created (we have to connect). Maybe this
property should be exposed on the Account object as well?
"""
Basically, we need a way to know if we can save the password of an account before trying to connect it. It should be exposed on the Account or Protocol object.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/109Clarify Close() state change for FT channels2019-12-03T20:23:53ZBugzilla Migration UserClarify Close() state change for FT channels## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35371)](https://bugs.freedesktop.org/show_bug.cgi?id=35371)**
## Description
Non-complete/cancelled FT channels are expected t...## Submitted by Danielle Madeley `@danni`
Assigned to **Telepathy bugs list**
**[Link to original bug (#35371)](https://bugs.freedesktop.org/show_bug.cgi?id=35371)**
## Description
Non-complete/cancelled FT channels are expected to emit a state change to Cancelled/Local-stopped before closing.
This should be documented in the spec.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/108FileTransfer.URI erroneously claims to be immutable “depending on the protocol”2019-12-03T20:23:51ZBugzilla Migration UserFileTransfer.URI erroneously claims to be immutable “depending on the protocol”## Submitted by Will Thompson `@wjt`
Assigned to **Telepathy bugs list**
**[Link to original bug (#34347)](https://bugs.freedesktop.org/show_bug.cgi?id=34347)**
## Description
http://telepathy.freedesktop.org/spec/Channel_Type_Fil...## Submitted by Will Thompson `@wjt`
Assigned to **Telepathy bugs list**
**[Link to original bug (#34347)](https://bugs.freedesktop.org/show_bug.cgi?id=34347)**
## Description
http://telepathy.freedesktop.org/spec/Channel_Type_File_Transfer.html#Property:URI
The template for tp:immutable='sometimes' assumes that it depends on the protocol, but in this case it depends on some other property, namely Requested. Should we add if-requested, if-unrequested, or loosen the wording?https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/107Document the case for multiple non-interactive "pre-approvers"2019-12-03T20:23:49ZBugzilla Migration UserDocument the case for multiple non-interactive "pre-approvers"## Submitted by Mikhail Zabaluev
Assigned to **Telepathy bugs list**
**[Link to original bug (#33766)](https://bugs.freedesktop.org/show_bug.cgi?id=33766)**
## Description
In handling channels, there may be a need to reliably conf...## Submitted by Mikhail Zabaluev
Assigned to **Telepathy bugs list**
**[Link to original bug (#33766)](https://bugs.freedesktop.org/show_bug.cgi?id=33766)**
## Description
In handling channels, there may be a need to reliably confirm certain facts before the user is alerted by an approver, or the channel is dispatched to the handler.
As an example, before launching an incoming call alert, the following actions need to be completed:
* The logger needs to reliably store the incoming call event;
* The resource policy hook needs to reserve resources necessary for the call.
The message flow described in bug #27860 details how one client can "hijack" the channel, but it does not describe how multiple entities can serve as mandatory checkpoints.
The observer property DelayApprovers looks like the necessary hinge to implement this: it's possible for observers to delay return from ObserveChannels until they have confirmed readiness. If this is deemed to be a good enough way (the channel dispatcher is supposed to give sensible timeouts to ObserveChannels?), it should be documented.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/106Channel-specific nicknames2019-12-03T20:23:44ZBugzilla Migration UserChannel-specific nicknames## Submitted by Jonny Lamb `@jonnylamb`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33589)](https://bugs.freedesktop.org/show_bug.cgi?id=33589)**
## Description
To really fix bug #33048 we need to be able to do t...## Submitted by Jonny Lamb `@jonnylamb`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33589)](https://bugs.freedesktop.org/show_bug.cgi?id=33589)**
## Description
To really fix bug #33048 we need to be able to do two things:
1. change your nickname in an XMPP MUC.
2. join an XMPP with a specific nickname.
I've implemented this using a method and a property:
Chan.I.Group.SetOwnNickname(s): simply sets your own nickname in the channel if the protocol supports it. The nickname is changed when SelfHandleChanged is fired. This fixes #1.
Conn.I.RoomNickname.DRAFT.DefaultNickname: s, rw: a DBus property connection manager property (so it can be persistent). This fixes #2 by having a global nickname that is used when you join rooms. If it's the empty string then gabble will make up the nickname like it's been doing for years.
Neither of these will fix the case of you wanting different nicknames for different XMPP MUCs which you want set when you join them. tbh I think we should fix that when/if we need to.
Whaddya think?
Version: git master
### Blocking
* [Bug 33048](https://bugs.freedesktop.org/show_bug.cgi?id=33048)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/105Give avatar URI on Account2019-12-03T20:23:40ZBugzilla Migration UserGive avatar URI on Account## Submitted by Xavier Claessens `@xclaesse`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33409)](https://bugs.freedesktop.org/show_bug.cgi?id=33409)**
## Description
Since AM is supposed to save on disk the avata...## Submitted by Xavier Claessens `@xclaesse`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33409)](https://bugs.freedesktop.org/show_bug.cgi?id=33409)**
## Description
Since AM is supposed to save on disk the avatar, it is convenient for clients to get it as URI. For example contactsd (meego telepathy->tracker daemon) need to save again on disk which could be avoided if AM communicate where it already saved it.
Also it's much more efficient than travelling avatar data over DBus.
I know this is breaking the hypothetical case where AM/CM are running on another machine, but does that really matter?
I'm thinking the same for CM doing the avatar cache, maybe we could have some flags on the account "this run on the local machine, so please give URI instead of avatar data over DBus" ?https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/104Call: Support SDP Capability Negotiation (RFC 5939)2019-12-03T20:23:36ZBugzilla Migration UserCall: Support SDP Capability Negotiation (RFC 5939)## Submitted by Olivier Crête `@ocrete`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33039)](https://bugs.freedesktop.org/show_bug.cgi?id=33039)**
## Description
Look at how to support SDEP Cap Neg..
It is requir...## Submitted by Olivier Crête `@ocrete`
Assigned to **Telepathy bugs list**
**[Link to original bug (#33039)](https://bugs.freedesktop.org/show_bug.cgi?id=33039)**
## Description
Look at how to support SDEP Cap Neg..
It is required by TS 126.114 section 6.2.1a (LTE SIP/RTP requirements) to use a profile other than RTP/AVP, so we must make sure that our API supports it.
The big thing about SDPCapNeg is that you can offer more than one possible configuration at the same time.
There are three ways we can support this:
1. Modify the MediaDescriptionOffer to include multiple offers at the same time
2. Have the CM do each offer in order until one is accepted by the client
3. Completely move the negotation inside the CM and make the API more simple by only having the client declare all of its capabilities and then have the CM just tell the client about the chosen offer.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/103Support setting Location globally2019-12-03T20:23:34ZBugzilla Migration UserSupport setting Location globally## Submitted by Will Thompson `@wjt`
Assigned to **Telepathy bugs list**
**[Link to original bug (#32956)](https://bugs.freedesktop.org/show_bug.cgi?id=32956)**
## Description
[Bug 24104](https://bugs.freedesktop.org/show_bug.cgi?...## Submitted by Will Thompson `@wjt`
Assigned to **Telepathy bugs list**
**[Link to original bug (#32956)](https://bugs.freedesktop.org/show_bug.cgi?id=32956)**
## Description
[Bug 24104](https://bugs.freedesktop.org/show_bug.cgi?id=24104) proposes an API for setting presence across all accounts. It would be nice to support setting Location across all accounts in a similar way, allowing a location service to call a single method when the user's location changes, rather than having to monitor for new connections on which to set the current location constantly.
(In a perfect world we could also set aliases, avatars, and so on across all accounts. Avatars are not so easy. Let's start small.)
Version: git master
### Depends on
* [Bug 24104](https://bugs.freedesktop.org/show_bug.cgi?id=24104)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/102Be able to format presence message2019-12-03T20:23:31ZBugzilla Migration UserBe able to format presence message## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#32404)](https://bugs.freedesktop.org/show_bug.cgi?id=32404)**
## Description
If at some point we want to support things ...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#32404)](https://bugs.freedesktop.org/show_bug.cgi?id=32404)**
## Description
If at some point we want to support things like MSN plus tags, we should have spec allowing to format presence messages.
See https://bugzilla.gnome.org/show_bug.cgi?id=617964 for the Empathy bug report and http://bugzilla-attachments.gnome.org/attachment.cgi?id=176378 for a scary example. :)