jiebi/CodeConvo huggingface dataset:
Change:
The "extension_data" field of this extension contains a "supported_signature_algorithms" value: <del> %%% Signature Algorithm Extension enum { /* RSASSA-PKCS-v1_5 </del> <ins> %%% Signature Algorithm Extension enum { /* RSASSA-PKCS1-v1_5 </ins> algorithms */ rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601),

Discussion:
RFC 3447 refers to it as RSASSA-PKCS1-v15, not RSASSA-PKCS-v15.
Change:
A literal header field with name reference representation encodes a header field where the header field name matches the header field name of an entry in the static table, or the header field name of an <del> entry in the dynamic table with an absolute index less than the Base. </del> <ins> entry in the dynamic table with an absolute index less than the value of the Base. </ins> This representation starts with the '01' two-bit pattern.  The following bit, 'N', indicates whether an intermediary is permitted to

Discussion:
This change has been suggested by afrind at URL on the basis that the Base is a count, and comparing an index to a count feels awkward.
Change:
providing security services.  The use of COSE, like JOSE and CMS, is only in store and forward or offline protocols, different solutions would be appropriate for online protocols although one can use COSE <del> in and online protocol after having done some type of online key </del> <ins> in an online protocol after having done some type of online key </ins> establishment process.  Any application which uses COSE for security services first needs to determine what security services are required and then select the appropriate COSE structures and cryptographic

