jiebi/CodeConvo huggingface dataset:
Code change:
7.3.2.1. <del> When the server cannot decrypt or does not process the </del> <ins> When the server rejects ECH or otherwise ignores </ins> "encrypted_client_hello" extension, it continues with the handshake using the plaintext "server_name" extension instead (see server- behavior).  Clients that offer ECH then authenticate the connection

Related discussion:
text: In places, the current draft doesn't make a clear distinction between rejection and decryption failure. In particular "cannot decrypt" can be interpreted either: "the client-facing server doesn't recognize the configuration specified by the client"; or "the client-facing server recognizes the configuration but decryption fails". This change resolves this ambiguity. Addresses issue .
Two sections suggest to ignore the extension on decryption failure, but one suggests to send an alert. What should happen? Ignoring the extension on unrecognized failures sounds reasonable in order to "not stick out". However, it is not entirely unambiguous what to do if a valid ECHConfig is found but decryption fails. says: says: says:
I think the first two statements apply when the config_digest doesn't correspond to a known ECHConfig (i.e., "I can't decrypt this"); the last is when the ECHConfig is known, but decryption fails ("I should be able to decrypt this, but the ciphertext is invalid"). The text could be a lot clearer here.
NAME Yes, your interpretation is correct. I think this is the result of a number of uncoordinated changes.
Closing as resolved.
Code change:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del> <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Related discussion:
text: Deploy Preview for gnap-resource-servers-editors-draft ready! Built Explore the source changes: 611af53328d71bac58f517702c5775a9c514d88d Inspect the deploy log: Browse the preview:
Code change:
TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

Related discussion:
text: attributes. As far as I can tell this can happen: On re-offers On any answer because nothing requires the offerer to generate bundle tags in the same order as m= lines (even though the data channel m= line is last) See: URL
NAME PTAL
Say you have a session where only a data channel is created. SDP looks like [session boilerplate] a=group:BUNDLE d1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 ... Now, a media m= section is added (i.e. after first o/a). SDP becomes: [session boilerplate] a=group:BUNDLE d1 a1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 a=ice-ufrag:ABCD ... m=X audio UDP/TLS/RTP/SAVPF 0 a=mid:a1 [no ice-ufrag or TRANSPORT attrs, since bundled] Now, where does a=rtcp-mux go? It can't go into because of the language that states Thoughts on how to resolve?
Could generating a session description be split into two parts? First, generate media-level attributes for each "m=" section, then transport-level attributes for the BUNDLE group and each non-bundled "m=" section.
That would be my preference, i.e., jam it into the BUNDLE group m= section, regardless of media type, as that's conceptually simplest, and easily handled here in JSEP. Either way, I suspect this will require changes upstream in the bundle spec.
So ... is it really not allowed in the d1 section. Unknown attributes are allowed in the d1 section, they are just ignored if they have no meaning for the data channel. Agree this sounds like something that will hit bundle.
Couldn't you do a=group:BUNDLE a1 d1 I would have thought this was prohibited, but is it really? URL
I think that's legal, but that approach doesn't work in the general case, where "m=" section A has TRANSPORT attributes that only it uses, and section B has TRANSPORT attributes that only it uses. BUNDLE just needs to allow an "m=" section to contain attributes that it normally wouldn't contain if it wasn't bundled. (If this isn't already allowed).
NAME any action needed here?
Code change:
TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

Related discussion:
text: I think what we want in this scenario is to put "a=rtcp-mux" and "a=rtcp-rsize" in the data channel section. The simplest way would be to say: Which I guess could only happen in subsequent offers.
Let's go with what NAME suggests, although this makes it a bundle problem.
What would you say is needed on the BUNDLE side? Just clarification that the offerer BUNDLE-tag m= section should contain the union of all TRANSPORT and IDENTICAL attributes used by the BUNDLE group?
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best guess is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
+1 with Taylor proposal to put RTP related things in data m= section if it is first and good with making this be bundles problem
NAME NAME I assume that you think that on initial offers this cannot happen because data comes last?
NAME Right. I can't think of a scenario where it wouldn't go last in an initial offer.
Agreed.
Oh, except that you aren't required to make the bundle group in order So you can have
I don't think the question whether you are allowed or not to place an RTP attribute in a non-RTP m= section is a pure BUNDLE issue. One needs to check what the specs defining those attributes say.
every SDP spec has to accept (and ignore) lines it does not understand ...
I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their inclusion into a non-media section. Generally, I think BUNDLE can define the rules for this sort of thing, without fear that it will somehow contradict some other spec.
NAME NAME You may want to chime in on the current MMUSIC thread. I agree with you, but it seems to be going in the direction of "you can't do this".

I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their >inclusion into a non-media section.
Code change:
TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

Related discussion:
text: It may not be explicitly stated, but since the semantics is about RTP and RTCP I think it is implicit. Having said that, I personally have no problem with allowing the attributes in non-RTP m- sections. I just want to verify that there is no text that has to be modified somewhere, and/or whether there is some text that has to be added somewhere :)
Resolved by
Looks good.
Code change:
approach 2^(-L/2), that is, the birthday bound.  For the algorithms described in this document, that probability is one in 2^64. <del> In some cases, inputs shorter than the full size required by the packet protection algorithm might be used. </del> To prevent an attacker from modifying packet headers, the header is transitively authenticated using packet protection; the entire packet header is part of the authenticated additional data.  Protected

