moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

proto-XEP Push v0.0.2 - Adjust some wording and typo fixes (lance)

This commit is contained in:
Matthew A. Miller 2015-03-10 10:48:23 -06:00
parent 03e060cf65
commit 246bcbd46e
1 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
inbox/push.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Push</title>
<abstract>This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices.</abstract>
<abstract>This specification defines a way for an XMPP servers to deliver information for use in push notifications to mobile and other devices.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
@ -29,6 +29,12 @@
<email>lancestout@gmail.com</email>
<jid>lance@lance.im</jid>
</author>
<revision>
<version>0.0.2</version>
<date>2015-03-10</date>
<initials>lance</initials>
<remark><p>Adjust some wording and typo fixes.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2015-02-23</date>
@ -83,7 +89,7 @@
</di>
<di>
<dt>Push Service</dt>
<dd>The push service is what ferries notifications from the App Server to the User Agent. How it does so is often proprietary and vendor/platform dependent.</dd>
<dd>The push service ferries notifications from the App Server to the User Agent. How it does so is often proprietary and vendor/platform dependent.</dd>
</di>
</dl>
@ -153,7 +159,7 @@
</section1>
<section1 topic='XMPP Push Service'>
<p>An XMPP Push Service is a PubSub service as defined by the XMPP &xep0060; extension. The functional difference between a Push Service and a generic pubsub service is that a Push Service will generally summarize and re-broadcast published content via non-XMPP mechanisms.</p>
<p>An XMPP Push Service is a PubSub service as defined by the XMPP &xep0060; extension. The functional difference between a Push Service and a generic pubsub service is that a Push Service will generally summarize and forward published content via non-XMPP mechanisms.</p>
<p class='em'>Note: a Push Service is provided by a specific client application as part of the App Server. A user's XMPP server will typically <em>not</em> act as a Push Service itself, but will instead publish to the Push Services for the user's client applications.</p>
<section2 topic='Recommended Defaults'>
@ -166,7 +172,7 @@
<section2 topic='Business Rules'>
<p>Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user.</p>
<p>In order to prevent information leaks, each node SHOULD be configured with a 'whitelist' access model so that only trusted entities are able to view or subscribe to published notifications. Furthermore, the 'publish-only' affiliation SHOULD be used to allow acceptable entities (such as the user's bare JID) to publish to the node to trigger notifications.</p>
<p>Care ought to be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from bare JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see <link url='#publish-options'>Enabling Notifications</link>).</p>
<p>Care SHOULD be taken to ensure that publish requests are coming from the user's server and not from other third-party client applications using the full JID of a user. A Push Service MAY opt to only accept or further process publish requests from bare JIDs to ensure that only a user's server is able to publish, but it SHOULD instead use publish options with credentials shared only with the user's server (see <link url='#publish-options'>Enabling Notifications</link>).</p>
</section2>
</section1>
@ -355,6 +361,7 @@
<section2 topic='Publish Errors'>
<p>If a publish request is returned with an IQ-error, then the server SHOULD consider the particular JID and node combination to be disabled.</p>
<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>
</section2>
<section2 topic='Notification Delivery'>
@ -398,8 +405,8 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Push notifications require routing private information, such as message bodies, through third parties. As such, server implmentations SHOULD allow users to limit the information sent via push notifications.</p>
<p>It is NOT RECOMMENDED to allow in-band modification of push notification settings. Such operations SHOULD be done out-of-band to prevent privilege escalation.</p>
<p>Push notifications require routing private information, such as message bodies, through third parties. As such, servers SHOULD allow users to limit the information sent via push notifications.</p>
<p>It is NOT RECOMMENDED to allow in-band modification of push notification content settings. Such operations SHOULD be done out-of-band to prevent privilege escalation.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>