jiebi/CodeConvo huggingface dataset:
Change:
Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored <del> by the receiving party. </del> <ins> by the receiving party.  For example, applications that choose to signal candidates via SDP may include a ufrag value in the SDP that represents candidates (such as "a=candidate ... ufrag abc").  Or as another exmaple, WebRTC implementations may include a ufrag in the JavaScript objects that represent candidates. </ins> One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by

Discussion:
NAME and NAME had an editors' discussion (see URL) about how to specify the handling of ICE restarts in the context of Trickle ICE. One possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange, because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. There is an SDP dependency on the a= line, but we've disengaged Trickle ICE from SDP, too. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway. I'm hoping that NAME can propose text...
At IETF 95, there was support for explicitly indicating which ufrag/pwd the candidate applies to. But the specifics are signaling-specific. So perhaps we should just update the text to say "SHOULD be explicit" in some way. URL
I am fine also adding to the spec a sample way of labeling them (the way Trickle for SIP does) Emil , Peter Thatcher EMAIL wrote:
By the way, this came up in the JSEP work recently, that with ICE restarts being roll-back-able, the explicit ufrag is really needed for edge cases there. We think the right solution is using a ufrag on the JS object, not on the SDP (since we also need to include it on the end of candidates message, and since it would look weird being duplicated in so many lines in the current remote description).
It looks like we already have a paragraph that indicates an implementation should have an explicit ufrag (or other correlation). Great! So, I made a PR to add some examples: URL
resolved
Change:
The Extended CONNECT protocol defined for this mechanism is "connect- ip", which is also referred to as CONNECT-IP in this document. <del> The CONNECT-IP protocol allows endpoints to set up a path for </del> <ins> The CONNECT-IP protocol allows endpoints to set up a tunnel for </ins> proxying IP packets using an HTTP proxy.  This can be used for various solutions that include general-purpose packet tunnelling, such as for a point-to-point or point-to-network VPN, or for limited

Discussion:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.
Change:
The only difference here is the endpoint that sends the first capsule. <del> 8. </del> <ins> 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay". <del> While it is expected that endpoints will have only one ACK-FREQUENCY </del> <ins> While it is expected that endpoints will have only one ACK_FREQUENCY </ins> frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum

Discussion:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.
Change:
not only inside endpoints but also across the end-to-end Internet path. <ins> Note that calling Clone() may result in on-the-wire signaling, e.g., to open a new connection, depending on the underlying Protocol Stack. </ins> If the underlying Protocol Stack does not support cloning, or cannot create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError:

Discussion:
Make clearer what "Priority is not entangled" means, following . Also added a note that Clone() may result in on-the-wire signaling.
Section 11.1.3 of the API says about Priority: "As noted in Section 6.4, this property is not entangled when Connections are cloned." Not sure what this means. I though when you clone a connection you would actually take the priority of the cloned connection but then you can change it independently for each connection in a group. Or what's the priority after cloning? Back to the default of 100? We should say this explicitly. Or maybe you even want to provide the priority while cloning? Actually looking at this now again, I think we would need to specify cloning a bit better anyway. I assume that calling clone() on a multiplexing capable connection would create a new stream; in case of quic is would only create local state but no on-the-wire singling. However if you call clone on a TCP connection, is that basically an initial() call that triggers the TCP handshake? We should say this explicitly.
I'd say it's exactly as you thought: When you clone a Connection, all Properties are copied (including the Priority), but then they are not entangled: If you change the Priority on the cloned Connection, the Priority on the original Connection stays as it was. If Priority was entangled, then it would change on both Connections if you change it on one of them. But yes, perhaps this is confusing and the text should be more explicit. The part on specifying cloning better: There's text on this in the Implementation draft on what happens with Clone() for each protocol. But maybe we can say in the API document that Clone() might trigger on-the-wire signaling or it might not, depending on the protocol.
Yes, both additions/clarification would be good.
LGTM - and thanks for adding this clarification!Thank you for the clarifications!
Change:
In order to protect against collisions, the 96 bit unique token numbers should be generated using a cryptographically secure pseudorandom number generator (CSPRNG), as specified in Appendix C.1 <del> of the TLS 1.3 specificationRFC8446.  With proper random numbers, if </del> <ins> of the TLS 1.3 specification RFC8446.  With proper random numbers, if </ins> fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%.

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection. <del> Server-generated connection IDs should seek to obscure any encoded routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the connection ID in the connection ID itself, instead of remembering it. QUIC_LB further specifies possible algorithms to generate connection IDs at load balancers. </del> <ins> QUIC_LB specifies algorithms for encoding the server mapping in a connection ID in order to share this information with selected on- path devices such as load balancers.  Server mappings should only be exposed to selected entities.  Uncontrolled exposure would allow linkage of multiple IP addresses to the same host if the server also supports migration which opens an attack vector on specific servers or pools.  The best way to obscure an encoding is to appear random to any other observers, which is most rigorously achieved with encryption.  As a result any attempt to infer information from specific parts of a connection ID is unlikely to be useful. </ins> 2.7.

