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

[Ballot comment]
# 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.

[Ballot comment]
# É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``

[Ballot 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

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-incremental-03. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

a single new field name is to be registered as follows:

Field Name: Incremental
Status: permanent
Structured Type: Item
Reference: [ RFC-to-be ]
Comments:

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the HTTP Proxy Error Types in the Hypertext Transfer Protocol (HTTP) Proxy-Status registry group located at:

https://www.iana.org/assignments/http-proxy-status/

a single new error type will be registered as follows:

Name: incremental_refused
Description: The HTTP message contained the Incremental HTTP header field, but the intermediary refused to forward the message incrementally.
Extra Parameters: None
Recommended HTTP Status Code: 501
Response Only Generated by Intermediaries: true
Reference: [ RFC-to-be ]
Notes:

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-12-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-incremental@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mbishop@evequefou.be, mnot@mnot.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Incremental Forwarding of HTTP Messages) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Incremental Forwarding of HTTP Messages'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the "Incremental" HTTP header field, which
  instructs HTTP intermediaries to forward the HTTP message
  incrementally.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-incremental/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Reasonably broad agreement; this document enjoyed diverse discussion across a good cross-section of the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were some last-minute concerns raised about the data structure chosen (a Boolean), but this was discussed extensively and the editors confirmed that approach.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not yet, although I believe there has been some experimentation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Nothing applicable.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Nothing applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains one minimal ABNF rule.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

It is believed that the effects of this document are contained within HTTP.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard; this is a standards-track HTTP extension.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; private messages.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references look to be appropriately classified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

From familiarity with the registries in question, this looks correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Reasonably broad agreement; this document enjoyed diverse discussion across a good cross-section of the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were some last-minute concerns raised about the data structure chosen (a Boolean), but this was discussed extensively and the editors confirmed that approach.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not yet, although I believe there has been some experimentation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Nothing applicable.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Nothing applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains one minimal ABNF rule.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

It is believed that the effects of this document are contained within HTTP.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard; this is a standards-track HTTP extension.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; private messages.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references look to be appropriately classified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

From familiarity with the registries in question, this looks correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/