Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote: The defined workflow is that when the XMPP server detects something interesting happened, then it has a set of JID+node endpoints that can be informed of that interesting event via pubsub publishes. We could let the server have the option to pick which of those JID+node combos it will publish to, but there is not a defined way to choose any particular subset. However, there are options available to pick from, for example: - Was the interesting event associated with a particular resource that also had enabled push services? Send the publish to only those services. - Are there push services for a user which have not been enabled by any of the user's current online sessions? Send the publish only to those services. - Publish to all enabled services regardless of if the user has any online resources. I expect that the XEP will expand to cover this topic once we have some more implementation experience on what works well in practice. As there's currently no specification on what are interesting push events, it's completely up to the implementer. My implementation currently defines events as: a message / presence subscription was stored by stream management's resumption feature This means if a client enables push and then goes offline it'll never receive notifications (unless it goes back online). The server will send notifications only if the client closed the tcp connection without sending the closing stream tag or when a dead tcp connection is detected. Is this a valid interpretation? We should define what going offline means for push (at least say it's up to server implementations).
[Standards] UPDATED: XEP-0293 (Jingle RTP Feedback Negotiation)
Version 0.2 of XEP-0293 (Jingle RTP Feedback Negotiation) has been released. Abstract: This specification defines an XMPP extension to negotiate the use of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) with Jingle RTP sessions Changelog: Added XML Schema; Updated based on last-call feedback. (ph) Diff: http://xmpp.org/extensions/diff/api/xep/0293/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0293.html
[Standards] UPDATED: XEP-0294 (Jingle RTP Header Extensions Negotiation)
Version 0.2 of XEP-0294 (Jingle RTP Header Extensions Negotiation) has been released. Abstract: This specification defines an XMPP extension to negotiate the use of the use of RTP Header Extension as defined by RFC 5285 with Jingle RTP sessions Changelog: Added XML Schema; Updated based on last call feedback. (ph) Diff: http://xmpp.org/extensions/diff/api/xep/0294/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0294.html
[Standards] Fwd: XMPP Council Minutes, 20150325T1600Z
FYI. -- Forwarded message -- From: Dave Cridland d...@cridland.net Date: 25 March 2015 at 16:20 Subject: XMPP Council Minutes, 20150325T1600Z To: XMPP Council coun...@xmpp.org Present: Dave Cridland (Acting Chair), Philipp 'Fippo' Hancke, Lance Stout, Matthew Wild Apologies: Kevin Smith (Chair) 0. Agenda Bashing 1. Actions 2. AOB 3. Time and Date of next 1. Actions - Dave has action to write a XEP Life Cycle blog post; he's sent this to the Council list. Fippo has reviewed these, Lance said in the meeting it looks good. 2. AOB - Fippo reminded Dave that there is a new version of the DNA I-D to review within the IETF's XMPP Working Group. - Fippo also reminded Council that Kev asked all members to sign up as GSoC Mentors. 3. Time and Date of Next ** TIMEZONE SHIFT ** Since the timezone changes for all EU countries this weekend, the next meeting will move time slot in UTC (and US local times), but stay the same for EU residents. Therefore the next meeting will be 20150401T1500Z (this is either an hour earlier or the same time depending on your timezone). ** TIMEZONE SHIFT ** 4. Ite, Meeting Est
[Standards] Proposed XMPP Extension: Push
Hi all, I make an XMPP app on iOS called Monal. Much of my comments are based on my experiences developing an XMPP client on iOS for the past 6 years. My concerns may be Apple specific in some places but since the intent of the XEP is for a very general implementation, these issues should be considered. Apologies for resurrecting this discussion. The proposed XEP does not seem to address token expiration. On Apple platforms (and likely others) the push token will change periodically. This information is provided on a feedback channel to the App server but there is no way for it to communicate this to the XMPP server. There is really no way for the client to know it’s token has expired so It will not know to request a new one from the push service and the messages will just be lost. In addition even if the client were to somehow know, there doesn't seem to be a way for the client to refresh its token with the XMPP server. It may also be nice if the client could define what events it cared about. Most mobile clients are probably not going to care much about anything other than ping and message stanzas when operating in the background. There would be significant battery life improvements if a client could take advantage of XEP-0198 (with a very long expiration) to close the socket unless a message or ping arrived. While XEP-0198 is probably beyond the scope of this document, it’s probably how I and others will try to use push, so it may warrant mentioning. Thanks, -Anu
