[Standards] XEP-0357 Push Notifications: Error handling and disabling notification

Ruslan Marchenko me at ruff.mobi
Tue Sep 10 17:41:31 UTC 2019


In the current specification 7.1 defines that xmpp server may 
unsubscribe user by processing publish errors implicitly, then 8 
mentions explicit unsubscribe notification from the push service back to 
the client.
The missing piece here is XMPP server notification to the client on 
error handling. Eg if push service was recycled and lost its state 
(token or whatever) it will likely reply with 
forbidden/not-found/not-available error. To follow 7.1 server should 
unsubscribe (but may keep) the push subscription. Which effectively is 
passive-disable. User however remains oblivious to this fact.
Here I think we need to to update 7.1 - if server decided to remove 
subscription as part of error handling or explicit server should send 
publish subscription removal on behalf of the unsubscribing node

<messagefrom='push-5.client.example'to='user at example.com/resource'><pubsubxmlns='http://jabber.org/protocol/pubsub'node='yxs32uqsflafdk3iuqo'><affiliationjid='user at example.com'affiliation='none'/></pubsub></message> 

to each subscribed full on the bare. Note here resource so the message 
is emitted on c2s directly to the client which has enabled push 
To avoid double notification (eg. server does not handle explicit 
affiliation message but as part of error handling does generate own 
affiliation removal) that could put as a MUST.

Clients should be able to handle this message as part of existing 
processing as per section 8. Happy to submit PR if authors agree.

diff --git a/xep-0357.xml b/xep-0357.xml
index 2071743d..f5a16de7 100644
--- a/xep-0357.xml
+++ b/xep-0357.xml
@@ -392,6 +392,16 @@
              <p>If a publish request is returned with an IQ-error, then 
the server SHOULD consider the particular JID and node combination to be 
              <p>However, a server MAY choose to keep a service enabled 
if the error is deemed recoverable or transient, until a sufficient 
number of errors have been received in a row.</p>
              <p>A server MAY retry an automatically disabled JID and 
node combination after a period of time (e.g. 1 day).</p>
+            <p>If server disables push subscription for particular node 
as part of error handling server MUST send removal of the 
publish-enabling affiliation as per Remote Disabling Notifications rules 
on behalf of the Push Service:</p>
+            <example caption='XMPP Server announces stop of push 
+<message from='push-5.client.example' to='user at example.com/resource'>
+  <pubsub xmlns='http://jabber.org/protocol/pubsub' 
+    <affiliation jid='user at example.com' affiliation='none' />
+  </pubsub>
+            <p>Server MUST also track remote Disabling Notifications 
messages in this case to avoid duplication of Remote Disabling 

          <section2 topic='Notification Delivery'>

So in this case the implementation is either dumb - and not reacting to 
any errors at all - leaving it to the client to handle, or is smart - 
and handles everything itself. No shades of grey.
And on error and consequent notification client will be able to recover 
by requesting a new token and

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190910/149d1e26/attachment.html>

More information about the Standards mailing list