- From: Martin Thomson <mt@lowentropy.net>
- Date: Wed, 22 Oct 2025 15:32:11 +1100
- To: ietf-http-wg@w3.org
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.
Received on Wednesday, 22 October 2025 04:32:36 UTC