> On Mar 25, 2015, at 8:34 PM, Anu Pokharel <i...@monal.im> wrote: > > 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.
No apologies necessary! The discussion is still underway.
> 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.
On iOS, and I expect this to be a general case on mobile, your app is supposed
to register itself for remote push notifications every time it launches,
precisely because the tokens/deviceIDs can expire and change.
Which means, on startup, an iOS app will need to:
1. Register with the OS/APNS for a device ID (call it DeviceToken)
2. Register itself with the App Server (e.g., 'push.monal.im') to optionally
receive AppToken.
3. Send an <enable /> request to the XMPP server.
Now, that <enable/> request needs to include some data, and there are a few
ways to do this:
1. <enable jid='push.monal.im' node='DeviceToken' />
In this case, your app server will more or less be acting as a straight proxy
to APNS. This will add a new entry to the user's set of push endpoints if the
DeviceToken did change, but old ones should get cleaned up when the app server
returns errors.
2. <enable jid='push.monal.im' node='AppToken' />
In this case, the AppToken abstracts the DeviceToken so that things work even
when the DeviceToken changes, when there are multiple DeviceTokens for a user,
etc.
Note that the XMPP server can't actually distinguish between those cases, nor
should it need to. The semantics of that node value are meaningful only to the
app server ('push.monal.im'); the XMPP server only cares that it can publish to
that node. The app server could even be able to speak to both APNS and GCM,
delivering notifications to both iOS and Android clients for the same event.
Personally, I prefer and will be using the second option.
> 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.
Yes, Christian had some thoughts on selecting what gets pushed out. I'll be
adding a way to do that in the XEP soon. In particular, I want to add that
mechanism to handle the case where my XMPP server might include message content
in the push data (because I the user am ok with that tradeoff), but an App
server could wish to *never* receive that information. I believe Monal would
fall into that group.
As it currently stands, when and what constitutes a push-worthy event is left
to the server implementation. Christian has been working on an implementation
for Ejabberd that uses XEP-0198 to determine when to start sending
notifications. I expect we'll be able to start standardizing some of those with
a bit more implementation experience.
- Lance
smime.p7s
Description: S/MIME cryptographic signature
