jiebi/CodeConvo huggingface dataset:
Change:
Firstly, "$" selects the root node which is the argument.  So the result is a list consisting of just the root node. <del> Next, ".a" selects from any input node of type object and selects any value of the input node corresponding to the member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". </del> <ins> Next, ".a" selects from any input node of type object and selects the node of any member value of the input node corresponding to the member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". </ins> Next, "[*]" selects from any input node which is an array and selects all the elements of the input node.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". Finally, ".b" selects from any input node of type object with a <del> member name "b" and selects the value of the input node corresponding to that name.  The result is a list containing "0", "1".  This is the concatenation of three lists, two of length one containing "0", "1", respectively, and one of length zero. </del> <ins> member name "b" and selects the node of the member value of the input node corresponding to that name.  The result is a list containing "0", "1".  This is the concatenation of three lists, two of length one containing "0", "1", respectively, and one of length zero. </ins> As a consequence of this approach, if any of the selectors selects no nodes, then the whole query selects no nodes.

Discussion:
This is a full rebase of branch pr-98 () on current main.
Does this incorporate any changes from the discussions from , or is it a simple rebase?
It is a simple rebase, followed by a number of edits coming from the discussions here. Most of the remaining conversations need some further discussion, so I hope to cover them with my updated slides in a couple of hours.
Looks like a good next step on our path.
Change:
The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </del> <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "wss" URI scheme defined in that document. The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986.

Discussion:
Doesn't this need an IANA considerations section - URL
We are not creating a registry here; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes. No IANA action required. (We do have an IANA action for registering in that existing registry.)
I was thinking of something like this - URL
Yes -- URL
Doh. For some reason, I got hung up on needing a separate reference for RFC6455, but only the URI suffix is registered. I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap-tcp-tls. Sorry for the noise.
: Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use ...
Change:
interpreted by implementations that take part in the controlled experiment making use of these tag keys. <del> 4. </del> <ins> 5. </ins> Out of the possible suffix keys, the suffix key "u-ca" is allocated to indicate the calendar in which the date/time is preferably

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. <del> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to industrial developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. </del> <ins> We notice an active research activity on coding and SATCOM.  That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems. </ins> This document follows the taxonomy of coding techniques for efficient network communications RFC8406.

Discussion:
"We have noticed an active research activity on coding and SATCOM in the past." -- if it's active, it's not in the past. if it's in the past, it's not active. Do you mean 'in the past we have noticed'? that's redundant.
You are right. This leads to some confusion. We propose to change as in PR
Change:
noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. <del> #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </del> <ins> The third concern is the least common, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </ins> Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time

Discussion:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.
Change:
media type (audio, video or data) into its own 5-tuple (bundling by media type). <del> Sending data over multiple 5-tuples is not supported. </del> <ins> Sending data channel data over multiple 5-tuples is not supported. </ins> A receiving implementation MUST be able to receive media and data in all these configurations.

Discussion:
Also do reformatting (xxe equivalent of tidy).
From Ben Campbell's IESG comments:
Change:
the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the <del> media, port, proto, and fmt values stored. </del> <ins> <media>, <port>, <proto>, and <fmt> values stored. </ins> Following the "m=" line, specific processing MUST be applied for the following non-attribute lines:

Discussion:
The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM
Change:
MUST NOT consider these streams to have any meaning upon receipt. The payload and length of the stream are selected in any manner the <del> implementation chooses.  Implementations MAY terminate these streams cleanly, or MAY abruptly terminate them.  When terminating abruptly, the error code H3_NO_ERROR or a reserved error code (http-error- codes) SHOULD be used. </del> <ins> sending implementation chooses.  When sending a reserved stream type, the implementation MAY either terminate the stream cleanly or reset it.  When resetting the stream, either the H3_NO_ERROR error code or a reserved error code (http-error-codes) SHOULD be used. </ins> 7.

