Tri-state

[kazuho]

In kazuho/draft-kazuho-httpbis-incremental-http#11, @martinthomson says:

Ted Hardie suggested that we might have three states:

1. Incremental is necessary
2. Incremental is preferred, but not essential
3. Incremental is not necessary

This seems like a better way than #7 and more general overall.

I suggest a/p/n for always/preferred/not preferred.

Rationale for having "preferred" is discussed in kazuho/draft-kazuho-httpbis-incremental-http#8.
Rationale for having "not preferred" (or prefer buffered) is discussed in kazuho/draft-kazuho-httpbis-incremental-http#7.

[PiotrSikora]

Rationale for having "not preferred" (or prefer buffered) is discussed in kazuho/draft-kazuho-httpbis-incremental-http#7.

My reading of kazuho/draft-kazuho-httpbis-incremental-http#7 is that it's asking for a strict (i.e. reject if cannot be fulfilled) fully buffered store-and-forward semantics, and not simply expressing a preference, so that OHTTP request is not interleaved with OHTTP response, since the privacy properties of OHTTP were proven with that assumption in mind.

cc @thibmeu to confirm

[kazuho]

@PiotrSikora Thank you for raising the point.

While we wait for confirmation from @thibmeu, generally speaking, we are talking about a 2x2 matrix:

	required	preferable
incremental	status quo
fully-buffered

Status quo is targeting only the top left corner, with the aim to improve interoperability.

Doing other three boxes does not necessarily improve interoperability. Applications that are fine with the signal being indications of preference (rather than a requirement) are using the signal for optimization. For OHTTP, it could make sense to require fully-buffered behavior for privacy reasons, though requiring that does not improve interoperability (because the functionality provided by OHTTP works perfectly when the messages are forwarded incrementally).

Therefore, I am concerned that there would be less appetite among the proxy developers to implement something other than the "require-incremental" mode.

Probably, one way of moving forward would be to define the "require-incremental" mode and keep room for adding other modes.

[PiotrSikora]

Doing other three boxes does not necessarily improve interoperability. Applications that are fine with the signal being indications of preference (rather than a requirement) are using the signal for optimization.

FWIW, I'm not convinced that the "preference" options are worth implementing, since clients shouldn't be in the business of optimizing and micro-managing the buffering behavior of the intermediaries.

[thibmeu]

The comment on kazuho/draft-kazuho-httpbis-incremental-http#7 is indeed trying to signal a preference from the client to not interleave request and response. If the server support Incremental, this is a requirement, but not all server will support it.
I have added that description to a rough update of the draft in a fork.

This should allow a proxy that does not want to buffer request/response to reject the request, possibly with a fallback to a non chunked variant on the client side.

This is different from @martinthomson proposal which is to have a tri-state specifically for incremental. If I was to update your table

	required	preferred	not-necessary
incremental	?1	martin-state-1	martin-state-2
fully-buffered	?0