[Standards] HTTPS certificate expired
This may have mentioned before but I just noticed that the HTTPS certificate for xmpp.org http://xmpp.org/ has expired. Thanks, Eelco signature.asc Description: Message signed with OpenPGP using GPGMail This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: [Standards] Proposed XMPP Extension: Push
On Mar 10, 2015, at 8:12 AM, Christian Ulrich christian...@rechenwerk.net wrote: Thanks for clarifying. Do we allow a client to send an enable stanza before resource binding then? We should not, if we want to allow the first two options you mentioned. I don't see a need to particularly restrict that ability since it's an App Client that will be making the enable call, so if the app needs to have a resource association it should wait until after binding. At the least, a suggestion to wait until binding would be good, right? more details I came across: The XEP defines the push notification field last-message-body. RFC 6120 says: Multiple instances of the body/ element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value Quite a rare case I think, should the server just pick the first body or should it include all bodies like this: Ah, right. That's going to get tricky very quickly, but I'm not seeing anything better than your suggestion right now. Is there a reason why jingle events (like in the old version) are not included in the field list? The summary form is meant to be just that — a summary of information you will always want to have in a push so you can keep counters and badges, etc, synced properly. Not everything needs to be forced to fit into the summary form; you can include any other payload elements you wish. I've (maybe incorrectly?) thought of the summary data to be 'passive' data. So I'm undecided how Jingle would fit there yet, since it is more of a call-to-action that could need special treatment. I am anticipating an update to http://xmpp.org/extensions/xep-0353.html to define how to use it with push, which would cover this case. Could a server shutdown be a push event? No reason why not. I'm not sure what you'd do with the information, but if that's interesting to applications, then yeah. - Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote: 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. Thanks for clarifying. Do we allow a client to send an enable stanza before resource binding then? We should not, if we want to allow the first two options you mentioned. For my implementation I decided to use a little trick for now in order to reduce complexity: Potentially interesting things are defined by stream management storing a stanza for later delivery. Important detail: When a push-enabled client enters the waiting-for-resumption state (a.k.a. zombie state), because stream management recognized the connection was closed, the push-module overwrites the resumption timeout (typically something like 5 min) with a long time span (e.g. 100 days). Interesting things thus happen only for clients having stream management resumption enabled. That's a little sad for clients without that feature but in my view has some advantages: - stream management may only be enabled when resource binding is complete, so all the potentially interesting stanzas are directed to a full jid. So the responsibility to route stanzas is delegated to the server's routing algorithm and might be configured by XEP-0354 in the future. - filtering mechanisms like CSI can be used (not possible if client is offline) - client stays in an available state, presence information is visible to presence subscribers (e.g. another resource might want to know the priority to become more / less available) more details I came across: The XEP defines the push notification field last-message-body. RFC 6120 says: Multiple instances of the body/ element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value Quite a rare case I think, should the server just pick the first body or should it include all bodies like this: ... x xmlns='jabber:x:data' field var='FORM_TYPE'valueurn:xmpp:push:summary/value/field field var='last-message-body' option label='de'valueWarum bist du Romeo?/value option label='en'valueWherefore art thou Romeo?/value /field /x ... Is there a reason why jingle events (like in the old version) are not included in the field list? Could a server shutdown be a push event? Otherwise the server should store the list of enabled clients in persistant storage. I don't know if that's something for the XEP to mention. Christian
Re: [Standards] Proposed XMPP Extension: Push
2.1 Push Service, 'is what' is extranous. 3.2 Business Rules paragraph 3, Care SHOULD be taken. 'ought' is too relaxed a word to use here, and it doesn't fit in with the SHOULDs used in paragraph 2. Fixed 5 Enabling Notifications, Note. This reiterates the assumption that the App Client is aware of the push service, and can interact with the push client on the host device, AND can interact with the XMPP server for the setup phase. To pull an 'evil' use case out of the hat, what about the case where the App Client can only communicate with the XMPP server via the push service? Do you have a specific example in mind for that case? The App Server should accept the push service token also via out-of-band mechanisms. 6 Disabling Notifications. The App Server should also provide an out-of-band mechanism for disabling push notifications. While I agree with these behaviours, is it a standards scope creep to introduce SHOULDs for App Servers? Speaking of out-of-band mechanisms, I notice that they're mentioned in section 9 Security (Wheel of Fortune types miss 'implementations') as a SHOULD, while in-band modifications are not recommended. Even though that's what is being described in sections 5 and 6 ;). The intent in the security section is to not allow changing in-band what content gets delivered via the push notifications, not the enabling/disabling of push services. Otherwise, a client could surreptitiously change the settings to include private information like full message bodies and contact JIDs when the user had previously chosen not to allow publishing that data. I'll add some clarifying language. Of course, the same sort of opportunities exist for bad clients already, such as adding to a user's roster without their consent. However, such things are generally noticeable by the user and correctable. Push services are more shielded from the user's notice and thus much easier to exploit. 7.1 Publish Errors The second paragraph describes how the server MAY consider the endpoint still active until a certain number of errors have been accumulated. I think there should also be language declaring that the server may also retry an errored-out endpoint at a later time, something like (as para3): A server MAY also retry a disabled JID and node combination after period of time (eg, 1 day) in a disabled state. +1, added Example 13 before this section has one too many 't's in its title. You'd confuse the poor Wheel of Fortune contestants with 'notifictation'. :) Fixed 8 Remote Disabling of Notifications. to stop accepting notifications _from_ the user's XMPP server Fixed New update of the XEP with the above changes has been sent to the editors. — Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 10 Mar 2015, lancest...@gmail.com wrote: 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. The problem with that approach is the the XMPP server needs to know if a device is online or not. It is the responsability of the XMPP to know which node to notify. To send a push notification to a device, it need a baseline and to compare with list of online devices. 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. We do not have a unique mapping between app and resource. For example, some client decide to use the same resource on all devices to be able to kick the existing session. Then, mapping the push to a resource is not enough, thus my device registry need. 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. It seems there is a case that is not handled is: publish to all devices on which the client is offline. 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. Well, I have made a a custom implementation of such service already and I know that I need to keep a list of registered devices. When the session opens and it send the push configuration packet, it give again its device id. That allow the server to tell that this specific device is online (and put it offline on disconnect). The most basic and useful use case is to have that baseline of offline / online devices to be able to send push to all offline devices. 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. Yes, I agree to cover those cases, but we need to have the case most of the developer expect to be covered answered as well. I think we can make that device registry (ability to pass a unique device ID on push enable in XMPP) optional. We will probably cover the use case that are not mobile in the same good way. But my feeling is that we need that registry if we want to cover the mobile case. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
Hello Christian, Sorry for the late reply: On 5 Mar 2015, christian...@rechenwerk.net wrote: 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. 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. If we agree on semantic that is a node reprensent a device-application, I am fine indeed. Having the ability to have a human name for the node, would be handy. One of your requirements is still not met: you have to know the resource to enable / disable push. [...] As I said earlier, I think the push module must check if arriving stanzas are addressed to a push-enabled device that's currently offline but *would be* the most available resource if it was still online. That's also bypassing the server's routing but in a more gentle way. 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 What about having the ability to list all your nodes (= devices) + the ability to delete a node as owner ? That would allow you to manage them as a users. I hope this helps, -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
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
