Template-Driven HTTP CONNECT Proxying for TCP
draft-ietf-httpbis-connect-tcp-17

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-httpbis-connect-tcp-16
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

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.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

###

## COMMENTS (non-blocking)


### Section 3

Please explain (or add a reference) about the syntax used in Figure 1.

Why not a "should" rather the interoperability-meaning of in `Recipients SHOULD begin forwarding payload from a DATA or FINAL_DATA capsule without waiting to receive the entire capsule, especially if the capsule is large.` ? See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ It seems to me that the "should" is to be preferred as the intend is low latency rather than interoperability.


### Section 3.2

Why not a MUST in `the "capsule-protocol" header field SHOULD be present with a value of "?1"` ? Else, provide guidance about the consequence(s) of not following the SHOULD.

The same issue in section 3.3.3 (and others :-( ...): the implementer has no clue about what to do...

## NITS (non-blocking / cosmetic)

### SHALL vs. MUST

For a non-English reader, please only use MUST rather than the mix of SHALL and MUST (even if they are equivalent per BCP14).

[Ballot discuss]
I am raising this as a DISCUSS to do just that. Discuss. I may not understand this completely, but I am hoping that by having this discussion, I will be corrected in my understanding or the document will be updated to make the point a little clearer.

Section 4.3, first paragraph:

554 >    This specification supports the "Expect: 100-continue" request header
555 >    ([HTTP], Section 10.1.1) in any HTTP version.  The "100 (Continue)"
556 >    status code confirms receipt of a request at the proxy without
557 >    waiting for the proxy-destination TCP handshake to succeed or fail.
558 >    Clients MAY send "Expect: 100-continue", and proxies MUST respect it
559 >    by returning "100 (Continue)" if the request is not immediately
560 >    rejected.  This allows for a few useful improvements:

This permission contradicts a MUST NOT in RFC 9110, and the document
doesn't say it updates RFC 9110. RFC 9110 Section 10.1.1:

>    *  A client MUST NOT generate a 100-continue expectation in a request
>      that does not include content.

A "connect-tcp" request has no content. RFC 9297 Section 3.2 says that
when the Capsule Protocol is in use, "the associated HTTP request and
response do not carry HTTP content". RFC 9110 Section 9.3.6 says it even
more directly for the HTTP/2 and HTTP/3 case, where the method is
CONNECT: "A CONNECT request message does not have content." So as
written, Section 4.3 gives clients a MAY to do something a normative
STD reference forbids.

The proxy-side rules in RFC 9110 Section 10.1.1 (for both origin
servers and proxies) only apply when the request
"indicates request content will follow". An unmodified
gateway that follows RFC 9110 has no reason to forward the
expectation, or to produce a 100, for a request with no content. Some
might reply 417 or 400. That makes the "proxies MUST respect it"
requirement hard to meet across the gateways that Section 5.3 invites
deployments to use. Section 5.3 also doesn't list Expect handling
among the things a compatible gateway has to do.

I thank Antun Jurkovic for raising this on the WG list against -16.
Ben agreed it was a conflict he hadn't spotted, and David Schinazi
called it "a real bug". The thread has proposed several fixes:
updating RFC 9110, defining a connect-tcp-specific request header,
using a different 1xx code, or dropping the feature. None of them is
in the document yet, and the WG hasn't converged. I'm not asking for
any particular fix. I'm asking that -16 not go forward with a
requirement that conflicts with RFC 9110. If the WG decides to
update RFC 9110, that needs an "Updates: 9110" header and a
justification. A narrower fix that this document can carry on its
own, such as a new header field, avoids that.

[Ballot comment]
Section 3, first paragraph:

164 >    A template-driven TCP transport proxy for HTTP is identified by a URI
165 >    Template [RFC6570] containing variables named "target_host" and
166 >    "target_port".  This URI Template and its variable values MUST meet
167 >    all the same requirements as for UDP proxying ([CONNECT-UDP],
168 >    Section 2), and are subject to the same validation rules.  Clients

RFC 9298 Section 2 only covers the template itself. The rules
for the variable values are in RFC 9298 Section 3: the ABNF for
target_host and target_port, non-empty values, percent-encoded colons
in IPv6 literals, and a port between 1 and 65535. Since this sentence
is the only place connect-tcp picks up those value rules, the citation
should be "Sections 2 and 3". The HTTP/2 example in Figure 3 already
percent-encodes the IPv6 literal, so the intent is clear.

---

Section 3.1, after the HTTP/1.1 request requirements, compared with
Section 3.2:

245 >    If the request is well-formed and permissible, the proxy MUST attempt
246 >    to establish the TCP connection before sending any response status
247 >    code other than "100 (Continue)" (see Section 4.3).  If the TCP
248 >    connection is successful, the response SHALL be as follows:

This requirement, and the definition of a successful response, appear
only in the HTTP/1.1 subsection. Section 3.2 defines the HTTP/2 and
HTTP/3 request, but says nothing about the response. As I read it, an
HTTP/2 proxy could send a 200 before it even tries the TCP connection
and still conform. A later failure would then show up as a stream
reset, with no status code and no Proxy-Status. RFC 9110 Section 9.3.6
gives 2xx its meaning for CONNECT, and Section 4.3 implies that the
final status waits for the TCP handshake. Still, the version-neutral
rule should be stated in a version-neutral place, either as a
paragraph in Section 3 or as a matching paragraph in Section 3.2.

---

Section 5.2, fallback to the default template:

642 >    If the client infers that classic HTTP CONNECT is not supported, it
643 >    SHOULD retry the request using the registered default template for
644 >    "connect-tcp" (Figure 8).  If this request succeeds, the client
645 >    SHOULD record a preference for "connect-tcp" to avoid further retry
646 >    delays.

The client side of the default template is specified here, but I
couldn't find the server side. RFC 9298 Section 2 pairs its default
template with "UDP proxy deployments SHOULD offer service at this
location if they need to interoperate with such clients." Without a
similar sentence, a client following this SHOULD could retry against
a proxy that never offers the well-known path. Was leaving out the
server-side statement deliberate?

---

746 > 7.  Operational Considerations

Thank you for including a real Operational Considerations section,
not just boilerplate. The HTTP/1.1, timeout, and address-sharing
guidance is useful to operators. What I don't see is anything about
managing a templated TCP proxy once it's deployed.

Much of the material already exists elsewhere in the document:

- the knobs an operator will configure, such as per-client and
  per-destination connection limits, receive-window and buffer
  limits, timeouts, the source address range, and TIME-WAIT reuse
  (Sections 6.1 and 7.2)
- the diagnostic signals, namely status codes and Proxy-Status
  (Sections 4.2 and 4.3)
- the migration path from classic CONNECT (Section 5.2)

Section 7 doesn't pull any of this together. An operator who goes
straight to it won't learn which limits to set, or what to monitor to
tell a healthy proxy from one under the resource-exhaustion attacks
in Section 6.1. Useful things to watch would include active tunnels
per client, buffered bytes, and the rate of abrupt versus graceful
closures.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 1.1, first paragraph:

99 >    client and the target destination ([HTTP], Section 9.3.6).  To date,
100 >    this is the only mechanism defined for proxying TCP over HTTP.  In

As written, this statement will not age well. Once this is published,
that won't be true anymore, because this document defines a second
mechanism. Something like "Before this specification, this was the only
mechanism ..." would age better.

---

Section 4.2, second paragraph:

538 >    A 4XX status code indicates the the request is malformed or

s/the the/that the/

---

Section 5.2, configuration input types:

612 >      -  In the "proxy" dictionary of a provisioning domain resource at
613 >          the corresponding .well-known URI
614 >          ([I-D.ietf-intarea-proxy-config], Section 2).

In draft-ietf-intarea-proxy-config-14, the structure is the "proxies"
array of dictionaries, defined in Section 3. "proxy" is a key inside
each of those dictionaries. Section 2 covers only the .well-known PvD
fetch. Perhaps: 'In the "proxies" array of a provisioning domain
resource fetched from the corresponding .well-known URI
([I-D.ietf-intarea-proxy-config], Sections 2 and 3).'

---

Section 5.3, gateway requirements list:

658 >    *  support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an
659 >      HTTP/1.1 server)

