jiebi/CodeConvo huggingface dataset:
Change:
This is really about case-sensitivity. The Connection header field value is case-insensitive - URL The requirement is uppercase but example uses lowercase. Without citing or mentioning the case sensitivity, readers might be confused, and pedants might complain

Discussion:
the origin of the proxy. the request SHALL include a single "Connection" header field with <del> value "Upgrade". </del> <ins> value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the request SHALL include a single "Upgrade" header field with value "connect-udp".

Protocols). the reponse SHALL include a single "Connection" header field with <del> value "Upgrade". </del> <ins> value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the response SHALL include a single "Upgrade" header field with value "connect-udp".
Change:
It's mentioned in the abstract and intro but I think it would be useful to remind people that there are prerequisites required to use extended CONNECT in the section that details the specific requirements.

Discussion:
3.4. <del> When using HTTP/2 H2 or HTTP/3 H3, UDP proxying requests use HTTP pseudo-header fields with the following requirements: </del> <ins> When using HTTP/2 H2 or HTTP/3 H3, UDP proxying requests use Extended CONNECT.  This requires that servers send an HTTP Setting as specified in EXT-CONNECT2 and EXT-CONNECT3, and that requests use HTTP pseudo-header fields with the following requirements: </ins> The ":method" pseudo-header field SHALL be "CONNECT".
Change:
I'm having trouble grokking this, is the mention of "different semantics" duplicate text or is it meant to apply to different things?

Discussion:
IDs are client-allocated, and odd-numbered context IDs are proxy- allocated.  The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be <del> simultaneously assigned different semantics in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re- allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </del> <ins> simultaneously allocated in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does
Change:
There's a danger people read too much into "datagram packets" or "registration packets". I think it would be clearer to say something like "due to reordering of packets that contain datagrams or registration messages"

Discussion:
header fields or capsules to register contexts.  Depending on the method being used, it is possible for datagrams to be received with Context IDs which have not yet been registered, for instance due to <del> reordering of the datagram and the registration packets during transmission. </del> <ins> reordering of the packet containing the datagram and the packet containing the registration message during transmission. </ins> 5.
Change:
All of these should apply here, doesn't hurt to remind people. Especially the bit in the other spec that says Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers).

Discussion:
However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <ins> The security considerations described in HTTP-DGRAM also apply here. </ins> 8. 8.1.
Change:
The last paragraph of section 5, considers payload length There's a small chance for confusion here, because the DATAGRAM capsule format has a field and has a field. Consider therefore explicitly illustrating the maths that is required to determine the payload for which your 65527 limit MUST apply. I.e. this would be calculated by looking at the Capsule's length value and subtracting the encoded length of the Context ID field. (or whatever the answer is, in case I got it wrong)

Discussion:
request with a failure, or if the datagrams are received by the proxy before the request. <del> Endpoints MUST NOT send HTTP Datagrams with payloads longer than 65527 using Context ID zero.  An endpoint that receives a DATAGRAM capsule using Context ID zero whose payload is longer than 65527 MUST </del> <ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527 using Context ID zero.  An endpoint that receives a DATAGRAM capsule using Context ID zero whose Payload field is longer than 65527 MUST </ins> abort the stream.  If a proxy knows it can only send out UDP packets of a certain length due to its underlying link MTU, it SHOULD discard <del> incoming DATAGRAM capsules using Context ID zero whose payload is longer than that limit without buffering the capsule contents. </del> <ins> incoming DATAGRAM capsules using Context ID zero whose Payload field is longer than that limit without buffering the capsule contents. </ins> 6.
Change:
This is a long sentence that mixes singular and plural terms, for different concepts. I think this needs some editing to improve readability.

Discussion:
octets" in UDP). Clients MAY optimistically start sending proxied UDP packets before <del> receiving the response to its UDP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy before the request. </del> <ins> receiving the response to its UDP proxying request.  However, implementors should note that such proxied packets may not be processed by the proxy if it responds to the request with a failure, or if the proxied packets are received by the proxy before the request. </ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints
Change:
This single paragraph has ~150 words and about 10 normative requirements of the MUST / MUST NOT variety. Personally I find this quite a dense presentation of information. But I'll leave it up to your editorial discretion to fix or not.