Related discussion:
text: Now that we require a minimum packet size, this is no longer true.
Is this no longer true for the algorithms defined in the spec, or no longer true for any packet protection algorithms for any AEAD? It might be worth moving the note to the end of 5.4.1 instead.
Code change:
private key that signs the delegated credential also implictly revokes the delegated credential. <del> 6.3. </del> <ins> 6.4. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

Related discussion:
text: Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.
Code change:
is the first three fields of MLSCiphertext: When parsing a SenderData struct as part of message decryption, the <del> recipient MUST verify that the LeafNodeRef indicated in the "sender" field identifies a member of the group. </del> <ins> recipient MUST verify that the leaf index indicated in the "leaf_index" field identifies a non-blank node. </ins> 8.

Related discussion:
text: This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.
Code change:
REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be <del> stable at the AS if the AS includes an access token.  The client instance MUST use this value exactly as given when making a continue-request. </del> <ins> stable at the AS.  The client instance MUST use this value exactly as given when making a continue-request. </ins> RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and

Related discussion:
text: In the current version, the AS must include an access token. "if the AS includes an access token" sounds like the inclusion of an access token is optional.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 323dd6c268368857c2d9942048f94658b806b8ad Inspect the deploy log: Browse the preview:
Code change:
2.4.6. <del> The "match" function extension provides a way to check whether (the </del> <ins> The "match()" function extension provides a way to check whether (the </ins> entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.

Related discussion:
text: Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.
Code change:
This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints <del> specified to operate over QUICv1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2. </del> <ins> specified to operate over QUIC version 1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUIC version 2. </ins> All QUIC extensions defined to work with version 1 also work with version 2.

Related discussion:
text: , , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM
Code change:
The following fields are defined in this document; all other fields are as defined in the cited documents. <del> Value of the negotiated CID. </del> <ins> Value of the negotiated CID (variable length). </ins> 1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext. </del> <ins> The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer). </ins> The length MUST NOT exceed 2^14. Note "+" denotes concatenation.

Related discussion:
text: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.
Code change:
validity period.  In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than <del> the maximum validity period.  This mechanism is described in detail in client-and-server-behavior. </del> <ins> the maximum validity period or that extends beyond the validity period of the delegation certificate.  This mechanism is described in detail in client-and-server-behavior. </ins> It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge

Related discussion:
text: Added text to address issue
There is a potential issue for credential renewal. On the credential owners side there is a risk that if the owner entirely depends upon the delegated credential lifetime to renew it could miss the fact that the underlying certificate has already expired will cause clients to fail validation. This can be addressed by adding the following to section 3: "Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or extend beyond the validity period of the X.509 certificate" Or there could be an addition to the operational section that talks about renewal. "5.2 Credential Renewal Credentials must be renewed before they expire and before the issuing X.509 certificate expires. "
addressed by pull request
Code change:
Security considerations for JSONPath can stem from <del> attack vectors on JSONPath implementations, and </del> <ins> attack vectors on JSONPath implementations, attack vectors on how JSONPath queries are formed, and </ins> the way JSONPath is used in security-relevant mechanisms.

Related discussion:
text: We wanted to add examples, but maybe we can merge this as is. Marking as ready for review.
Let's get this in and polish it later.
Code change:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del> <ins> Next, "[*]" selects from an input node of type array all its elements (if the input note were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input

Related discussion:
text: Lots of niggly details re blank space. Style consistency, some missing places (assuming we stick with the liberal approach). Allowing "in" before or after a newline or tab. Adding some legend to the only remaining table with XPath content in the main document.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?