[dispatch] =?UTF-8?Q?Re:__Potential_incoming_work:_web_push_for_IMAP, _Cal?= DAV and CardDAV

It looks like the conversation went a long way down this path, which by my reading is "ask the server to maintain a long running connection and keep pushing updates down it" which is a slightly different use-case from the push proposals I was making, which are:

 * Client establishes a relationship with a third party push server (potentially via some platform specific, highly efficient protocol - e.g. APNs <https://en.wikipedia.org/wiki/Apple_Push_Notification_service> or GCM <https://en.wikipedia.org/wiki/Google_Cloud_Messaging>)
 * Client requests server inform the third party push server when there are changes.
 * Third party push server passes details down to client, which can then request updates from the server without having to hold a connection open or poll.

This is a general pattern which 1st party clients frequently use (including ours at Fastmail) but which doesn't have a general solution, so my impression of the work required there is defining a standard for how to request the server make that push to a third party, and what gets included in that push.

This other work of having the server hold a connection open is also interesting and potentially useful, it's just not exactly what I was suggesting!

Cheers,

Bron.

On Wed, Oct 23, 2019, at 16:27, Michael Toomim wrote:
> Hi Bron! The work on the Braid HTTP extension also provides a "web push". We are also trying to find a general approach.
> 
> The current design allows clients to specify a "Subscribe" header in the GET request, which tells the server to keep the connection open and stream all updates to the resource, as they happen. We will be publishing a new draft within the next week or two.
> 
>> On Oct 22, 2019, at 9:08 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
>> 
>> There's a couple of interesting things that have been going on in different places that I'm working on trying to get aligned and to find a home for at the IETF:
>> 
>> Web push for IMAP servers here:
>> 
>> https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md
>> 
>> Web push for CalDAV and CardDAV servers here:
>> 
>> https://datatracker.ietf.org/doc/draft-gajda-dav-push/
>> 
>> (there's a more recent version in the CalConnect private repositories - we haven't been pushing it just yet because the CALEXT group is already pretty busy, and we're not sure if it belongs there or in another group).
>> 
>> And of course JMAP already has a web push built in with the push subscription object:
>> 
>> https://tools.ietf.org/html/rfc8620#section-7
>> 
>> Anyway, I'm not sure if this is ripe for discussion at Singapore, or indeed if we've missed the deadlines for a BOF, but I figured if I post here I might see if there's any others working on similar things and if we could pull everyone together to join forces and make sure all the different push mechanisms work similarly.
>> 
>> Cheers,
>> 
>> Bron.
>> 
>> --
>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>> brong@fastmailteam.com
>> 
>> 
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong@fastmailteam.com