Re: I-D Action: draft-ietf-httpbis-incremental-02.txt

Hi Rahul,

More than two states was explicitly considered in previous discussion; see:
  https://github.com/httpwg/http-extensions/issues/3041

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

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.

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/

Received on Monday, 20 October 2025 21:32:15 UTC