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

Hi Martin,

I just want to clear the air before engaging in any repartee that what I am categorically not asking for is the inclusion of a specific parameter or key!

The question I have for you is bike-shedding and completely academic, so ignore me if you wish!

Let me build on your example: Help me understand why Incremental: buffer-delay=50 is any different from saying Incremental: ?1;buffer-delay=50 ? The intermediary that does not understand buffer-delay as a key can still ignore it. Whereas the presence of Incremental header is sufficient to indicate "minimally" buffer (or add an implicit or explicit "value" key like I suggested previously, but even that is redundant). AFAICT, both designs allow progressive comprehension. Heck, if you want to confuse everyone, you can even allow both designs to co-exist (Again, not advocating that you actually do it).

BR/Rahul 

 

On Wednesday, October 22nd, 2025 at 10:05 AM, Martin Thomson <mt@lowentropy.net> wrote:

> On Tue, Oct 21, 2025, at 07:58, Rahul Gupta wrote:
> 

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

> 

> Others have responded to your other concerns, but I wanted to comment on this extensibility question.
> 

> You suggest that an alternative spelling might be more elegant. But I think that what we have is, for the use cases you contemplate, the most elegant option. Largely because it enables progressive comprehension by intermediaries.
> 

> Consider that Incremental: ?1;buffer-delay=50 which might be a way of suggesting that you want incremental delivery but can tolerate a buffering delay of up to 50 milliseconds. An intermediary that doesn't understand the parameter still works just fine (and will buffer minimally based on their own determination). That allows for incremental implementation (pun totally intended), which is an important feature.
> 

> Intermediaries will have to change their architecture to support this draft; that sort of progressive implementation makes the ask much more modest. In comparison, bundling this feature with other capabilities as you seem to suggest makes the ask bigger. Recall that we're deploying to a large, uncoordinated system and so we have to make reasonable asks of participants in that system.