> 2.1 Push Service, 'is what' is extranous. > > 3.2 Business Rules paragraph 3, Care SHOULD be taken. 'ought' is too relaxed > a word to use here, and it doesn't fit in with the SHOULDs used in paragraph > 2.
Fixed > 5 Enabling Notifications, Note. This reiterates the assumption that the > App Client is aware of the push service, and can interact with the push > client on the host device, AND can interact with the XMPP server for the > setup phase. To pull an 'evil' use case out of the hat, what about the case > where the App Client can only communicate with the XMPP server via the push > service? Do you have a specific example in mind for that case? > The App Server should accept the push service token also via out-of-band > mechanisms. > 6 Disabling Notifications. The App Server should also provide an out-of-band > mechanism for disabling push notifications. While I agree with these behaviours, is it a standards scope creep to introduce SHOULDs for App Servers? > Speaking of out-of-band mechanisms, I notice that they're mentioned in > section 9 Security (Wheel of Fortune types miss 'implementations') as a > SHOULD, while in-band modifications are not recommended. Even though that's > what is being described in sections 5 and 6 ;). The intent in the security section is to not allow changing in-band what content gets delivered via the push notifications, not the enabling/disabling of push services. Otherwise, a client could surreptitiously change the settings to include private information like full message bodies and contact JIDs when the user had previously chosen not to allow publishing that data. I'll add some clarifying language. Of course, the same sort of opportunities exist for bad clients already, such as adding to a user's roster without their consent. However, such things are generally noticeable by the user and correctable. Push services are more shielded from the user's notice and thus much easier to exploit. > 7.1 Publish Errors > > The second paragraph describes how the server MAY consider the endpoint still > active until a certain number of errors have been accumulated. I think there > should also be language declaring that the server may also retry an > errored-out endpoint at a later time, something like (as para3): > > A server MAY also retry a disabled JID and node combination after > period of time (eg, 1 day) in a disabled state. +1, added > Example 13 before this section has one too many 't's in its title. You'd > confuse the poor Wheel of Fortune contestants with 'notifictation'. :) Fixed > 8 Remote Disabling of Notifications. "to stop accepting notifications _from_ > the user's XMPP server" Fixed New update of the XEP with the above changes has been sent to the editors. — Lance
smime.p7s
Description: S/MIME cryptographic signature
