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

inbox/push.xml

@@ -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>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 settings. Such operations SHOULD be done out-of-band to prevent privilege escalation.</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'>