This bullet has no trailing period, but the bullet before it does.

---

Section headings 4.1 and 4.3:

502 > 4.1.  Latency optimizations
552 > 4.3.  Conveying metadata

These use sentence case, but the other headings (for example "4.2.
Indicating Failure") use title case.

[Ballot comment]
Thank you for this document, I do have some concerns about the interactions with the transport and network layers, but suspect that these concerns may be addressed by additional text, rather than any changes to the protocol design. None-the-less I'd be interested in hearing the answers to the questions below:

##Section 7.2 Timeouts
  "However, for efficient operation, it may be necessary to
  adjust the settings for TCP keep-alives ([TCP], Section 3.8.4), QUIC
  idle timeouts ([QUIC], Section 10.1), HTTP/2 PING frames ([HTTP/2],
  Section 6.7), and other transport options."
- The above text puzzled me, because I could not work-out what operational action needed to be taken to manage this. Please explain more.

- I was expecting some insight that might help designers of MASQUE services, such as text here on the implications and overhead of multiple layers of keep-alive functions - such as perhaps a note that sending keep-alive packet consumes resources (in the case of a battery-powered radio link the additional resource can be significant), and therefore it is important to avoid unnecessary keep-alive packets, especially to avoid sending separate packets at different protocol layers.

## DSCP Usage
- I was surprised this section did not note the implications of proxying on the use of DSCPs to mark traffic.

## EH Interactions
- It is important to call out any implications of proxying on the use of the use of Extension Headers for IPv6 and any limitations this places on using IPv6 EH.

## ECN Support
- How does the proxy function interact with a TCP stack that enables and uses Explicit Congestion Notification? Please explain.

Best wishes,
Gorry Fairhurst
(WIT AD)

[Ballot comment]
** Section 8.1 – 8.3

Section 8.1
  IF APPROVED, IANA is requested to add the following entry to the HTTP
  Upgrade Token Registry:

What does the “IF APPROVED” prefix text mean?  Should this text be removed in the final RFC?
This phrase is also found in Section 8.2-8.3.

[Ballot comment]
Thanks to Valery Smyslov for their secdir review.

Thanks to the author (and working group) for a specification that is easy to read.  I have a couple of comments, the last two I consider important, enough that I thought about making them discusses.  I'm sure they will be carefully considered even as no obj comments.

Section 4.1, para 1:  I would remove the parentheses from the last sentence.  It certainly is normative, and it impacts interoperability (hence the BCP 14 language). The only hesitation I have making this comment is the lead sentence which leads the reader to believe that the paragraph is only about HTTP/2 and HTTP/3.  Perhaps also consider a new topic sentence, or make the HTTP/1.1 sentence its own paragraph.

Section 6:  It is important to call out the security considerations associated with both sending TCP stream content optimistically, and the support for TLS early data.  I'm not sure if it is all covered in RFC 8470 section 6, certainly the early data portion is.

Section 6:  As RFC 9110 states in section 17.16, "everything about the topic of HTTP authentication is a security consideration", it bears repeating (or referencing) here too (especially since section 3.3.2 is all about authentication).

[Ballot comment]
Hi Ben,

The changes in [1] address all the comments raised in my previous ballot [2].

Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-httpbis-connect-tcp-15&url2=draft-ietf-httpbis-connect-tcp-16&difftype=--html

[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2026OctDec/0057.html

[Ballot discuss]
Hi Ben,

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

Please find below some few comments; nothing major though:

# Consider explaining when it is appropriate to not begin forward data

CURRENT:
  Recipients SHOULD begin
  forwarding payload from a DATA or FINAL_DATA capsule without waiting
  to receive the entire capsule.

# Alignment with RFC9297

CURRENT:
  According to the Capsule Protocol ([CAPSULE], Section 3.2),
  new Capsule Types should be ignored by pre-existing proxies and
  intermediaries.  If a new Capsule Type cannot safely be ignored, the
  endpoints can confirm support using a new HTTP header field.

I’m afraid this is interpreting the behavior in 3.2 of 9297.

Could we shorten this text and simply point to 3.2 of 9297 for the handling of unknown Capsule Types?

See also below for “new” and “pre-existing” terminology.

# Even if this is an optional feature, I-D.ietf-intarea-proxy-config is normative for the following part:

CURRENT:
  Clients for this specification MAY accept various configuration
  inputs, including:

  …

  *  The full URI, including path, of a provisioning domain resource
      containing one or more "connect-tcp" proxy sub-dictionaries
      ([I-D.ietf-intarea-proxy-config], Section 3).

[Ballot comment]
# Consider adding a brief mention of these “deficiencies”

CURRENT:
  However, this tunneling functionality has several
  important deficiencies

##  Also, I suggest to drop “modern” thing as that won’t age well in an RFC.

# Templated TCP proxy

## Please add a definition for that term.

## Consider to use consistent terminology as I also see “template-driven TCP transport proxy” in some sections.

# BCP 142

As the TCP proxy in this spec is basically a NAT (which inherits all the complications of such function), was adherence to BCP 142 been considered?

The document touches on a related item (timeouts in Section 7.3), though. I see rfc9298 inherited a requirement from UDP-BEHAVE for timers.

You may have good reasons why full BCP 142 can’t be mandate here, but I wanted to check this.

# Redundant normative language

CURRENT:
  capsule payloads, which MAY be empty, represents the TCP payload
  data.  A FINAL_DATA capsule additionally indicates that the sender
  has closed this stream, semantically equivalent to TCP FIN.  After
  sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA
  or FINAL_DATA capsules on this data stream.  (See Section 3.4 for
  related requirements.)

  DATA Capsule {
    Type (i) = 0x08,
    Length (i),  # MAY be zero
    TCP Payload (..),
  }

  FINAL_DATA Capsule {
    Type (i) = 0x09,
    Length (i),  # MAY be zero
    TCP Payload (..),
  }

The MAYs in the code snippets seem to be redundant with the MAY in the narrative text. I would s/MAY/may in the figure.

# “pre-existing” and “new” terminology is confusing

For example,

CURRENT:
  According to the Capsule Protocol ([CAPSULE], Section 3.2),
  new Capsule Types should be ignored by pre-existing proxies and
  intermediaries.  If a new Capsule Type cannot safely be ignored, the
  endpoints can confirm support using a new HTTP header field.

A proxy can “pre-exist” but it can be upgraded.

Rather than reasoning about new, I suggest to use “unknown”.

# Address sharing issues

Please consider adding a mention under OPS Cons to remind that the issues listed in RFC6269 will apply.

# For convenience, I sent a PR with some nits/minor edits: https://github.com/httpwg/http-extensions/pull/3543. Feel free to use or ignore.

Cheers,
Med

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Please find below some comments and suggestions that I would like to offer for
your consideration. They come from someone that is not very familiar with this
area, so please correct me if I am wrong.

The review is inline in the idnits output of v15 of this document. The end
of the review is marked by the tag

208   This protocol can be extended by defining additional relevant Capsule
209   Types.  According to the Capsule Protocol ([CAPSULE], Section 3.2),
210   new Capsule Types should be ignored by pre-existing proxies and
211   intermediaries.  If a new Capsule Type cannot safely be ignored, the
212   endpoints can confirm support using a new HTTP header field.

RFC 9297 Section 3.2 has endpoints drop unknown Capsule Types, while
intermediaries forward them unmodified. If I am correct, then perhaps:

CURRENT
  new Capsule Types should be ignored by pre-existing proxies and
  intermediaries.
SUGGEST
  new Capsule Types are silently dropped by pre-existing proxies and
  forwarded unmodified by intermediaries.


224   *  The request SHALL include a single "Host" header field containing
225       the origin of the proxy.

Doesn't the Host header field carries the authority (host and port) rather
than the origin, which also includes the scheme?


504   TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer,
505   proxies MAY ignore, reject, or accept the early_data extension
506   ([TLS], Section 4.2.10).  At the HTTP layer, proxies MAY process the

Early data is Section 4.3.10 in RFC 9846 (4.2.10 was its RFC 8446
number).

750   Templated TCP proxies can make use of standard HTTP gateways and
751   path-routing to ease implementation and allow use of shared
752   infrastructure.  However, current gateways might need modifications
753   to support TCP proxy services.  To be compatible, a gateway must:

Sections 7.2 and 7.3 carry requirements on implementations rather than
operational advice: what a gateway "must" do. Requirements on intermediaries are
already specified in Section 3. If these are meant to be normative, please consider
moving the gateway list into a new subsection of Section 3 with BCP 14 key words,
and the timeout MUST into Section 3.4, leaving deployment advice in Section 7.

787   Endpoints MAY impose additional timeouts, especially as a defense
788   against certain resource exhaustion attacks (Section 6.1).  However,
789   operators should apply timeouts cautiously to minimize the impact on
790   connections that are functioning but slow.  Any timeout imposed by
791   the endpoint MUST be treated as an abrupt closure of the affected
792   stream or connection (Section 3.4).

The MUST on treating a timeout as an abrupt closure is a requirement
on endpoint behaviour rather than operational advice, and it would sit
naturally with the closure handling in Section 3.4. This is on the same lines
as my previous comment.

798   IF APPROVED, IANA is requested to add the following entry to the HTTP
799   Upgrade Token Registry:

RFC 9110 Section 16.7 asks that a registration name the expected
protocol-version tokens, and the registry has a column for them; RFC 9298
registered "connect-udp" with "None". Perhaps also use the registry's name:

CURRENT
  IF APPROVED, IANA is requested to add the following entry to the HTTP
  Upgrade Token Registry:
SUGGEST
  IF APPROVED, IANA is requested to add the following entry to the
  "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry":

  Value:  connect-tcp
  Description:  Proxying of TCP payloads
  Expected Version Tokens:  None
  Reference:  This document

831   IF APPROVED, IANA is requested to add the following entry to the
832   "HTTP Capsule Types" registry:

IANA has already provisionally registered 0x08 (DATA) and 0x09
(FINAL_DATA) with a reference to -12. Perhaps:

CURRENT
  IF APPROVED, IANA is requested to add the following entry to the
  "HTTP Capsule Types" registry:
SUGGEST
  IANA has provisionally registered the following entries in the "HTTP
  Capsule Types" registry.  IF APPROVED, IANA is requested to make these
  registrations permanent and to update their reference to this
  document:

Please review and fix the following related to references:
RFC 9293: should be normative? The requirements in Section 3.4 are stated in
terms of TCP FIN, RST and the TIME-WAIT and CLOSED states.

IESG/Authors/WG Chairs:

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

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

First, in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry located at:

https://www.iana.org/assignments/http-upgrade-tokens

a new registration will be made as follows:

Value: connect-tcp
Description: Proxying of TCP payloads
Expected Version Tokens:
Reference: [ RFC-to-be ]

Second, in the MASQUE URI Suffixes registry in the Multiplexed Application Substrate over QUIC Encryption (MASQUE) registry group located at:

https://www.iana.org/assignments/masque

a new URI suffix will be registered as follows:

Path Segment: tcp
Description: TCP Proxying
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the HTTP Capsule Types registry also in the Multiplexed Application Substrate over QUIC Encryption (MASQUE) registry group located at:

https://www.iana.org/assignments/masque

two capsule types will be updated as follows:

Value: 0x08
Capsule Type: DATA
Status: permanent
Reference: [ RFC-to-be; Section 3 ]
Date: [ TBD-at-registration ]
Change Controller: IETF
Contact: [HTTPBIS_WG]

Value: 0x09
Capsule Type: FINAL_DATA
Status: permanent
Reference: [ RFC-to-be; Section 3 ]
Date: [ TBD-at-registration ]
Change Controller: IETF
Contact: [HTTPBIS_WG]

We understand that these are the only actions 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,

Sabrina Tanamal
IANA

The following Last Call announcement was sent out (ends 2026-10-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-connect-tcp@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mbishop@evequefou.be, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Template-Driven HTTP CONNECT Proxying for TCP) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Template-Driven HTTP CONNECT Proxying for TCP'
  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 2026-10-01. 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


  TCP proxying using HTTP CONNECT has long been part of the core HTTP
  specification.  However, this proxying functionality has several
  important deficiencies in modern HTTP environments.  This
  specification defines an alternative HTTP proxy service configuration
  for TCP connections.  This configuration is described by a URI
  Template, similar to the CONNECT-UDP and CONNECT-IP protocols.




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



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?

This document received a good amount of reviews and input, and is based on
the agreement of a large chunk of the WG that is involved with forward proxies.

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

No particular controversies came up with this document.

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 appeals threatened.

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)?

Some implementations have been discussed, but I'm not aware of large-scale implementations
yet. This protocol is mainly a successor to the very common "legacy" HTTP CONNECT.

## 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.

This document is pretty solidly within the HTTP scope; no close interactions come to mind.

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.

No formal review required.

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]?

