From 246bcbd46ef7d917605e846c3a2ac59ef1fd8042 Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Tue, 10 Mar 2015 10:48:23 -0600 Subject: [PATCH] proto-XEP Push v0.0.2 - Adjust some wording and typo fixes (lance) --- inbox/push.xml | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/inbox/push.xml b/inbox/push.xml index cfc512d6..1215788c 100644 --- a/inbox/push.xml +++ b/inbox/push.xml @@ -7,7 +7,7 @@
Push - This specification defines a way for an XMPP servers to broadcast information for use in push notifications to mobile and other devices. + This specification defines a way for an XMPP servers to deliver information for use in push notifications to mobile and other devices. &LEGALNOTICE; xxxx ProtoXEP @@ -29,6 +29,12 @@ lancestout@gmail.com lance@lance.im + + 0.0.2 + 2015-03-10 + lance +

Adjust some wording and typo fixes.

+
0.0.1 2015-02-23 @@ -83,7 +89,7 @@
Push Service
-
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.
+
The push service ferries notifications from the App Server to the User Agent. How it does so is often proprietary and vendor/platform dependent.
@@ -153,7 +159,7 @@ -

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.

+

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.

Note: a Push Service is provided by a specific client application as part of the App Server. A user's XMPP server will typically not act as a Push Service itself, but will instead publish to the Push Services for the user's client applications.

@@ -166,7 +172,7 @@

Each PubSub node is a delivery target for the Push Service, which could represent multiple devices for a single user.

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.

-

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 Enabling Notifications).

+

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 Enabling Notifications).

@@ -355,6 +361,7 @@

If a publish request is returned with an IQ-error, then the server SHOULD consider the particular JID and node combination to be disabled.

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.

+

A server MAY retry an automatically disabled JID and node combination after a period of time (e.g. 1 day).

@@ -398,8 +405,8 @@ -

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.

-

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.

+

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.

+

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.