From kevin@dunglas.fr Fri Nov 3 02:35:09 2023 Return-Path: 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 86D3FC15C2AC for ; Fri, 3 Nov 2023 02:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunglas-fr.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRCVO9gj1XNr for ; Fri, 3 Nov 2023 02:35:04 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07D2C1519AB for ; Fri, 3 Nov 2023 02:35:04 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-6754b4091b6so10425746d6.3 for ; Fri, 03 Nov 2023 02:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunglas-fr.20230601.gappssmtp.com; s=20230601; t=1699004103; x=1699608903; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dVqodY2hdfPx4PSYlxR+gcCaaiOyZXS41FBwK9oW3rs=; b=RZ5f2emgrTwg+W+r5vzw+FvCsbbXs0HeBbzYhJuzDorHpmjXNfIgdoAsq5KZlpml47 ECrWPyjZJo7vER0dgPVSFOptJVLf0po7jHC/qPUdczKTbiTN7XfPMhh170dQI3DgGXSl TveHU4ZY9a9S6Ymsu2GDjzpuY0WlD+u0IuADUSOXIYEIbEjivA20qfx1E5PINEfV9GR5 bmoU40BPTT4nE+T590BvloESbDGJs9EOHcxexUfbIvZG9LerJR+MJNtOTMgsMQde/lh4 Q+G7IodmxxpzcrPZs5U8ZuDqbQ1WfCNLXjq4uOC28/WLbJ7clM6XAyWm0dQWMj3Qg6VA UNtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699004103; x=1699608903; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dVqodY2hdfPx4PSYlxR+gcCaaiOyZXS41FBwK9oW3rs=; b=hrlLwgBzFs0lx6SMwdcLwz2zc0Gbjqt2kplmcWwJamF8cDmloRJEqz5AKZE/XU4bR/ DFRBqsGVfgnt0mFjUG8KxX02D0zXbEI8TGiNDNxZ75PgzFtjw75/KcnOTsPIcBZimgmS K7LmKK++sxj7yY95UdlxUjDIKCz7Lth9GnNm7eat2tUvGYp8s+l4jjz3d4yISlxYx+uO MpfJSZXbdyM1EecXY/MHvNRkjF4vc5olGo4W0W1bRlfRO0C8RZZvC/YXgfXdJUWQRv7N /zDTSway8SuCGq6zWeo6i9UPA4uikikTvENm7Zff65cHGHavm9sabk6va/mk9l9mmC1n lgNw== X-Gm-Message-State: AOJu0Yy6BYY0+mudmPBXYT2Ju0N8TxtyRXgVKltez2gBtvsd7dyiAY2J ovf4KJs/g3Piio882Nw9SUWUAACaOtWxbyskfkGDfw== X-Google-Smtp-Source: AGHT+IFFX04FZyS9bHiPPByqU8sO8OLBX3NvmcpJIRxN78sqMX9y+jn+OWmGsEm/xWXTxulAAOmQfu8wvy0Itsxy0cw= X-Received: by 2002:a05:6214:1316:b0:656:2d03:a4be with SMTP id pn22-20020a056214131600b006562d03a4bemr27382745qvb.40.1699004103131; Fri, 03 Nov 2023 02:35:03 -0700 (PDT) MIME-Version: 1.0 References: <87lebuz6nh.fsf@hobgoblin.ariadne.com> <8b2c6d87-3d89-31fe-9338-c429b3bc6e8c@gmail.com> In-Reply-To: <8b2c6d87-3d89-31fe-9338-c429b3bc6e8c@gmail.com> From: =?UTF-8?Q?K=C3=A9vin_Dunglas?= Date: Fri, 3 Nov 2023 10:34:52 +0100 Message-ID: To: Michael Toomim Cc: Rahul Gupta , dispatch@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000000a1ac906093c38f2" Archived-At: Subject: Re: [dispatch] Proposal for Per Resource Events Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2023 09:35:09 -0000 --0000000000000a1ac906093c38f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, Many thanks to you and Rahul for pushing this topic forward. Standardization of resource updates is much needed. Unfortunately, I won't be able to make it to Prague. I'm not very familiar with IETF meetings, but if it's possible to participate remotely in the discussion, I'd be delighted to join you and present our work on Mercure. I'll also send an email to the HTTPbis list to summarize the differences and similarities between the three proposals, and show how these approaches can be complementary. Cheers, On Thu, Nov 2, 2023 at 11:11=E2=80=AFPM Michael Toomim w= rote: > Hi Kevin! > > I am grateful for your continued work on HTTP Subscriptions, and would be > very happy to help make these approaches (Mercure, PREP, Braid-HTTP) work > together, ideally in a unification that meets everyone's needs. It also > might be educational to implement a babelfish that lets the protocols tal= k > to one another by translating their messages. > > Since this conversation began, the chairs have suggested moving it to > HTTPbis (cc'd) from Dispatch. So I am cc'ing HTTPbis on this email, and > Rahul and I will be presenting PREP and Braid-HTTP at the HTTPbis meeting > next Thursday or Friday in Prague: > https://datatracker.ietf.org/doc/agenda-118-httpbis/ Maybe you would like > to tune in and comment? > (I will still present the idea of a new State Sync Working Group in > Dispatch on Monday.) > > At this meeting, I am calling for HTTPbis to adopt work on > Subscriptions=E2=80=94something to implement the core functionality that = we all > want with Mercure, PREP, and Braid. The resulting specification could end > up looking like Mercure, PREP, Braid, or something else. See > https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0120.html > > Cheers! > > Michael > On 11/2/23 10:13 AM, K=C3=A9vin Dunglas wrote: > > Hi Rahul, > > Our team has been working for several years on a very similar protocol > called Mercure: > > * Up-to-date spec: https://mercure.rocks/spec > * Older I-D: https://www.ietf.org/archive/id/draft-dunglas-mercure-06.htm= l > > The main difference is that we basically "ported" and extended the WebSub > protocol (https://www.w3.org/TR/websub/) ro work over SSE. > This approach has the benefits of working everywhere (even in HTTP/1.1 > contexts), to be easy to make compatible with environments not able to > maintain persistent connections (PHP, serverless, CGI etc) and to be very > easy to implement (no code nor SDK required client-side). > > Also, Mercure is already implemented and used in the wild by a lot of > existing apps, and free software tools (including the popular Symfony web > framework): https://mercure.rocks/spec#implementation-status > It also a very dynamic community on GitHub: > https://github.com/dunglas/mercure > > Our previous attempt to "promote" the spec as a RFC didn't get much > feedback ( > https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0020.html), > so we are in the process of submitting the spec as independent submission= . > > I'm glad to see that there seems to be a desire to standardize something > on this subject (PREP, Braid...). > > Would you and Michael be available to discuss how both specs can work > together? > > Best regards, > > > On Mon, Oct 23, 2023 at 7:30=E2=80=AFAM Rahul Gupta 40protonmail.com@dmarc.ietf.org> wrote: > >> Dale, >> >> Thank you (again!) for your interest and feedback. See responses >> interleaved! >> >> BR/Rahul >> >> ------- Original Message ------- >> On Monday, October 23rd, 2023 at 3:00 AM, worley@ariadne.com < >> worley@ariadne.com> wrote: >> >> >> > Rahul Gupta cxres=3D40protonmail.com@dmarc.ietf.org writes: >> > >> > > I have submitted my proposal for the Per Resource Events >> > > https://github.com/CxRes/prep Protocol as an >> > > Internet-Draft >> > > >> https://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource-events= / >> > >> > >> > A few bits: >> > >> > - Section 5.1 seems to introduce "event fields" but it doesn't provide >> > any description of what they are. This is particularly treacherous >> > because the use of "fields" in "event fields" evidently does not mean >> > exactly the same thing as "header fields" (as event fields aren't >> > header fields), but are likely to have the same names as header >> > fields, and event fields have values in some (different) way, which >> > values have similar semantics to the corresponding header field >> > values. >> >> I do explicitly define "event fields" in 3.5 Terminology. >> >> Would you like me to expand on it or put it in a different manner? Or >> would you like a more explicit link back on first use in each major sect= ion? >> >> > >> > - A few fairly complete examples would help. In particular, I think >> > that the concept is that PREP is started by the client sending a GET >> > containing the appropriate headers, then the server sends the header >> > of a response containing the appropriate headers, then the first part >> > of a multipart body and the first body part (containing the current >> > state of the resource), then a multipart divider ... then possibly a >> > delay ... then a second body part (containing the first update), then >> > a multipart divider ... then possibly a delay ... But I don't think >> > this is stated clearly near the beginning, nor is a complete example >> > given. >> >> Given that you seem to describe PREP so well, it feels like the situatio= n >> is pretty good ;). There is also a cultural aspect here, I am still >> relatively unfamiliar with the expectations of IETF/RFC readers. So, let= me >> ask you how you might approach this=E2=80=A6 >> >> 1. Would you like a complete example, say as an unnumbered section at th= e >> end (linked from the introduction)? >> 2. Do you want me to expand "1.2 How it works" a bit? >> >> > >> > - Do you have an initial application? It always helps to get traction >> > if you have an existing need that can be satisfied, or better, two or >> > three. >> >> There is interest in Solid community to implement this (This work as I >> stated in my original post came about because of my work on Solid >> Notifications Protocol. The community has a real desire in Solid for a >> simpler notifications system). There is a (public) expression of interes= t >> from a private server developer and discussions with open source server >> implementers. This was held back in part because I only last night relea= sed >> the companion specification that links Solid and PREP, conveniently call= ed >> Solid-PREP . So >> implementations are likely to come online more in time for IETF 119, >> unfortunately. >> >> > >> > - There's some sort of index at the end, but it's difficult to read, a= nd >> > it appears to only be a list of places where specified terms appear. >> > This doesn't add much value, since every tool a person might use to >> > look at draft-gupta-httpbis-per-resource-events has a string-search >> > capability. >> > >> >> This index is auto generated by RFC tooling (I only mark words that I >> want indexed, because I want them recorded as significant terms in the >> XML). I find the generated index unintuitive too. Please complain loudly= :P >> to the RFC tooling folks as this affects every I-D! >> >> > Dale >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listin= fo/dispatch > > --0000000000000a1ac906093c38f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,

