> So I think using the node name as a device identifier (or more > precicely: an identifier for entities that want to receive the same push > notifications and are thus registered for the same node) is sufficient > for the xmpp server.
Yes, that is the correct interpretation. Imagine for example that Apple's push service was actually implemented as an XMPP Push Service. The 'device ID' given to your iOS app would be the node. What a node actually represents is 100% completely arbitrary and decided by the App Server. The App Server you create for your new app could treat node == device ID so that it can target specific devices, or you might want to just always notify all of a user's devices (or none!) and thus node == user. All of which means that your XMPP server has no internal knowledge of phones or devices, only of applications/services. > When a client sends an enable stanza the server > updates an existing record for the client's full jid with the stanza's > new 'node' value. That's actually already described in the XEP. I may need to add additional clarifying language to the XEP then. Enabling and disabling as defined is for the bare JID account level. However, servers could keep track of which services a particular resource connection enabled and use that information to do more intelligent notifications. 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. Of course, what defines interesting (and the levels and kinds of interesting) is left to the server implementation and to future XEPs, but there are a lot more potential things than just offline messages. > One of your requirements is still not met: you have to know the resource > to enable / disable push. > > So what if my phone gets stolen and I want disable push notifications > for it? I could log in from another device using the same full jid. But > you also mentioned random strings as resources… Then your App Server needs to provide a way to disable notifications to your phone, which is already the case today for mobile apps. The topic of push is hard to talk about without assuming everything is directed to mobile devices, but the point is that XMPP servers really shouldn't need to know what a phone even is. Consider XMPP Push Services whose associated App Server is nothing more than a daily 'things you missed' email summary generator — a case with no mobile app, no mobile device, and no particular associated resource. > One solution to the stolen phone problem would be an emergency-off > switch (disable all resources of the user on all nodes): > > <iq type='set' id='x97'> > <disable-all xmlns='urn:xmpp:push:0' jid='push-5.client.example' /> > </iq> That is already the defined behaviour for the <disable /> element when no node is provided, but you would need to know the JID of the service. — Lance
smime.p7s
Description: S/MIME cryptographic signature
