Re: [dispatch] Proposal for Per Resource Events Protocol

[Kévin Dunglas <[e-mail]>]

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.html

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 AM Rahul Gupta <cxres=
[e-mail]> 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, [e-mail] <
> [e-mail]> wrote:
>
>
> > Rahul Gupta cxres=[e-mail] 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 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…
>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>