[Ohai] Re: Mohamed Boucadair's Discuss on draft-ietf-ohai-chunked-ohttp-07: (with DISCUSS and COMMENT)

[Martin Thomson <[e-mail]>]

On Tue, Feb 3, 2026, at 00:12, Mohamed Boucadair via Datatracker wrote:
> I trust the examples in the appendix were validated.

They were directly generated by an interoperating implementation.  I can't confirm that they were independently validated.  My implementation generated and validated them.  I don't know if Tommy checked these specific examples, but I believe he did check a previous version (I think the examples have changed a few times for formatting reasons, though the format has not).

> I have some comments about this part:
>
>    Chunked OHTTP requests and responses SHOULD include the Incremental
>    header field [INCREMENTAL] in order to signal to intermediaries (such
>    as the relay) that the content of the messages are intended to be
>    delivered incrementally.  Without this signal, intermediaries might
>    buffer request or response body until complete, removing the benefits
>    of using Chunked OHTTP.
>
> # If there are cases where it is envisioned that the Client (or Relay Resource)
> can be aware that Relay Resource (or Gateway Resource) will by default forward
> chunks incrementally, then call that as an exception to this SHOULD.
> # Absent such exceptions, and given that the benefits might be nullified in the
> absence of the header, why isn’t this a MUST?

I don't think the exception to the SHOULD is shaped quite like that.  Even if an intermediary is known to incrementally forward messages, the Incremental field is still probably advisable (if incremental forwarding is desired, that is).

Where it makes sense to omit the Incremental field is when a request doesn't need incremental forwarding (because it is a single unit) but the response does.  In that case, the chunked form might be used to let the gateway know to use the chunked form in the response.

Another case is where the goal is not incremental forwarding, but incremental *processing*.  So maybe the entire resource is available, but the endpoint sending the message wants to make it easier to handle in pieces.  Consider a server that is responding with the contents of a massive database table.  The content is all there and it doesn't matter if the intermediary wants to buffer.  But having it in chunked form makes it easier to process.

I do know that we could probably do more to explain the why around this, so I'll open an issue to track a fix.

https://github.com/ietf-wg-ohai/draft-ohai-chunked-ohttp/issues/55

> # To be useful, the value of the header should be set to “?1” as signaling the
> default value would be useless. I think that this should be called out in the
> text.

That seems too obvious to justify the expenditure of text, at least from my perspective, but I'm not opposed to it.

> # Increment header in C/RR and RR/GW Legs
>
> Is there any dependency between the use of Incremental header set by the client
> and Relay Resource? For example, is a Relay Resource allowed to add an
> Increment Header set to true independent of whether this was set by the Client?

It's HTTP, so it can add the header field if it chose to, I guess.  Not much point in doing so, because the relay is the entity the field is generally targeted at.