Re: [Standards] Proposed XMPP Extension: Push
> On Mar 2, 2015, at 4:11 PM, Christian Ulrich > wrote: > > I started implementing an older version of the XEP [1] as an ejabberd > module. It's on github [2]. Currently I'm updating it to the new > version. Awesome and ^5! > My implementation includes the app server (currently only for Ubuntu > push), so the app server and the XMPP server are one instance. In order > to explain why I chose to do this I have to expand the scope a little. I understand why you'd want to set things up that way, but IMO this is not going to be tenable in the long run (explained below). > In case of Apple's, Google's and Microsoft's push services the app > server needs secret authorization data (certificate or secret key) to > send push notifications. So all client app instances need to register > with a central app server. In Ubuntu's push service [3] it's different. > The app server only needs the client's token and app_id for > authorization with ubuntu's server. I'd like to keep decentrality alive > where possible and in case of Ubuntu Push it is (at least in the > non-proprietary part). So I'd like to enable an arbitrary XMPP server > to send notifications to Ubuntu's push service. Given that you read the previous draft, I'm sure you appreciate that the topic of push comes with a very tangled knot of terminology, so please bear with me trying to explain my thoughts here. I think this approach is trying to decentralize the wrong aspect. The goal for the XEP is to let an XMPP server notify the App Servers for the user's apps when something interesting happens. What those apps do once notified is up to the app's purpose and implementation. Of course, the common case we expect is for those apps to in turn publish a push notification to the user's devices which have the app installed. But that is not actually required, and the fact that multiple apps may forward their notices via the same third-party mechanism to user devices is only coincidence. It comes down to that apps have purpose and will do different things. For example, say that I have two apps which both happen to use Ubuntu Push to send data to my device. One is a typical general IM client. The other is a video call app. The App Server for the video call app will only send data through Ubuntu Push when it receives a notification that includes Jingle data. The App Server for the general IM client might only send data through Ubuntu Push when chat message data was included in a notification, and it could also keep track of all the chat message notifications it received for me during a day and send me a summary email every evening of things I might have missed. Forcing those two apps to use the same App Server will not work, because their App Servers are different, even if they do some things in common. Even if they did the exact same things now, that is not guaranteed to be true forever. Apps change, gain and lose features. App Client and App Server necessarily need to be kept in sync. That said, what you do want to do to preserve decentralization is to let the user of an app run their own instance of the App Server. Once you allow that, it remains an implementation detail how the App Client discovers and registers with the App Server. > - apps that need to register with one central app server will know its > app server's hostname, but for an app supporting arbitrary app > servers there's no way of dicovering a hostname. So it should be able > to ask its xmpp server for a hostname serving a specific push service > type. Maybe something like this (up means ubuntu push): > >from='ro...@montague.net/orchard' > to='montague.net' > id='items3'> > node='urn:xmpp:push:0#up'/> > > >from='montague.net' > to='ro...@montague.net/orchard' > id='items3'> > node='urn:xmpp:push:0#up'> > > > So from my point above, in this case you would not search for an XMPP Push Service for Ubuntu Push. You would search for an XMPP Push Service for your app. This is an interesting idea to pursue. Perhaps we need to define how to create disco#info identities for this? Would this be a follow-up XEP or defined here? This needs more implementation experience to hammer out. > - arbitrary app servers require a unified registration process. The > draft suggests to use XEP-0077, that's ok I think, but then we need to > define what data the client has to provide. My suggestion for XEP-0077 > registration fields: > > * token (mandatory) > * app-id (optional, relevant for Ubuntu push) > * silent-push (optional, relevant for iOS and Android (I think)) > > I think an example for registration should be in the XEP. Given the above, this does need standardizing on a per-app basis. But that standardization should be done as part of the documentation of the app. > Moreover I'm missing an example for configuring the XMPP server part > regarding pri
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 3 Mar 2015, christian...@rechenwerk.net wrote: > On 03.03.2015 16:16, Mickaël Rémond wrote: >> Hello, >> >> On 3 Mar 2015,christian...@rechenwerk.net wrote: >> >>> Then the client app hands this information over to its xmpp server >>> using the enable-iq stanza so the xmpp server can publish push >>> notifications when the client app is not reachable. >> What does it mean ? >> Suppose I am using MyApp on iPad and iPhone, with the same JID and >> resource (not using them at the same time). >> What does not being reachable mean ? > > You are right, the draft does not define any events when push > notifications should be sent. The old version didn't either but it > defined three cases to consider when such an event occurs: [1]. > I don't think there needs to be a list of unreachable clients, the > server knows when a client is not reachable: Well, in our implementation, we found that the server has no proper way to know where to push unless you have a registry of client. Here is a very common example: I would like to receive push on my mobile, even if my desktop client is connected. In that situation, the message will not use offline and may not use stream management (session may have expired). This is also the case if you have N devices. You may want to receive push on all of them, or only a few of them. The only way to hint the server about this, is to have > In my (currently broken) ejabberd implementation I chose to send > notifications in the following cases: > > - Stream management stores a stanza for a push-enabled user > - mod_offline stores a message for a push-enabled user > > This has quite complicated implications, because message delivery > rules (https://tools.ietf.org/html/rfc6121#section-8.5.4) are quite > complicated. First try to write them down: > > One or multiple push notifications are published if [...] > This is probably incomplete and can be written in a better form. The > question is, do we want to define these events in the XEP or leave it > up to the server when to send a push notification? I have to think > more about this. Yes. I agree about the routing for online users. This is not easy but can be sorted out by server developers. However, I think we miss a level of routing for "offline resources". At some point, I was toying with the idea of having queues to deliver offline messages to all devices when they reconnect. This was solve in some way with archiving as a way to provide catchup. However, the problem is back with push, as the client "stay offline" and you want to notify them with push. Relying on offline means you miss a rule: Delivering to "offline devices" means you need to know the offline devices. >> Yes, but the list need to be managed. Supposed I had two devices and >> now handed over one to someone else. I need to be able to get the >> list of devices that serve a reference for XMPP server to trigger >> push notifications sending. And as a user, I need to be able to >> manually clean that list in some rare but important cases. >> >> Does it make sense ? > I'm not sure if I understand this. If you registered at the app server > with resource A and enabled push at your XMPP server for A, you can > unregister and disable later for A on another device. But maybe I got > you wrong. What case are you thinking of? The resource is not enough as the resource is transient (In XMPP a resource only has a meaning during the session duration). It means you never know if it will be reused. Some clients like web client even use random resources to accomodate with multiple tabs, but still should represent a single device in term of push. They also can be shared between multiple devices at different moment. My point is that I think using the resource to identify a client app is not the correct artefact. I hope this help :) -- Mickaël Rémond http://www.process-one.net/
[Standards] XEP-47 In-Band Bytestream: Why not headline messages?
Is there any particular reason that xep47 does not encourage the use of 'headline' type messages for ibb? They appear to be the ideal choice, as they are not stored offline. Also § 4. should mention xep184 "message delivery receipts" as alternative to amp. - Florian signature.asc Description: OpenPGP digital signature
[Standards] XEP-65 erratum in § 9.4
Hi everyone, I think I found an error in XEP-65: Section "9.4 Element" states that This element is always empty and has no defined attributes. when it should be This element's XML character data contains always the JID of the target and has no defined attributes. because '' is not an empty element. The Schema is correct (as far as I can tell). - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Proposed XMPP Extension: Push
On 03.03.2015 16:16, Mickaël Rémond wrote: Hello, On 3 Mar 2015,christian...@rechenwerk.net wrote: Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. What does it mean ? Suppose I am using MyApp on iPad and iPhone, with the same JID and resource (not using them at the same time). What does not being reachable mean ? You are right, the draft does not define any events when push notifications should be sent. The old version didn't either but it defined three cases to consider when such an event occurs: [1]. I don't think there needs to be a list of unreachable clients, the server knows when a client is not reachable: In my (currently broken) ejabberd implementation I chose to send notifications in the following cases: - Stream management stores a stanza for a push-enabled user - mod_offline stores a message for a push-enabled user This has quite complicated implications, because message delivery rules (https://tools.ietf.org/html/rfc6121#section-8.5.4) are quite complicated. First try to write them down: One or multiple push notifications are published if - a message addressed to a full jid arrives AND the user has push enabled for this full jid AND a session with this full jid is in stream management's zombie state - a message addressed to a full jid arrives AND there's no non-negative resource for that jid AND a push-enabled jid has a session with the highest priority AND this session is in stream management's zombie state - a message arrives addressed to a bare jid arrives AND the highest priority session is for a push-enabled jid AND this session is in stream management's zombie state - a message addressed to full or bare jid arrives AND there's no non-negative resource AND there's one (or multiple) push-enabled jids This is probably incomplete and can be written in a better form. The question is, do we want to define these events in the XEP or leave it up to the server when to send a push notification? I have to think more about this. Yes, but the list need to be managed. Supposed I had two devices and now handed over one to someone else. I need to be able to get the list of devices that serve a reference for XMPP server to trigger push notifications sending. And as a user, I need to be able to manually clean that list in some rare but important cases. Does it make sense ? I'm not sure if I understand this. If you registered at the app server with resource A and enabled push at your XMPP server for A, you can unregister and disable later for A on another device. But maybe I got you wrong. What case are you thinking of? Christian [1] https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md#where-to-deliver-notifications
Re: [Standards] help! reviews needed in XMPP WG
> On 2-Mar-2015, at 17:54, Peter Saint-Andre - &yet wrote: > > The IETF's XMPP Working Group is finishing up several documents, and reviews > from folks here would be very helpful in these late stages! > > The documents in question are: > > 1. XMPP Address Format - the fundamental definition of JIDs, now updated to > be forward-compatible with newer versions of Unicode (Working Group Last Call > ends March 12) > > http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ I’ve had a look over this and have a couple of comments: - In the ABNF describing resourcepart, 1023(resourcebyte) is referred to on the RHS, but the comment uses “opaquebyte”. - Table 2, example 15 appears to be valid by my reading of FreeformClass and OpaqueString. Further, the comment given for it being invalid refers to the resourcepart mapping to IdentifierClass, not FreeformClass/OpaqueString. - Not necessary, but it may be worth calling out Unicode Normalization Form C as what’s used, even though that’s specified in the the SASL prep module. Otherwise, it looks good to me! -bjc
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 3 Mar 2015, christian...@rechenwerk.net wrote: > Then the client app hands this information over to its xmpp > server using the enable-iq stanza so the xmpp server can publish push > notifications when the client app is not reachable. What does it mean ? Suppose I am using MyApp on iPad and iPhone, with the same JID and resource (not using them at the same time). What does not being reachable mean ? That's what I mean when I talk about a client registry that the XMPP server has to know about. To know that a client is not reachable or is missing, it need to have a list. It needs to be able to know for a given JID what are the "client app - device" tuple to be notified. I my view the app server cannot know that, because it does not know anything about the reachability. > I think one node representing multiple client apps is only possible if > all of these apps use the same push service type, e.g. all of them use > app ShinyApp on iOS. Otherwise the app server which maybe only > supports one push service type can't decide if a published > notification is for the client it is serving. > >> How can I see all my client app registered for push ? How can I >> manage that list ? > > from which side? I think each client app is responsible for its own > registration. Yes, but the list need to be managed. Supposed I had two devices and now handed over one to someone else. I need to be able to get the list of devices that serve a reference for XMPP server to trigger push notifications sending. And as a user, I need to be able to manually clean that list in some rare but important cases. Does it make sense ? -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Proposed XMPP Extension: Push
On Di, 2015-03-03 at 11:23 +0100, Mickaël Rémond wrote: > - Is app client really an instance of an application running on a > specific device ? > I thought at first the node what acting as a device registry, but, it > seems it does not as a node is defined as: "Each PubSub node is a > delivery target for the Push Service, which could represent multiple > devices for a single user." > So, basically, I am lost. What is acting as a Client App registry ? In my understanding an app client is the actual app running an iOS etc. The registration process is not defined (XEP-0077 is suggested). I think the idea is that there could be a proprietary app server that has nothing to do with XMPP which does the dispatching of push notifications to the push service (in the old draft version the push service, e.g. APNS, was called proprietary push service and packets sent to it were called proprietary push notifications, this makes it clearer). It needs the token and maybe additional information (at Ubuntu push an app-id) for that. The interface between app server and xmpp server is a pubsub node. The app server creates a node on a pubsub service (could be a third instance or a part of the app server) and subscribes to it. The information required for publishing on that node (hostname, node name, maybe a secret) are sent to the client app as a registration response. Then the client app hands this information over to its xmpp server using the enable-iq stanza so the xmpp server can publish push notifications when the client app is not reachable. I think one node representing multiple client apps is only possible if all of these apps use the same push service type, e.g. all of them use app ShinyApp on iOS. Otherwise the app server which maybe only supports one push service type can't decide if a published notification is for the client it is serving. > How can I see all my client app registered for push ? How can I > manage that list ? from which side? I think each client app is responsible for its own registration.
Re: [Standards] Proposed XMPP Extension: Push
Hello, On 2 Mar 2015, edi...@xmpp.org wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Push > > Abstract: This specification defines a way for an XMPP servers to > broadcast information for use in push notifications to mobile and > other devices. I have several questions regarding things that are not clear for me after first read: - Is app client really an instance of an application running on a specific device ? I thought at first the node what acting as a device registry, but, it seems it does not as a node is defined as: "Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user." So, basically, I am lost. What is acting as a Client App registry ? How can I see all my client app registered for push ? How can I manage that list ? - What is the role of node ? Do you have example on how they are used created and deleted ? - I could not see how that step is performed in the XEP: "The App Client sends the token to the App Server for later use." Sorry for the very basic questions and thanks for your feedback. -- Mickaël Rémond http://www.process-one.net/