No YANG module.

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.

No formal language.

## 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, I believe this document is in good shape to progress.

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?

We haven't flagged any such areas.

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, which is appropriate given that this is defining protocol details
within HTTP requests. All states reflect this.

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.

The author has not disclosed any IPR, and no one else has come forward with any.

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, the author is willing to be listed.

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.)

No notable nits.

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

No, these look good in the latest version

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

N/A

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.

N/A

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?

N/A

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.

This document does not change any other document status.

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]).

The IANA actions involve registering an HTTP upgrade token, a MASQUE default template,
and two HTTP capsules. These are clear and appropriate.

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.

No new registries.

[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

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?

This document received a good amount of reviews and input, and is based on
the agreement of a large chunk of the WG that is involved with forward proxies.

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

No particular controversies came up with this document.

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 appeals threatened.

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)?

Some implementations have been discussed, but I'm not aware of large-scale implementations
yet. This protocol is mainly a successor to the very common "legacy" HTTP CONNECT.

## 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.

This document is pretty solidly within the HTTP scope; no close interactions come to mind.

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.

No formal review required.

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]?

No YANG module.

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.

No formal language.

## 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, I believe this document is in good shape to progress.

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?

We haven't flagged any such areas.

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, which is appropriate given that this is defining protocol details
within HTTP requests. All states reflect this.

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.

