Mohamed Boucadair's No Objection on draft-ietf-httpbis-incremental-03: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-httpbis-incremental-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-incremental/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Kazuho, Tommy, and Martin,

Thank you for the effort put into this well-written document.

Please find below some comments:

# Advisory

Section 3 says:

   The Incremental field is advisory, as intermediaries that are unaware
   of the field or that do not support the field might buffer messages,
   even when explicitly requested otherwise.

… but then requires that an error message is sent if not honored by an
intermediate that supports the header, per the following:

   If an intermediary decides outright to refuse forwarding the message
   body incrementally, the intermediary MUST generate an error response
   rather than buffering an entire message before forwarding.

## How such function is operationally justified for intermediary nodes? What is
the incentive to deploy here?

## How sending the error makes things better for applications?

## How applications are expected to behave when they receive such errors?

# Exceptions

Section 3 says:

   Upon receiving a header section that includes an Incremental header
   field with a true value, HTTP intermediaries SHOULD NOT buffer the
   entire message before forwarding it.  Instead, intermediaries SHOULD
   transmit the header section downstream and continuously forward the
   bytes of the message content as they arrive.

The security considerations includes a discussion when the above behavior can
be bypassed. However, RFC9110 cites other exceptions per the following:

   An HTTP message can be parsed as a stream for incremental processing
   or forwarding downstream.  However, senders and recipients cannot
   rely on incremental delivery of partial messages, since some
   implementations will buffer or delay message forwarding for the sake
   of network efficiency, security checks, or content transformations.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

## Shouldn’t all these exceptions be reminded in this document as well?

## Isn’t “SHOULD”/”SHOULD NOT” recommendation betting that the message is safe
to forward by default?

## BTW, it would be helpful to add a forward reference to Section 4.

# HTTP implementations

CURRENT:
   The request to use incremental forwarding ** also ** applies to HTTP
   implementations.

I don’t understand “also” mention and “HTTP implementations” mentioned here.

Isn’t the signal only targeting intermediaries per the following?

CURRENT:
   A true value ("?1") indicates that the sender requests intermediaries
   to forward the message incrementally, as described below.

# Misc.

## SSE Example

CURRENT:
   For example, Server-Sent Events [SSE] uses a long-running HTTP
   response, where the server continually sends notifications as they
   become available.

Is the assumption here that only portions of a notification are sent, not that
a full notification is included in a message?

Otherwise, I don’t understand how this is used as an example.

## Probing

CURRENT:
   Clients can rely on
   prior knowledge or probe for support on individual resources.

### Are there pointers to examples of how such probe can be done?

### I wonder to what extent the results of such probing are reliable given that
rate-limit (or filters to decide which messages can be granted incremental
forwarding) may be in place.

Cheers,
Med

Received on Monday, 2 February 2026 12:37:59 UTC