Discussion:
Add in response for IANA review on all documents SecDir review by Nancy on -algs GenArt review on -struct
Change:
A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del> <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the <del> payload type fo the primary codec, as specified in RFC4588, </del> <ins> payload type of the primary codec, as specified in RFC4588, </ins> Section 8.1. For each supported FEC mechanism, a corresponding "a=rtpmap" line

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance <del> (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. </del> <ins> (referred to in that document as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols. For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent.  However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. </ins> 1.2.

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
MUST be used for identification; otherwise, the "m=" section index is used instead. <del> Implementations MUST be prepared to receive objects with some fields missing, as mentioned above. </del> <ins> Other than the "m=" section index, all IceCandidate fields are optional, and implementations MUST NOT reject a candidate simply because an optional field is missing. </ins> 3.5.3.

Discussion:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout
Change:
In this theoretical case, the HTTP 201 response to the HTTP POST request would look like: <del> 5. </del> <ins> 6. </ins> HTTPS SHALL be used in order to preserve the WebRTC security model. <del> 6. </del> <ins> 7. </ins> The link relation type below has been registered by IANA per Section 4.2 of RFC8288. <del> 6.1. </del> <ins> 7.1. </ins> Relation Name: ice-server

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested
Change:
padded_length is greater than 260. A list of extensions that the client can take into consideration <del> when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room for additional features in the future.  An extension may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ESNIConfig content. </del> <ins> when generating a Client Hello message.  The purpose of the field is to provide room for additional features in the future.  The format is defined in RFC8446; Section 4.2.  The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ESNIConfig content. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is

Discussion:
Followup on . Looks like ESNIConfig is the only ESNI structure that has extensions, now that we've delegated the key delivery to HTTPSSVC. Should I avoid reflowing the text?
states: same type in a given extension block. The ESNI draft should probably explicitly restate this for both and . I'd be happy to make a PR if need be. Thanks!
NAME if you could propose text that takes the new ESNIConfig and HTTPSSVC change into account, that'd be great!
Fixed by .
Change:
selected cipher suite; see hp-aes and hp-chacha. fig-sample shows an example long header packet (Initial) and a short <del> header packet. fig-sample shows the fields in each header that are covered by header protection and the portion of the protected packet payload that is sampled. </del> <ins> header packet (1-RTT). fig-sample shows the fields in each header that are covered by header protection and the portion of the protected packet payload that is sampled. </ins> Before a TLS cipher suite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that cipher suite.

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.
Change:
and do not contribute to any per-flow or connection-wide data limit. The risk associated with not providing flow control for DATAGRAM <del> frames is that a receiver may not be able to commit the necessary resources to process the frames.  For example, it may not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </del> <ins> frames is that a receiver might not be able to commit the necessary resources to process the frames.  For example, it might not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </ins> 5.3. DATAGRAM frames employ the QUIC connection's congestion controller. <del> As a result, a connection may be unable to send a DATAGRAM frame </del> <ins> As a result, a connection might be unable to send a DATAGRAM frame </ins> generated by the application until the congestion controller allows it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop

Discussion:
There are several instances of lowercase "may" in this document. It is ambiguous if these are normative requirements or not.
Could you elaborate on why it's ambiguous? We have a reference to RFC 8174.
I sometimes assume typos :) If you're happy the present document is correct, I will close this issue
I'm not aware of errors like this, do you have any specific ones in mind?
Gah, fat fingered accidental close. The example that triggered opening this issue is below, I had to read this several times. Perhaps that's just a sign that editorial tweaks would help, regardless of the exact words in use
I can fix this
Thanks!
Change:
4.2. <del> WebTransport streams have states that mirror the states of QUIC streams (Section 3 of RFC9000) as closely as possible to aid in ease of implementation. </del> <ins> WebTransport streams have identifiers and states that mirror the identifiers ((Section 2.1 of RFC9000)) and states (Section 3 of RFC9000) of QUIC streams as closely as possible to aid in ease of implementation. WebTransport streams are identified by a numeric value, or stream ID. Stream IDs are only meaningful within the WebTransport session in which they were created.  They share the same semantics as QUIC stream IDs, with client initiated streams having even-numbered stream IDs and server-initiated streams having odd-numbered stream IDs. Similarly, they can be bidirectional or unidirectional, indicated by the second least significant bit of the stream ID. </ins> Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in

Discussion:
Attempting to be minimal and just point at RFC9000.
Do we talk about the stream ID numbering space here? It could be completely scoped to the WebTransport session, which is different than H3. Originally posted by NAME in URL
Thanks for doing that.
Change:
given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its arguments are instances of "ValueType".  If the first argument is not a string or the second argument is not a string conforming to I- D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse". Otherwise, the string that is the first argument is searched for at least one substring that matches the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if such a substring exists and "LogicalFalse" otherwise. </del> <ins> Its arguments are instances of "ValueType" (possibly taken from a singular query, as for the first argument in the example above).  If the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".  Otherwise, the string that is the first argument is searched for at least one substring that matches the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if such a substring exists and "LogicalFalse" otherwise. </ins> 2.6.8.

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
Once a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection.  QUIC provides protocol <del> negotiation, stream-based multiplexing, and flow control.  An HTTP/3 endpoint can be discovered using HTTP Alternative Services; this process is described in greater detail in discovery. </del> <ins> negotiation, stream-based multiplexing, and flow control.  Discovery of an HTTP/3 endpoint is described in discovery. </ins> Within each stream, the basic unit of HTTP/3 communication is a frame (frames).  Each frame type serves a different purpose.  For example,

Discussion:
Clients MAY establish QUIC connections using the host and port indicated in the URL for "https" URLs only Non-"https" origins are able to be delegated using Alt-Svc Cribs a lot of text from .
Are we waiting on a consensus call for this?
The call has been issued and is running until Saturday UTC. If you have comments, please make them now!
Excellent! Can't wait for this to land. (Looks like I need to finish reading my WG email :>)
NAME I'll get your comments as a separate PR.
S 2.4. This text seems quite a bit more restrictive than S 9.1.1. of RFC 7540, which just allows reuse as long as the SAN is present in the cert. Is that intentional?
I think that the intent was to present equivalent text. Though the thinking about coalescing has evolved some in the meantime. We should discuss where we think the state of this discussion is at and see if we can capture something sensible.
Yes, it'd be good to capture something more up-to-date if we can come to consensus on that. Is explicit signal meant to indicate DNS and/or ORIGIN frame? If so, maybe call those two out as examples?
NAME I think the dilemma is that some of those things don't exist yet for H3. For example, Mike did some earlier work to redefine ALTSVC frame for H3 but there is yet to be equivalent for ORIGIN or secondary certs.
Yes, it's intentional. RFC7540 allows coalescing based on the cert and DNS, because you're connected to the authoritative origin. However, HTTP/3 is never connected on the authoritative endpoint for an http(s?):// URL, so you need something else to tell you that's okay. This could be an Alt-Svc record for that origin delegating to the same UDP port. This could be an ORIGIN-for-H3 frame telling you to throw caution to the wind and trust the cert, if the client thinks that's sensible.
Discussed in London; also blocked on URL defining how a client decides which connection / server to ask for a given resource.
Discussed in ZRH. Waiting for HTTP changes to materialize.