Discussion:
Template TEMPLATE with the variables "target_host" and "target_port". Examples are shown below: <del> The URI Template MUST be a level 3 template or lower.  The URI Template MUST be in absolute form, and MUST include non-empty scheme, authority and path components.  The path component of the URI Template MUST start with a slash "/".  All template variables MUST be within the path component of the URI.  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.  The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.  If any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the proxy. </del> <ins> The following requirements apply to the URI Template: The URI Template MUST be a level 3 template or lower. The URI Template MUST be in absolute form, and MUST include non- empty scheme, authority and path components. The path component of the URI Template MUST start with a slash "/". All template variables MUST be within the path component of the URI. The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables. The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot- Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix. If any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the proxy. </ins> Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query,
Change:
Section 4, second paragrap: 'The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics. Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order.' I found this text initially confusing. I think what I was missing initially was a reminder that the HTTP datagram will be either in the communication context of the HTTP Request (HTTP 1.x) or the HTTP datagram will contain the quarter stream ID, and thus be in context. So an potential improvement here would be to add a clarification before this to remind that HTTP datagram will always be in context of a given HTTP request.
Fixed by
Section 4 last sentence 2 paragraph is: Why is there a "-"? Actually not sure what the second is supposed to say. Is there anything missing?
The dash has meaning similar to parentheses: it is equivalent to (see ). This parenthetical clause adds context to the main clause: allocation is separate but usage is not.
Do you have a suggestion for text that would be better?
I find the use of namespace in the quoted text unhelpful. You might editorialize this sentence a bit anyway to improve the clarity. Something like "Context ID allocation depends on restrictions to the use of even- and odd-numbered context IDs in order to avoid the need for synchronisation. However, once a context has been allocated, those restrictions no longer apply and context IDs can be used by any client or proxy, independent of who initially allocated them.
Lucas thanks that's much better! (I think this "allocation carries" wording confused me a bit)
:shipit:

Discussion:
it is possible for a context ID with the same numeric value to be simultaneously allocated in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re-allocated within a <del> given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </del> <ins> given HTTP namespace but MAY be allocated in any order.  The context ID allocation restrictions to the use of even-numbered and odd- numbered context IDs exist in order to avoid the need for synchronisation between endpoints.  However, once a context ID has been allocated, those restrictions do not apply to the use of the context ID: it can be used by any client or proxy, independent of which endpoint initially allocated it. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does
Change:
I had to read the first sentence multiple time to parse it: When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format defined in [Figure 6]. I think turning the sentence around would make it slightly easier tor read: The HTTP Datagram Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format defined in [Figure 6], when associated with streams of UDP proxying requests.
I think I find it easier to read the other way around
Or split the difference
that works too. I also found the term "UDP proxying request streams" a bit clumsy. but the new sentence works much better. Thanks!

Discussion:
5. <del> When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see HTTP-DGRAM) has the format </del> <ins> When HTTP Datagrams (see HTTP-DGRAM) are associated with UDP proxying request streams, the HTTP Datagram Payload field has the format </ins> defined in dgram-format.  Note that when HTTP Datagrams are encoded using QUIC DATAGRAM frames, the Context ID field defined below directly follows the Quarter Stream ID field which is at the start of
Change:
Section 3.1 mentions proxy handling requirements and notes a DNS failure SHOULD be communicated in the response using Proxy-Status. Is that the only case? Maybe it's worth mentioning that the header can be used for any other type of failure too.
It's linked to a SHOULD requirement
Fair enough. Let it be known that by this issue, NAME has volunteered to become Area Director.
I have been volunteered many times by other people, I don't think this one will change anything