Many thanks to you = and Rahul for pushing this topic forward. Standardization of resource updat= es is much needed.

Unfortunately, I won't be able to make it to = Prague. I'm not very familiar with IETF meetings, but if it's possi= ble to participate remotely in the discussion, I'd be delighted to join= you and present our work on Mercure.

I'll also send an email to= the HTTPbis list to summarize the differences and similarities between the= three proposals, and show how these approaches can be complementary.
=

Cheers,


On Thu, = Nov 2, 2023 at 11:11=E2=80=AFPM Michael Toomim <toomim@gmail.com> wrote:
=20 =20 =20

Hi Kevin!

I am grateful for your continued work on HTTP Subscriptions, and would be very happy to help make these approaches (Mercure, PREP, Braid-HTTP) work together, ideally in a unification that meets everyone's needs. It also might be educational to implement a babelfish that lets the protocols talk to one another by translating their messages.

Since this conversation began, the chairs have suggested moving it to HTTPbis (cc'd) from Dispatch. So I am cc'ing HTTPbis on= this email, and Rahul and I will be presenting PREP and Braid-HTTP at the HTTPbis meeting next Thursday or Friday in Prague: https://datatracker.ietf.org/doc/agenda-118-httpbis/ Mayb= e you would like to tune in and comment?

(I will still present the idea of a new State Sync Working Group in Dispatch on Monday.)

At this meeting, I am calling for HTTPbis to adopt work on Subscriptions=E2=80=94something to implement the core functionality t= hat we all want with Mercure, PREP, and Braid. The resulting specification could end up looking like Mercure, PREP, Braid, or something else. See https://lists.w3.org/Archives/Public/ietf-h= ttp-wg/2023OctDec/0120.html

Cheers!

Michael

On 11/2/23 10:13 AM, K=C3=A9vin Dunglas wrote:
=20
Hi Rahul,

Our team has been working for several years on a very similar protocol called Mercure:

* Up-to-date spec: https://mercure.rocks/spec

The main difference is that we basically "ported" = and extended the WebSub protocol (https://www.w3.org/TR/websub/) ro work over SSE.
This approach has the benefits of working everywhere (even in HTTP/1.1 contexts), to be easy to make compatible with environments not able to maintain persistent connections (PHP, serverless, CGI etc) and to be very easy to implement (no code nor SDK required client-side).

Also, Mercure is already implemented and used in the wild by a lot of existing apps, and free software tools (including the popular Symfony web framework): https://merc= ure.rocks/spec#implementation-status
It also a very dynamic community on GitHub: https://github.com/dunglas= /mercure

Our previous attempt to "promote" the spec as a RF= C didn't get much feedback (https:/= /lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0020.html), so we are in the process of submitting the spec as independent submission.

I'm glad to see that there seems to be a desire to standardize something on this subject (PREP, Braid...).

Would you and Michael be available to discuss how both specs can work together?

Best regards,


On Mon, Oct 23, 2023 at 7:30=E2=80=AFAM Rahul Gupta <cxres=3D40protonmail.com@dmarc.ietf.o= rg> wrote:
Dale,

Thank you (again!) for your interest and feedback. See responses interleaved!

BR/Rahul

------- Original Message -------
On Monday, October 23rd, 2023 at 3:00 AM, worley@ariadne.com <wor= ley@ariadne.com> wrote:


> Rahul Gupta cxres=3D40protonmail.com@dmarc.ietf.org writes:
>
> > I have submitted my proposal for the Per Resource Events
> > https://github.com/CxRes/prep Protocol as an
> > Internet-Draft
> > https= ://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource-events/ >
>
> A few bits:
>
> - Section 5.1 seems to introduce "event fields" = but it doesn't provide
> any description of what they are. This is particularly treacherous
> because the use of "fields" in "event field= s" evidently does not mean
> exactly the same thing as "header fields" (as ev= ent fields aren't
> header fields), but are likely to have the same names as header
> fields, and event fields have values in some (different) way, which
> values have similar semantics to the corresponding header field
> values.

I do explicitly define "event fields" in 3.5 Terminol= ogy.

Would you like me to expand on it or put it in a different manner? Or would you like a more explicit link back on first use in each major section?

>
> - A few fairly complete examples would help. In particular, I think
> that the concept is that PREP is started by the client sending a GET
> containing the appropriate headers, then the server sends the header
> of a response containing the appropriate headers, then the first part
> of a multipart body and the first body part (containing the current
> state of the resource), then a multipart divider ... then possibly a
> delay ... then a second body part (containing the first update), then
> a multipart divider ... then possibly a delay ... But I don't think
> this is stated clearly near the beginning, nor is a complete example
> given.

Given that you seem to describe PREP so well, it feels like the situation is pretty good ;). There is also a cultural aspect here, I am still relatively unfamiliar with the expectations of IETF/RFC readers. So, let me ask you how you might approach this=E2=80=A6

1. Would you like a complete example, say as an unnumbered section at the end (linked from the introduction)?
2. Do you want me to expand "1.2 How it works" a bit?=

>
> - Do you have an initial application? It always helps to get traction
> if you have an existing need that can be satisfied, or better, two or
> three.

There is interest in Solid community to implement this (This work as I stated in my original post came about because of my work on Solid Notifications Protocol. The community has a real desire in Solid for a simpler notifications system). There is a (public) expression of interest from a private server developer and discussions with open source server implementers. This was held back in part because I only last night released the companion specification that links Solid and PREP, conveniently called Solid-PREP <https://cxres.github.io/solid-prep/protocol/>. So implementations are likely to come online more in time for IETF 119, unfortunately.

>
> - There's some sort of index at the end, but it's difficult to read, and
> it appears to only be a list of places where specified terms appear.
> This doesn't add much value, since every tool a person might use to
> look at draft-gupta-httpbis-per-resource-events has a string-search
> capability.
>

This index is auto generated by RFC tooling (I only mark words that I want indexed, because I want them recorded as significant terms in the XML). I find the generated index unintuitive too. Please complain loudly :P to the RFC tooling folks as this affects every I-D!

> Dale
>
> _______________________________________________
> dispatch mailing list
> dis= patch@ietf.org
> https://www.ietf.org/mailman/listinfo= /dispatch_______________________________________________
dispatch mailing list
dispatch= @ietf.org
https://www.ietf.org/mailman/listinfo/dis= patch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000a1ac906093c38f2--