Discussion:
repeats requirements from the transport spec unnecessarily. It might be easier to just strike this.
This is supposed to give advice to network operators e.g. in a load balancing setup where connection IDs are maybe generated centrally and distributed to the servers.
The surrounding text does. This paragraph does not.
I didn't think network operators who are in control of one of the endpoints would be considered in scope for this I-D. Surely the whole point is to advise network operators about what they should do with traffic they cannot hope to decrypt? If server endpoint operators are in scope, the Introduction should be revised. If they are not in scope, I could propose some words that essentially say "Don't bother trying to infer information from specific parts of the connection ID, for these reasons."
Okay, I think I see the problem now. Is better?
This is fine, but it presumes a lot about the outcome of things that aren't completely resolved in QUIC-LB. I think that I would like to see more of this left to QUIC-LB to deal with, especially if we are planning to publish this before QUIC-LB (which seems likely). That might mean being a lot more aggressive about cutting text here.
Change:
IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. <del> 4. </del> <ins> 3. </ins> <del> 4.1. </del> <ins> 3.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage:

Discussion:
Privacy text was moved to ip-handling, so no longer needed here. Update some surrounding sections accordingly.
LGTM. Let's merge this one, we will correct RFC6762 in the PR that is already doing that or as an editorial commit.
As discussed at IETF 101, ip-handling should define the problems, and this document should present the mDNS solution.
See URL
LGTM
Change:
EAP-TLS, see Section 4.2.10 of RFC8446 for additional information of the "early_data" extension.  Resumption is handled as described in resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message <del> which is not useful and not expected in EAP-TLS.  The EAP-TLS server always commits to not send any more handshake messages by sending a TLS close_notify alert.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success. </del> <ins> which is not useful and not expected in EAP-TLS.  As a protected success indication RFC3748 the EAP-TLS server always sends TLS application data 0x00, see Section 2.5.  Note that a TLS implementation MAY not allow the EAP-TLS layer to control in which order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpretated as success after the EAP-Request that contains TLS application data 0x00.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS application data 0x00, the EAP-TLS server sends EAP-Success. </ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest

Discussion:
This was discussed and EMU WG IETF 110. URL URL Interop test was done by several implementors during the hackaton. The conclusions was the application data works well as a protected success indication and that close_notify is problematic. Alan DeKok stated that application data will not cause problems for other TLS based EAP methods. The consensus in the WG was to use application data 0x00 as a protected success indication on the EAP-TLS layer. The application data is not controlling the TLS layer. After sending application data (or any other success indication) the EAP-TLS can only send EAP-SUCCESS. The working group argued that the IESG and TLS WG resistance against use application data was as it was used in -13 when it promised that no more handshake messages was sent by the TLS layers. The EMU WG hopes and thinks that the IESG and the TLS WG will be ok with the current use of applicaiton data as a protected success indication on the EAP-TLS layer. Additional changes related to this (protected success and protected failure) will/is done in the EAP State Machnine PR.
There seems to be consensus to use the 0x00 application data as a result indicator for EAP-TLS. See PR
Closing as PR is merged
Change:
2.1. <del> The "Idempotency-Key" request header field describes </del> <ins> "Idempotency-Key" is an Item Structured Header RFC8941.  Its value MUST be a String.  Refer to Section 3.3.3 of RFC8941 for ABNF of "sf- string": </ins> Clients MUST NOT include more than one "Idempotency-Key" header field in the same request.

