On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote:
On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote:And look at making the push protocol have a confirmation step:I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.)I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step.
Tero - are you satisfied with this response? The fact that RFC8030 didn't see the need to add a confirmation step suggests that not having a confirmation step in JMAP isn't wildly different from current practice or current IETF standards, and Neil's justification that it makes setup less reliable for common push services seems reasonable.
If we need to beef up the language that the server MUST disable the push channel if the endpoint URL doesn't reply correctly, and maybe even a suggestion that the server rate limit individual authenticated users and similarly detect weird behaviour and limit it. It would be great to solve this with clear advice to server implementations on how to not become a DOS amplifier rather than hobble the protocol.
Cheers,
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
brong@xxxxxxxxxxxxxxxx
