- From: Rahul Gupta <cxres@protonmail.com>
- Date: Tue, 21 Oct 2025 09:03:08 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org, "rory.hewitt@gmail.com" <rory.hewitt@gmail.com>
- Message-ID: <5rf0Y6nm_NB5p_pFo_4ZwPbiV9Hel5Wc5cgLbgbUPhUCaPkUqjPRdiBSiTlrLAx6SqgdiE78BQs35v_>
Hi Mark, On Tuesday, October 21st, 2025 at 3:04 AM, Mark Nottingham <mnot@mnot.net> wrote: > Hi Rahul, > > More than two states was explicitly considered in previous discussion; see: > https://github.com/httpwg/http-extensions/issues/3041 Thanks, but I was aware. I am not talking about tri-state on the wire. > > > I think the `?0` is superfluous and unnecessarily creates a tri-state design with two identical states out of three. > > > What are those states in your reading? There are three states (True, False, and unknown), but that maps well to a SF Boolean, and they are not identical. Exactly, T, F and X. F was previously just ignored (hence only two states), but now is explicitly defined. F with parameters is, in particular, meaningless. My concern, as Rory correctly captures, is that ultimately there are only two states being mapped on to three values. It's not wrong, but seems inefficient. > > Regarding Boolean vs. Dictionary: we're getting close to editorial matters -- how this is spelled on the wire doesn't have significant interoperability impact, and so we're largely talking about matters of taste here. The editors have made a judgement call on how to best express the semantics on the wire, and while folks can and should express their preferences, we don't want to risk this becoming design-by-committee. If our understanding of the requirements changes, I'm sure they'll adjust accordingly, but let's get that understanding first. > My proposals benefit from this draft becoming an RFC, and I am as eager as you for this I-D to progress. But at the same time, I also want the best possible design for my users. The editors have made changes to the I-D quite late in the day (because it is based on community feedback), and my understanding of requirements has evolved as a result of reading the new draft (and my learnings with Events Query), and hence my suggestion (which, I believe, has never been thought of in this context). Editors' considering these requirements/suggestion, even this late, would be much appreciated. > Cheers, > > > On 21 Oct 2025, at 7:58 am, Rahul Gupta cxres@protonmail.com wrote: > > > > Hello Incremental Authors and Enthusiasts, > > > > I was in favour of this draft, but the latest additions feel over-engineered. > > > > I think the `?0` is superfluous and unnecessarily creates a tri-state design with two identical states out of three. Especially so, if I am correct in presuming that parameters, which you have now explicitly allowed, would only apply to `?1`. My suggestion, in that case, would be to define Incremental as a Dictionary structured header instead. We could even define a key called value which is true by default. Saying "Incremental: value=?1" will be more verbose than "Incremental: ?1", but then "Incremental: prop=val" will be less verbose than "Incremental: ?1;prop=val". My intuition is that keys/parameters will become common (see next para). > > > > Coming to parameters, I might already have need for one. In implementing Events-Query, I have the need for servers to let clients know for how long they intend to send notifications, i.e. for how long do they intend to keep the response stream open. I am defining a custom header (actually a key called "duration" in a dictionary header) for this, but it could easily be a parameter of Incremental. More generally, I see incremental as somewhat analogous to caching with Incremental header conveying properties of about the “immediateness” of responses (things like duration, rate, and message transformation). Perhaps even an "Incremental-Control" header or "prefer: incremental-*=val" might be needed eventually? > > > > I am in favour of the proposal for an Incremental header, but at the same time I would request more discussion on the changes proposed in the -02 draft. I think there is room for a more elegant design. > > > > Best Regards, > > Rahul > > > > On Monday, October 20th, 2025 at 11:32 AM, internet-drafts@ietf.org internet-drafts@ietf.org wrote: > > > > > Internet-Draft draft-ietf-httpbis-incremental-02.txt is now available. It is a > > > work item of the HTTP (HTTPBIS) WG of the IETF. > > > > > > Title: Incremental HTTP Messages > > > Authors: 奥 一穂 (Kazuho Oku) > > > Tommy Pauly > > > Martin Thomson > > > Name: draft-ietf-httpbis-incremental-02.txt > > > Pages: 8 > > > Dates: 2025-10-19 > > > > > > Abstract: > > > > > > This document specifies the "Incremental" HTTP header field, which > > > instructs HTTP intermediaries to forward the HTTP message > > > incrementally. > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-httpbis-incremental/ > > > > > > There is also an HTML version available at: > > > https://www.ietf.org/archive/id/draft-ietf-httpbis-incremental-02.html > > > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-incremental-02 > > > > > > Internet-Drafts are also available by rsync at: > > > rsync.ietf.org::internet-drafts > > > <publickey - cxres@protonmail.com - 0x0CEC7748.asc> > > > -- > Mark Nottingham https://www.mnot.net/ BR/Rahul
Attachments
- application/pgp-keys attachment: publickey_-_cxres_protonmail.com_-_0x0CEC7748.asc
Received on Tuesday, 21 October 2025 09:03:18 UTC