Discussion:
Therefore it needs to respond to the request without waiting for a packet from the target.  However, if the target_host is a DNS name, the proxy MUST perform DNS resolution before replying to the HTTP <del> request.  If DNS resolution fails, the proxy MUST fail the request and SHOULD send details using the Proxy-Status header field PROXY- STATUS. </del> <ins> request.  If errors occur during this process (for example, a DNS resolution failure), the proxy MUST fail the request and SHOULD send details using the Proxy-Status header field PROXY-STATUS. </ins> Proxies can use connected UDP sockets if their operating system supports them, as that allows the proxy to rely on the kernel to only
Change:
Section 3 "connect-udp" uses the Capsule Protocol as defined in [HTTP-DGRAM]. What does "uses" here mean? As there are situations where the Capsule Protocol and the Datagram Capsule defined in HTTP-DGRAM is not required to be used, it is not clear if it MUST be implemented and MAY be used?
It would be better to link specifically to URL associated request's data stream uses the Capsule Protocol. If they do so, that means that the contents of the associated request's data stream uses the following format ...
and possibly forward ref to https://ietf-wg-URL
And that might be clearer, assuming that the implementation requirement is clear in those section of the HTTP datagram spec.

Discussion:
3. This document defines the "connect-udp" HTTP Upgrade Token. "connect- <del> udp" uses the Capsule Protocol as defined in HTTP-DGRAM. </del> <ins> udp" uses the Capsule Protocol as defined in HTTP-DGRAM.  The format of HTTP Datagrams is defined in format. </ins> Clients issue requests containing a "connect-udp" upgrade token to initiate a UDP tunnel associated with a single HTTP stream.  Tunnels
Change:
"Upgrade" (note that this requirement is case-insensitive as per {{Section 7.6.1 of HTTP}}). "Single" implies that there can't be other values (at least in other header lines, and possibly this one). That's an inappropriate constraint.
Thanks for catching this oversight, fixing via .

Discussion:
the request SHALL include a single Host header field containing the origin of the UDP proxy. <del> the request SHALL include a single "Connection" header field with value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </del> <ins> the request SHALL include a "Connection" header field with value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the request SHALL include a single "Upgrade" header field with value "connect-udp".
Change:
"connect-udp". "Single" implies that this mechanism is incompatible with any other upgrade mechanisms. If that's actually the case, it might be good to state so explicitly, rather than rely on this single word.
Thanks for catching this oversight. Similar to , this was not the intent. Fixing via .

Discussion:
"Upgrade" (note that this requirement is case-insensitive as per HTTP). <del> the request SHALL include a single "Upgrade" header field with value "connect-udp". </del> <ins> the request SHALL include an "Upgrade" header field with value "connect-udp". </ins> For example, if the client is configured with URI Template "https://proxy.example.org/.well-known/masque/
Change:
Try as we might, we can't retroactively place this requirement on the countless deployed caches on the Internet. Given that at least over HTTP/1.1 this mechanism uses GET, it might be better to specify that the GET response needs the appropriate caching metadata.
Good catch. That particular text came from back when we only used CONNECT, as that's defined as non-cacheable. Since defining how to cache Upgrade sounds like dragons holding footguns, I'm just going to remove this text via . That way we rely on existing HTTP documents to properly define how caching works.

Discussion:
successful UDP proxying responses also do not carry any message content. <del> Responses to UDP proxying requests are not cacheable. </del> 3.1. Upon receiving a UDP proxying request, the recipient UDP proxy
Change:
Looking at the changes in the document I think I have picked up on another potential issue. Due to the discussion in URL I have to ask what happens if the client issues an Connect request over HTTP/2 that is then changed into an HTTP/1.1 request by an intermediate HTTP proxy in front of the actual MASQUE server. I don’t think this issue is discussed and what a MASQUE server does if it gets a CONNECT request with an Connect-UDP upgrade header.
In that scenario, the client will send: and the intermediary converting from HTTP/2 to HTTP/1.1 will convert that to: That works as expected. Are you saying there's a problem here?
Probably worth a mention in this spec, like CONNECT already does, that a proxy can forward CONNECT-UDP requests to a proxy it has configured. I don't think much more detail is required than that. Such a proxy needs to follow the normative requirements set out else where. Concerns about converting requests between HTTP versions are common and not terribly unique here.
That sounds like a worthwhile clarification. Tagging as editorial.
LGTM, parity with HTTP without compromising existing tone / style

