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

I am not trying to either bikeshed or look for design-by-committee, but I
can see the point that making this a boolean provides less flexibility
moving forward - it assumes that all other extensibility can be captured in
parameters. If it's a boolean, we have these options:

* [no header passed] - This stream MAY be buffered (default functionality,
obviously)
* "Incremental: ?0" - This stream MAY be buffered
* "Incremental: ?1" - This stream SHOULD NOT be buffered

But if an entity wants to indicate either of the following:

* a stream MUST NOT be buffered, and a proxy must throw an error if it
requires buffering
* a stream MUST be buffered, and a proxy must throw an error if is cannot
buffer the stream

what options will it have to indicate that?

In other words, do we want to differentiate between 'should' and 'must' in
the structured field value as opposed to optional parameters?

Once a decision is made to make this a boolean, then it's not possible to
go back and change it later.

On Mon, Oct 20, 2025 at 2:34 PM 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
>
> > 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