jiebi/CodeConvo huggingface dataset:
Change:
to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero <del> checksum field. </del> <ins> checksum field, and the enumerated value "Full Coverage" means that the entire Message needs to be protected by a checksum. </ins> 8.1.2.

Discussion:
This is my attempt to address items 2, 3 and 4. My suggestion is not to do anything about item 1 (referencing -arch), because we already do this so often and IMO it won't improve the document to add yet another reference. See also the discussion in .
These are some minor comments (mostly editorial) /nits, that would be best to address before going for IETF Last call but can be taken care during or after the IETF LC. Section 3 should reference architecture document. We are using concepts and definitions from the architecture document and lets be specific about it. Of we can mention this in the terminology section. Section 8.1.1: the description of Full Coverage is given in section 9.1.3.6. Either forward ref that section where it is explained or move the text in section 8.1.1. Section 8.1.6 : says - >When the capacity profile is set to a value other than Default, z Transport Services system SHOULD select paths and configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified. here "z" ?? Section 9.1.3.1 : says - >The Lifetime specifies how long a particular Message can wait to be sent to the Remote Endpoint before it is irrelevant and no longer needs to be (re-)transmitted. can we describe whether this wait till the Message is sent out of the TAPS system or will the wire (which might include other processing delay by the system)?
Regarding the first item: I think this is overkill. Section 1 begins with: "This document specifies an abstract application programming interface (API) that specifies the interface component of the high-level Transport Services architecture defined in [I-D.ietf-taps-arch]." Section 2 begins with "The design of the API specified in this document is based on a set of principles, themselves an elaboration on the architectural design principles defined in [I-D.ietf-taps-arch]. " - adding something like this to section 3 or section 1.1 too is not making anything clearer, IMO.
The problem I see is that in section 3 we are describing the Connection and Preconnection again.

Note that I am using the word "describing" as those are already defined and described in the Arch doc we just need to ref them or say see there in the Interface doc. I would like to avoid the situation that readers are confused and any future update to the Interface doc is problematic to decide which definition/description to preserve. I think just adding a sentence in the terminology section saying things are defined in Arch document make sense. But hej, this is a minor comment so...
Change:
detection as long as ephemeral ciphers are used.  It does not provide downgrade protection when static RSA is used. <ins> Note: This is an update to TLS 1.2 so in practice many TLS 1.2 clients and servers will not behave as specified above. </ins> Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the Random value to encode the time since the UNIX epoch.  The sentinel value above was selected to avoid conflicting with any valid TLS 1.2

Discussion:
Chairs have judged that there is consensus to merge, see: URL It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, URL Procedurally, we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time. Thanks, J&S , Eric Rescorla wrote:
Change:
6.2. <del> To modify resource state, clients usually GET a representation from the server, process it locally, and transfer the resulting state back to the server with a PUT.  Sometimes, however, the state can only be modified on the server side, for instance, because representations would be too large to transfer or part of the required information shall not be accessible to clients. In this case, resource state is modified by calling a function.  This is usually modeled with a POST request, as it leaves the behavior semantics completely to the server. </del> <ins> To modify resource state, clients usually use GET to retrieve a representation from the server, modify that locally, and transfer the resulting state back to the server with a PUT (see sec-uniform- interface).  Sometimes, however, the state can only be modified on the server side, for instance, because representations would be too large to transfer or part of the required information shall not be accessible to clients.  In this case, resource state is modified by calling a procedure (or "function").  This is usually modeled with a POST request, as this method leaves the behavior semantics completely to the server.  Procedure calls can be divided into two different classes based on how long they are expected to execute: "instantly" returning and long-running. </ins> 6.2.1. <ins> When the procedure can return within the expected response time of the system, the result can be directly returned in the response.  The result can either be actual content or just a confirmation that the call was successful.  In either case, the response does not contain a representation of the resource, but a so-called action result. Action results can still have hypermedia controls to provide the possible transitions in the application state machine. </ins> 6.2.2. <ins> When the procedure takes longer than the expected response time of the system, or even longer than the response timeout, it is a good pattern to create a new resource to track the "task" execution.  The server would respond instantly with a "Created" status (HTTP code 201 or CoAP 2.01) and indicate the location of the task resource in the corresponding header field (or CoAP option) or as a link in the action result.  The created resource can be used to monitor the progress, to potentially modify queued tasks or cancel tasks, and to eventually retrieve the result. Monitoring information would be modeled as state of the task resource, and hence be retrievable as representation.  The result - when available - can be embedded in the representation or given as link to another sub-resource.  Modifying tasks can be modeled with forms that either update sub-resources via PUT or do a partial write using PATCH or POST.  Canceling a task would be modeled with a form that uses DELETE to remove the task resource. </ins> 6.2.3. GET is cachable, good for static information such as look-up tables