Discussion:
3.1. <del> Upon receiving a UDP proxying request, the recipient UDP proxy extracts the "target_host" and "target_port" variables from the URI it has reconstructed from the request headers, and establishes a tunnel by directly opening a UDP socket to the requested target. </del> <ins> Upon receiving a UDP proxying request: if the recipient is configured to use another HTTP proxy, it will act as an intermediary: it forwards the request to another HTTP server.  Note that such intermediaries may need to reencode the request if they forward it using a version of HTTP that is different from the one used to receive it, as the request encoding differs by version (see below). otherwise, the recipient will act as a UDP proxy: it extracts the "target_host" and "target_port" variables from the URI it has reconstructed from the request headers, and establishes a tunnel by directly opening a UDP socket to the requested target. </ins> Unlike TCP, UDP is connection-less.  The UDP proxy that opens the UDP socket has no way of knowing whether the destination is reachable.
Change:
From AD Review: Expand the acronym and add a (normative!) reference.
I'm going to mark this editorial since it's just clarifying what ECN is, and I don't believe we've had any confusion on that point among working group members.
The second commit explicitly mentions the TCP ECN feedback mechanism, for completeness. And yes, this is editorial.

Discussion:
certainty that the inner traffic is congestion-controlled. If a client or UDP proxy with a connection containing a UDP proxying <del> request stream disables congestion control, it MUST NOT signal ECN support on that connection.  That is, it MUST mark all IP headers with the Not-ECT codepoint.  It MAY continue to report ECN feedback via ACK_ECN frames, as the peer may not have disabled congestion control. </del> <ins> request stream disables congestion control, it MUST NOT signal Explicit Congestion Notification (ECN) ECN support on that connection.  That is, it MUST mark all IP headers with the Not-ECT codepoint.  It MAY continue to report ECN feedback via QUIC ACK_ECN frames or the TCP "ECE" bit, as the peer may not have disabled congestion control. </ins> When the protocol running over UDP that is being proxied uses loss recovery (e.g., QUIC), and the underlying HTTP connection runs over
Change:
Nit from the AD review. Reading this sentence, it took me a moment to figure out if we were talking about config on the client or the on the proxy.

Discussion:
Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query, <del> there exist proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MAY attempt to access UDP proxying capabilities using the default template, which is defined as: </del> <ins> there exist clients with proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port. Client implementations of this specification that are constrained by such limitations MAY attempt to access UDP proxying capabilities using the default template, which is defined as: </ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP proxy respectively.  UDP
Change:
As per registrations cannot contain a character so we register instead of
L602 still includes /udp, Is that intended?
Yeah my thinking was that we register and for now only define semantics for . A future document can tweak the related info line to also assign semantics to
I'm not a .well-known expert. My interpretation from mnot's suggestion was the prefix ends up as ".well-known/masque" and that the remainder is defined here as "/udp/{targethost}/{targetport}". Yes something else might come along and define other things to follow the prefix .well-known/masque but that can be deferred for later, and that spec needs to state all of its own rules. An alternative is that we expect everything after the prefix to behave in a similar way, I.e. .well-known/masque/{masquetype}/{targethost}/{target_port}. I don't know if that holds true.
From reading it appears that there is a lot of flexibility on how to organize additional path components so this appears OK to me, but I'll let NAME provide insights here
Yep, how you deal with what's "under" your registration is up to you. One option is to create a separate registry; another is to require additional values to update the registering RFC.

Discussion:
8.2. <del> This document will request IANA to register "masque/udp" in the "Well-Known URIs" registry maintained at </del> <ins> This document will request IANA to register "masque" in the "Well- Known URIs" registry maintained at </ins> <<https://www.iana.org/assignments/well-known-uris>>.