Incremental Forwarding of HTTP Messages
draft-ietf-httpbis-incremental-04

# Andy Newton, ART AD, comments for draft-ietf-httpbis-incremental-03
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-httpbis-incremental-03.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Julian Reschke for the ARTART review.


## Comments

Many thanks to the authors and the working group for this doc.

Thanks to Chris Lonvick for their secdir review. 

General:  A well written, easy to read specification.  I just have a couple of comments...

Section 3, third from last para:  In the paragraph that starts 'The Incremental field is advisory', appears to address the situation where the HTTP intermediary is unfamiliar with the new header field.  Am I reading this right?  If so, perhaps a more direct discussion of 'transition' might be useful (as Chris Lonvick points out in their secdir review).  In addition, while 'advisory' is a perfectly normal English word, it isn't one we normally see in Standards track specifications.  I'd be happy to help with the wording (although I suspect that you all are well equipped to do this without help).

Section 4:  Perhaps the addition of a reminder that RFC 9110, Section 17.2 does still apply might be in order.  Of course, that warning is already 'in play' as it were, the question is whether it is worth a reminder.

# Éric Vyncke INT AD comments for draft-ietf-httpbis-incremental-03
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits.


I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Section 3

Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, the SHOULD cannot appear alone.

Two uses in this section:
`HTTP intermediaries SHOULD NOT buffer the entire message before forwarding it` SHOULD rather than a MUST is probably to cope with 'legacy' intermediaries, if so, then suggest using a sentence such as 'HTTP intermediaries implementing this specification MUST NOT...'

Later `SHOULD use the presence of the Incremental header field` is either in the same case as above, else it should be clear when an intermediary can deviate from the SHOULD.

### Section 4.1

Same comment about the SHOULD in ` the intermediary SHOULD respond with a 501 (Not Implemented) error``

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

Thank you to Stewart Bryant for the GENART review.