The author has not disclosed any IPR, and no one else has come forward with any.

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, the author is willing to be listed.

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.)

No notable nits.

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

No, these look good in the latest version

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

N/A

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.

N/A

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?

N/A

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.

This document does not change any other document status.

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]).

The IANA actions involve registering an HTTP upgrade token, a MASQUE default template,
and two HTTP capsules. These are clear and appropriate.

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.

No new registries.

[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

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?

This document received a good amount of reviews and input, and is based on
the agreement of a large chunk of the WG that is involved with forward proxies.

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

No particular controversies came up with this document.

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 appeals threatened.

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)?

Some implementations have been discussed, but I'm not aware of large-scale implementations
yet. This protocol is mainly a successor to the very common "legacy" HTTP CONNECT.

## 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.

This document is pretty solidly within the HTTP scope; no close interactions come to mind.

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.

No formal review required.

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]?

No YANG module.

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.

No formal language.

## 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, I believe this document is in good shape to progress.

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?

We haven't flagged any such areas.

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, which is appropriate given that this is defining protocol details
within HTTP requests. All states reflect this.

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.

The author has not disclosed any IPR, and no one else has come forward with any.

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, the author is willing to be listed.

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.)

There is a slight redundancy with RFC 9000 being listed as a reference twice.

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

RFC 9000 is listed as both, and should just be Normative.

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

N/A

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.

N/A

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?

N/A

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.

This document does not change any other document status.

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]).

The IANA actions involve registering an HTTP upgrade token, a MASQUE default template,
and two HTTP capsules. These are clear and appropriate.

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.

No new registries.

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