Discussion:
The term "function" might imply idempotence and/or freedom from side effects, depending on who you ask. RPC uses the term "procedure" in order to be more general.
NAME would you suggest s/function/procedure/g ?
Changed to "procedure"
Change:
4.4. <del> HTTP/3 server push is similar to what is described in HTTP/2 HTTP2, but uses different mechanisms. </del> <ins> Server push is an interaction mode introduced in HTTP/2 HTTP2 which permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request.  This trades off network usage against a potential latency gain.  HTTP/3 server push is similar to what is described in HTTP/2 HTTP2, but uses different mechanisms. </ins> Each server push is identified by a unique Push ID.  This Push ID is used in a single PUSH_PROMISE frame (see frame-push-promise) which

Discussion:
The transition to "Push Streams" has no preceding mention of server push. This adds a reference to the correct section of RFC7540.
If mention of server push is desired before mention of push stream, would it be simpler to move the final sentence of the paragraph to the start?
Maybe this would be better if section 4 was moved after section 6? Then the concepts would be explained before going into the framing. I'd also like to reorder/renumber all the push frame types so they're all adjacent to one another and in a sensible order. Is there a reason they're numbered as they are? If not, I'll open an issue to renumber them.
There's already an issue to reorder some of the sections, so I'm happy to consider this as part of the same discussion. As to the numbering, the primary reason is maintaining the same frame IDs for things that stayed over from HTTP/2 -- PUSHPROMISE has the same ID, CANCELPUSH has the ID that HTTP/2 used for RSTSTREAM, and DUPLICATEPUSH is brand new and so pushes into unallocated space.
Given that is in now, do you still see this as a problem?
I think the Server Push section still lacks a simple explanation of what the push does. A sentence like what I added in this PR at the beginning would help that. Currently the Server Push section goes directly into mechanics. URL "HTTP/3 server push is similar to what is described in HTTP/2 {{!HTTP2}}, but uses different mechanisms. Each server push is identified by a unique Push ID. ..." I'd add more to the first paragraph in case people don't want to read the H2 draft.
I think I'd prefer for the reference to be to 4.4 of the current draft instead, since that does point to RFC7540 and has more context as well.
Whoops -- which also doesn't have the two-sentence explanation of what push is. That's up in the intro. Let me copy that over to 4.4.
Thanks for the added text Mike, it looks great. I'm happy with this, so it's up to you to decide when this is ready to merge.
Change:
This structure is placed in the RRData section of a TXT record as a base64-encoded string.  If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings <del> as per Section 3.1.3 of RFC4408. </del> <ins> as per Section 3.1.3 of RFC4408.  Servers MAY supply multiple ESNIKeys values, either of the same or of different versions.  This allows a server to support multiple versions at once. </ins> The name of each TXT record MUST match the name composed of _esni and the query domain name.  That is, if a client queries example.com, the

Discussion:
Do we need it.
For ESNIKeys (the DNS record) I do not think we need a version for the following reasons: I think we would prefer adding extensions rather than making incompatible changes we always have the freedom to pick a new prefix (e.g. ) or a new RR type when making incompatible changes an incompatible change will require the client to query for two DNS records anyways For the ESNI extension, I also do not think that we need a version field. When we define an extension sometime in the future, we could the advertise the support as an extension in the ESNIKeys to instruct the clients that support that extension to send a CH extension that uses a different extension ID than the ESNI extension.
A lot of other TXT records have a version in them. It turns out that if you do that you can query for TXT records and get multiple answers back. Then, you pick those with the version you like. That's one query. I'm tempted to suggest that the first octet (or two) be used for a version number. It's cheap.
I'm concerned about how we iterate on these in the field. They're not tied to TLS version, so what if we decide to change the formats, as we are discussing in
a magic number (including version) is a pretty decent idea. right now _esni is in its own namespace but you can imagine someone doing a txt record that applies to every dns response so we would want to disambiguate that as well. take note to update the "concat multiple records" rule if we go down this path..
I think that having version is a good idea in sense that it allows to do experiments before the standardization completes.
Change:
RFC5506 MUST be implemented to signal reduced-size RTCP messages. <ins> RFC4588 MUST be implemented to signal RTX payload type associations. </ins> RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:

Discussion:
kramdown-rfc2629 inserts a non-breaking space when expanding , which xml2rfc subsequently mangles to produce invalid XML. Rather than deal with that, insert the boilerplate with regular spaces instead. Note that this is necessary to make work properly, as that tool drops the non-breaking whitespace character between "BCP" and "14".
URL (I need to follow up regarding the use of non-breaking whitespace generally).
This seems fine, but I assume you've separately filed the appropriate bugs to fix the regular tools?
Change:
If a local MediaStreamTrack has been associated, and FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC <del> SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del> <ins> SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr]

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
If the server sends a NewSessionTicket message, the corresponding ESNI PSK MUST be ignored by all other servers in the deployment when not negotiating ESNI, including servers which do not implement this <del> specification.  This may be implemented by adding a new field to the server session state which earlier implementations cannot parse. </del> <ins> specification. </ins> This restriction provides robustness for rollbacks (see misconfiguration).

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
4.1.9. <ins> [[TODO: Revise if the W3C API uses different stuff here.]] The canTrickle property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: No SDP has been received from the other side, so it is not known if it can handle trickle.  This is the initial value before setRemoteDescription() is called. SDP has been received from the other side indicating that it can support trickle. SDP has been received from the other side indicating that it cannot support trickle. As described in sec.ice-candidate-trickling, JSEP implementations always provide candidates to the application individually, consistent with what is needed for Trickle ICE.  However, applications can use the canTrickle property to determine whether they can actually do Trickle ICE, i.e. safely send an initial offer or answer followed later by candidates as they are gathered.  As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickle against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent. 4.1.10. </ins> The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to be changed during the session.  The effects of this method call

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
The context ID to register. <del> A string of comma-separated key-value pairs to enable extensibility.  Keys are registered with IANA, see iana-keys. The ABNF for the Extension String field is as follows (using syntax from Section 3.2.6 of RFC7230): </del> <ins> See context-ext. </ins> Note that these registrations are unilateral and bidirectional: the sender of the frame unilaterally defines the semantics it will apply

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
It is possible for a server to be configured with multiple Oblivious Proxy Resources, each for a different Oblivious Request Resource as <del> needed. </del> <ins> needed.  If the goal is to support a large number of Oblivious Request Resources, clients might be provided with a URI template TEMPLATE, from which multiple Oblivious Proxy Resources could be constructed. </ins> 9.3.

Discussion:
Truly, the most interesting forwarding is what occurs at the Oblivious Request Resource, but this is a point of inflexibility that some people struggle with. No point in hiding how we might intend for a generic proxy to operate. The alternatives people invent are likely to be worse if we don't at least point in the rough direction of a good solution.
Resource and the Oblivious Request Resource. This means that any encapsulated request sent to the Oblivious Proxy Resource will always be forwarded to the Oblivious Request Resource. This constraint was imposed to simplify proxy configuration and mitigate against the Oblivious Proxy Resource being used as a generic proxy for unknown Oblivious Request Resources. The proxy will only forward for Oblivious Request Resources that it has explicitly configured and allowed. This seems like it's pretty inflexible. I wonder if maybe a compromise would be some kind of URL pattern?
I agree that it's written as very inflexible — I'd be happy to see this change for wording. I've personally interpreted this, though, to mean that the mapping could coincide with a URI template, but it's up to the proxy of what to do. So, one proxy could say: maps to But another could say: maps to Both of these are 1:1 technically. The latter case needs to be careful that it has correct ACLs to not allow arbitrary access, but it's still a mapped resource.
Yes, I think this explanation does a lot to clarify the possible approaches.