Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV

Julian Reschke <julian.reschke@gmx.de> Thu, 24 October 2019 08:47 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C31200B8 for <dispatch@ietfa.amsl.com>; Thu, 24 Oct 2019 01:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvu6Tj9L3wk0 for <dispatch@ietfa.amsl.com>; Thu, 24 Oct 2019 01:47:57 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BD612006B for <dispatch@ietf.org>; Thu, 24 Oct 2019 01:47:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571906869; bh=iX7IXYmIVBRwt3IsQvzQAoWI3DbgZ2GG+OUhX51wIgs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V3GMZU3X4OAzKU9D++Oa9K/uI9AJjHqPTDCTnQaG+18Lvz7Sp4+ny0zr9dOEfXyJe KI/cbrB+AHf1BoppUNIbDDu+PSbN7yh56TmiOPc8GGadrhg/Rl9H2l9fCmpqx2tm+E OJfXmBK24J6+CmcRDLAGF7qSawIl5pptVQNkVsA4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.146.174]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ3t-1iSh3R3uNR-00WFJl; Thu, 24 Oct 2019 10:47:49 +0200
To: Michael Toomim <toomim@gmail.com>
Cc: Bron Gondwana <brong@fastmailteam.com>, dispatch@ietf.org, Seph Gentle <me@josephg.com>, Rafie Walker <slickytail.mc@gmail.com>
References: <290514e7-79ce-4852-bf05-a684e2e8d045@beta.fastmail.com> <DFC3797D-DA12-4470-9CBE-D7BD981DB6CE@gmail.com> <839ea4e5-db2d-8220-6058-93869a29c185@gmx.de> <82F33D05-D8BC-4F69-A198-677773F3427C@gmail.com> <11cabf2e-1550-53e5-60dd-7d1bdf65805a@gmx.de> <B1A18B63-B78A-4AE5-A164-A9CE0B13D326@gmail.com> <450f4113-7cdb-f65e-761d-9023e3d625bd@gmx.de> <CEECFFAD-ECAA-41FF-8817-4090DF694B27@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <a89ee52b-306b-60ca-35a6-e912c2a2eb82@gmx.de>
Date: Thu, 24 Oct 2019 10:47:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CEECFFAD-ECAA-41FF-8817-4090DF694B27@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:lD+0hIdJbkoofFckqUnRPG2yn+DjLKiGCHiaIiokUHIQGvqS6+a XgsT7fWaTCgD+YwsAodgbHsDMrJHh3nBvBvMRNMKOCVJrmaUVz3qRWOt1rzrYsaZBksvvP0 DFy1ueZgdFmPmI+bPaaq2i3WZ9EgCgyM6cYyXTEsXwnioHE41l2SopYbu24nxw5agtEU903 Wqu4avgTcfYmV68Mu/cYg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dFgHFlpP/40=:KKZZc4LfIgp+eQA27rfPob 3F4aF4XhmhWlIXmtISfZr8hiHtDtYh77XF/T+Dm7rOKSZLC4w4UAphcL1Vtv693TpR1F2dkwD JvYRgaX9ns/x6gowHvV7R1j+uqFxCkMkSXJpA3hTmSpLvFVK7SmZiEfLNM10sNlH2Wms46Zgs R/BLRQO6La67MOiBIHj8Hfx8idD063I6PsKmPQSavIe3lknfcS0s+pC7GJGl+djU+T0I2bC/3 F/dGGm0a15x584vQXKgDDUWM8ln8mQqVOmdst8Q+qWlaM5TRHO7LP+48Q6j28RV9GeIhHhBIh 2k425WDnzNPuD+OrfyiEtNmyfIYT+jaCQkwEbgC9EW/ZLO+vmv92ogSx6r49lHqA8y2R15z2y uEZS+8D7P/IVRTBp8zucPiIu15Iz8xhfhBmkXy+38mYMdupBMCGU/WmfR52dBu2G30MWTWZ51 r7I7l+ikEYJClQCsKB/nMLG7UvrCs+RpuFuNGbf9XAjxcn3O1tP0qvWUp/bkYk7DCvWbuKO5E VjES2O02l3yII4DCTShbhwDieQ4BnQJB1t841d3wWdHblsppR1jlqg+7tDP/8AdPA2K7vv2w2 JaJf0s4cpD3XUYasKoh1rxdIGtUM/ampuD8lDIRBHPv//2ZjQCZhMILOfaqdYpYP47Wx+HpqN 51JxnOcRF42xmJk4BpcL7D12snDDFO3/hxwMUbiFq0JZNELZVoU94sERSkfixxLFWqKX1fNtt i4qaExL1j0w4001ZXFuEBFQpP1hzeg58z2PBf7oXJWQfA7n/3JcVT3/Za5vYNxlXTsZ526Mrl Gp1L0ZObqWIn8h3QXquYbS2Xm3HGr9f3Z27fHADmqQ3+uHY3gOce+J4qjBrC+KLsteA5hgWqe MMg7/5JukI0WbIFIJ6n33kzwCUXEAsJ/HfrfHywMmIPvHiHnKov/oicQzKZO5TyesAl8C6UWd bcF4vTxL+kMeqjM/Cuawu26zJRwsY4Y+seRh/wEMpr2OcoaqkuobOSwUp6LwghywVkOuMdfGK ylKUJdyUl/+bqSalLxm53QWwNvzg90XZ51AMKVzK31brwOa4wEw2UIfREOUzN+XqDWbCxmOSi EwUAuSHS63o9F10IInpYosze3C0Ty4JhIJ0YSsIKvU4VvqVkSYigWedTJ6tI3t6x2eHGHQitz Lq4RlDfvEczyce9qPPe/YH3IweSUqVU0W70ge/aSrCQKMPhFgl0/FK04kQqfXSnwD9pogRCFi MoJlEXyrDredekO1ET+0tnkBoq9d+y/40hgRR3GZ4xx3icFDAy78//zWj8lY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/wC8O3aK0JVFrvTNGHPHtjqsAhuk>
Subject: Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 08:48:00 -0000

On 24.10.2019 10:38, Michael Toomim wrote:
>> Julian:
>>> Michael:
>>>> Julian:
>>>>> My gut feeling is that you should define a media type that handles this
>>>>> kind of continueing-to-update content, and then just use Accept: to tell
>>>>> the server...
>>>
>>> Thank you, Julian!  Our spec works for any media type.  You can apply it to existing HTML, JSON, or images.  It allows CDNs to get live updates via patches, of the existing content they distribute.  CDNs will be able to support dynamic content, not just static content.
>>
>> Where's the spec?
>
> We're still editing it for publication, but our working area is here:
>
>     https://github.com/braid-work/braid-spec

Hmm. I think you'll need to work on the proper labeling of things. Even
if the client opts into this format, the Content-Type will still have to
describe the overall payload.

You're basically inventing a new payload format that can wrap multiple
payloads. But then we already have multipart/*; it really seems to me
you should be using that instead.

Best regards, Julian