Discussion:
NAME pls review
While not a mandatory requirement for new fields, using SF has a number of benefits: Well-defined parsing and serialisation algorithms Corresponding reduction of interop and security issues Existing implementation support Possibility of more efficient serialisation support (i.e., binary HTTP headers) URL
Closing this, PR is merged after NAME comment is addressed.
Change:
use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called <del> "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4. </del> <ins> "permanent" address, is not needed.  There are some caveats to note when specifying this property.  First, if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4.  Second, temporary local addresses might involve trading off privacy for performance. For instance, temporary addresses can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </ins> 5.2.13.

Discussion:
NAME PTAL
sec 5.2.12 Using temporary local addresses may break various mechanisms that prove address ownership (e.g QUIC resumption tokens) and therefore impair performance as the client has to re-verify its address.
The default is to use a temporary address for client local address; and to not use it for a server local address. This is the same as most socket APIs. What are you suggesting in the text, NAME
right, a QUIC resumption token will generally contain the client's IP address so that future connections no longer have to go through Retry and anti-amplification mechanisms, which reduce throughput. so IIUC 5.2.12 could say something like "Clients that use temporary local addresses might invalidate server-provided tokens that validate the client's IP addresses (e.g. Sec 8.1.3 of quic-transport), increasing latency."
Add a one-sentence warning that using a temporary address has a potential performance impact on resumption.
Do we wish to refer to RFC 7721?
This looks pretty close ... check these words and submit.
Change:
in microseconds by which the endpoint can delay an acknowledgement.  Values of 2^24 or greater are invalid, and receipt of these values MUST be treated as a connection error of <del> type PROTOCOL_VIOLATION. </del> <ins> type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received <del> max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is specified in microseconds. </del> <ins> max_ack_delay as a connection error of type TRANSPORT_PARAMETER_ERROR.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is specified in microseconds. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.

Discussion:
Use TRANSPORTPARAMETERERROR for communicating errors in TP, rather than using PROTOCOL_VIOLATION.
Change:
attacks as discussed in security-ssrf. When receiving the request, the client instance MUST parse the JSON <del> object and validate the hash value as described in interaction-hash, or else return an "unknown_interaction" error (response-error).  If the hash validates, the client instance sends a continuation request to the AS as described in continue-after-interaction using the interaction reference value received here. </del> <ins> object and validate the hash value as described in interaction-hash. If either fails, the client instance MUST return an "unknown_interaction" error (response-error).  If the hash validates, the client instance sends a continuation request to the AS as described in continue-after-interaction using the interaction reference value received here. </ins> 4.2.3.

Discussion:
The current formulation regarding the client instance's validation of a pushed interaction completion notification can be misunderstood as "client instance must either parse JSON & verify hash or return an error", whereas I think the intended meaning is "client instance must parse JSON and verify hash. If either fails, return an error."
Built To edit notification comments on pull requests, go to your .
Change:
different label in their use of HPKE.  The "message/bhttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "message/bhttp request" <del> label; see repurposing-the-encapsulation-format. </del> <ins> label; see repurposing. </ins> 6.5.

Discussion:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding.

The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me
Change:
different label in their use of HPKE.  The "message/bhttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "message/bhttp request" <del> label; see repurposing-the-encapsulation-format. </del> <ins> label; see repurposing. </ins> 6.5.

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?