Discussion:
I totally misread this passage, so let's make it more emphatic which side of the stream we're talking about.
In Section 6.2.3, we recommend the following about the reserved unidirectional stream types: However, this has a fatal flaw -- it recommends special handling for the grease types, which is precisely the behavior we're trying to disincent with grease. Instead, I think we should move the recommendation to use reserved error codes to the guidance on what to do with unknown stream types, which is currently: This has the same net effect on the grease streams. The change in behavior is on actual unknown-but-real stream types, which will now get grease error codes in response.
+1 lets do this (as an individual)
Actually, scratch that -- it's a misreading. This is a statement about how the sender of the stream should close them, not about behavior on receipt at all. I'll take this as editorial to emphasize that this is purely about how to send them.
Change:
6. <del> The instructions in this document add a recommended column to many of </del> <ins> The instructions in this document add a Recommended column to many of </ins> the TLS registries to indicate parameters that are generally recommended for implementations to support.  Adding a recommended parameter to a registry or updating a parameter to recommended status

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. <del> 4.3. </del> <ins> 5.3. </ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
13.1. <del> Two different key structures are being defined for Elliptic Curve </del> <ins> Two different key structures could be defined for Elliptic Curve </ins> keys.  One version uses both an x and a y coordinate, potentially with point compression.  This is the traditional EC point representation that is used in RFC5480.  The other version uses only the x coordinate as the y coordinate is either to be recomputed or <del> not needed for the key agreement operation.  An example of this is Curve25519 I-D.irtf-cfrg-curves.  [CREF13] </del> <ins> not needed for the key agreement operation Currently no algorithms are defined using this key structure. </ins> 13.1.1. <del> One class of Elliptic Curve mathematics allows for a point to be completely defined using the curve and the x coordinate of the point on the curve.  The two curves that are initially setup to use is point format are Curve 25519 and Curve 448 which are defined in I- D.irtf-cfrg-curves. For EC keys with only the x coordinates, the 'kty' member is set to 1 (EC1).  The key parameters defined in this section are summarized in table-ec1-keys.  The members that are defined for this key type are: contains an identifier of the curve to be used with the key. [CREF14] The curves defined in this document for this key type can be found in table-ec-curves.  Other curves may be registered in the future and private curves can be used as well. contains the x coordinate for the EC point.  The octet string represents a little-endian encoding of x. contains the private key. For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure.  For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure.  For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. 13.1.2. </del> The traditional way of sending EC curves has been to send either both the x and y coordinates, or the x coordinate and a sign bit for the y coordinate.  The latter encoding has not been recommend in the IETF

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming <del> Connections.  This list can be passed to a peer via a signalling protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the remote. </del> <ins> Connections.  These resolved Preconnections will share all other Properties with the Preconnection from which they are derived, though some Properties may be made more-specific by the resolution process. This list can be passed to a peer via a signalling protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the remote. </ins> 6.4.

Discussion:
section 6.3 (Rendezvous) has the following line: PreconnectionBinding := Preconnection.Resolve() If i read the text correctly, I'd propose to change this to Preconnection<> := Preconnection.Resolve()
Agreed, not sure what a is...
Agreed; the text would need to change to compensate as well. NAME is the on an array of preconnections? I don't think we have a notation for this yet ( are event params), but we probably should.
Agree with the change. are new objects derived from the initial by a process like ICE. E.g., once the resolve call has done a STUN exchange to find the external address of a NAT you're behind, you'll get back an object that represents that external address.
lgtm
Change:
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.

Discussion:
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
Change:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del> <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api. <del> Although it is not clear from RFC7710 what protocol should be executed at the specified URI, some readers might have assumed it to be an HTML page, and hence there might be User Equipment assuming a browser should open this URI.  For backwards compatibility, it is RECOMMENDED that the server check the "Accept" field when serving the URI, and serve HTML pages for "text/html" and serve the API for "application/json".  [REVISIT: are these details appropriate?] </del> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a

Discussion:
This removes some text around discovering URLs with 7710[bis] and PvD. That extra context can be handled by those documents. This builds on .
Looks good
Lgtm
LGTM
Change:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use <del> their existing candidates. </del> <ins> their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= lines referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation. </ins> 3.4.2.

Discussion:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI
Change:
The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: <del> An "a=mid" line, as specified in RFC5888, Section 4.  All mid </del> <ins> An "a=mid" line, as specified in RFC5888, Section 4.  All MID </ins> values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp- <del> bundle-negotiation, Section 14. </del> <ins> bundle-negotiation, Section 14.  Note that this does not set the RtpTransceiver mid property, as that only occurs when the description is applied.  The generated MID value can be considered a "proposed" MID at this point. </ins> A direction attribute which is the same as that of the associated transceiver.

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
agent for future reuse. Replace the IP address of the ICE host candidate with its mDNS <del> hostname.  Expose the candidate. </del> <ins> hostname, and expose the candidate as usual. </ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By <del> doing so, only steps 1 and 2 of the above procedure will be executed at the time of gathering candidates. </del> <ins> doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </ins> An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip step 3 and 4 </del> <ins> available network interfaces.  The ICE agent may skip steps 2 and 3 </ins> and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one <del> IP address.  Specifically an ICE agent using an interface with both </del> <ins> IP address.  Specifically, an ICE agent using an interface with both </ins> IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.

Discussion:
Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM
Change:
contain all zero bits are stripped before it is used as the pre_master_secret. <del> Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate. </del> 8.1.3. All ECDH calculations (including parameter and key generation as well

Discussion:
This applies to TLS 1.3 draft 4. The ffdhe groups in Section 7.3.2.5.2 aren't up-to-date with draft-ietf-tls-negotiated-ff-dhe-04: ffdhe2432(256) has been replaced with ffdhe2048(256). ffdhe6144(259) is no more. ffdhe8192(260) has been renumbered to ffdhe8192(259). The note in Section 8.1.3 has text that refers to the old TLS 1.2 and earlier key exchange method, where the server could select any DH-parameters it liked. NamedGroup and NamedGroupList should be added to somewhere in appendix A.
Thanks. WRT to the appendix, I am going to let it get out of date for a draft or two and then do a mass update.
I am now auto-generating the appendix, so it will hopefully get less out of sync
Grubba, PTAL at the Pull Request above.
Looks good to me.
The latest FFDHE-draft (06) has reintroduced FFDHE-6144, and replaced FFDHE-2048 with FFDHE-2432, so this issue should probably be reopened.