jiebi/CodeConvo huggingface dataset:
Code change:
The Frame Type field uses a variable length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient implementations of frame parsing, a frame type MUST use the shortest <del> possible encoding.  Though a two-, four- or eight-byte encoding of the frame types defined in this document is possible, the Frame Type field for these frames is encoded on a single byte.  For instance, though 0x4001 is a legitimate two-byte encoding for a variable-length integer with a value of 1, PING frames are always encoded as a single byte with the value 0x01.  An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION. </del> <ins> possible encoding.  For frame types defined in this document, this means a single-byte encoding, even though it is possible to encode these values as a two-, four- or eight-byte variable length integer. For instance, though 0x4001 is a legitimate two-byte encoding for a variable-length integer with a value of 1, PING frames are always encoded as a single byte with the value 0x01.  This rule applies to all current and future QUIC frame types.  An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION. </ins> 13.

Related discussion:
text: Fixes issue
Thanks for this. It's a lot clearer this way.
restricts frame type varint encoding: The relevant sentence is: This means that the restriction may not apply to frames defined by QUIC extensions (such as the frame in the Delayed Acks_ extension). Must each extension spell out its own frame type encoding rules? It would be easier to change the transport draft to extend the minimal encoding restriction to not-as-yet-specified frames as well.
I read the first sentence as applying to all QUIC frame types, core or extensions. The examples confuse the matter by explicitly mentioning the core frames. Section 19.21 contains some guidance for extension frames, adding a pointer back to the encoding rules from would be a good editorial change.
The sentence I highlighted talks about frames in this document and then these frames, effectively overriding what the first sentence may imply.
yes I think we agree :)
I think we all agree that it can be made more explicit. The first sentence says that the rule for all frame types is that they be minimally encoded. Applying that principle to all frame types defined in this document means that they get one-byte encodings. We should clarify that it's an application of the rule, not a limitation of it.
Why did we have this rule in the first place? It just seems to complicate things in unexpected ways.
NAME See . IIRC the rationale for using minimal varint encoding is that stacks that support only the standardized frames can live with a simpler dispatch scheme that takes one byte as an input (regardless of the dispatch method being a table or a switch clause or whatever). While I do not have a strong opinion regarding that requirement, I'd prefer not revisiting the discussion.
PR has been merged -- closing bug.
Code change:
of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. <del> 6.3. </del> <ins> 7.3. </ins> QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document

Related discussion:
text: Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM
Code change:
client being added to new groups by exhausting all available InitKeys. <ins> 15.5. It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath encrypts a sequence of path secrets to different subtrees of the group's ratchet trees.  These path secrets should be derived in a sequence as described in ratchet-tree-evolution, but the UpdatePath syntax allows the sender to encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that the encrypted path secret encrypted for a given node corresponds to the public key provided for that node. Both of these types of corruption will cause processing of a Commit to fail for some members of the group.  If the public key for a node does not match the path secret, then the members that decrypt that path secret will reject the commit based on this mismatch.  If the path secret sequence is incorrect at some point, then members that can decrypt nodes before that point will compute a different public key for the mismatched node than the one in the UpdatePath, which also causes the Commit to fail.  Applications SHOULD provide mechanisms for failed commits to be reported, so that group members who were not able to recognize the error themselves can reject the commit and roll back to a previous state if necessary. Even with such an error reporting mechanism in place, however, it is still possible for members to get locked out of the group by a malformed commit.  Since malformed Commits can only be recognized by certain members of the group, in an asynchronous application, it may be the case that all members that could detect a fault in a Commit are offline.  In such a case, the Commit will be accepted by the group, and the resulting state possibly used as the basis for further Commits.  When the affected members come back online, they will reject the first commit, and thus be unable to catch up with the group. Applications can address this risk by requiring certain members of the group to acknowledge successful processing of a Commit before the group regards the Commit as accepted.  The minimum set of acknowledgements necessary to verify that a Commit is well-formed comprises an acknowledgement from one member per node in the UpdatePath, that is, one member from each subtree rooted in the copath node corresponding to the node in the UpdatePath. </ins> 16. This document requests the creation of the following new IANA

Related discussion:
text: In preparation for feature-freeze / post-first-WGLC living, this PR removes a few issues that have been discussed and pretty much resolved. It leaves a few OPEN ISSUES that could benefit from analysis during the feature freeze.
Code change:
otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home

Related discussion:
text: …ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.
Code change:
The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to <del> implement two protocols in parallel.  This value may be the empty string. </del> <ins> implement multiple protocols in parallel.  This value may be the empty string. </ins> Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a RFC5785.  The well-known URI for an IdP proxy

Related discussion:
text: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.
Code change:
filter-selectors enclosing the filter-selector that is directly enclosing the identifier). <del> An existence expression may test the result of a function expression (see fnex). </del> <ins> A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function expression (see fnex).  In the latter case, if the function expression is of type "OptionalBoolean" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodes" or one of its subtypes, it tests whether the result is different from "Nothing". </ins> Parentheses MAY be used within "boolean-expr" for grouping.

Related discussion:
text: Add the necessary internal references.
Currently, the existence test description contradicts the intended use of OptionalBoolean functions. We need to be careful if we want to make a special case for OptionalBoolean functions and not open the door to any boolean value being treated similarly.
2023-01-10 Interim: Fix text to properly handle OptionalBoolean. Make sure to indicate that an existence test from a path never gets to the actual value.
Can this issue be elaborated? What is OptionalBoolean? How does this apply to functions? Examples would be great.
Base 09 explains what OptionalBoolean is and uses it in the match and search functions. The current issue will also add some text to explain the way OptionalBoolean functions behave in filter expressions.
E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?
Code change:
filter-selectors enclosing the filter-selector that is directly enclosing the identifier). <del> An existence expression may test the result of a function expression (see fnex). </del> <ins> A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function expression (see fnex).  In the latter case, if the function expression is of type "OptionalBoolean" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodes" or one of its subtypes, it tests whether the result is different from "Nothing". </ins> Parentheses MAY be used within "boolean-expr" for grouping.

Related discussion:
text: The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this.
Ok, let's refactor the ABNF later. ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.
Code change:
The argument is a literal primitive value and the defined type of the parameter is "ValueType". <del> The argument is a Singular Path or "filter-path" (which includes Singular Paths), or a function expression with </del> <ins> The argument is a Singular Query or "filter-query" (which includes Singular Queries), or a function expression with </ins> declared result type "NodesType" and the defined type of the parameter is "NodesType".  Where the declared type of the parameter is not "NodesType", a conversion applies.

Related discussion:
text: XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!
Code change:
allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is <del> equivalent to passing a default messageContext with not values added. </del> <ins> equivalent to passing a default MessageContext with not values added. </ins> If an application wants to override Message Properties for a specific <del> message, it can acquire an empty messageContext Object and add all </del> <ins> message, it can acquire an empty MessageContext Object and add all </ins> desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties. <del> Parameters may be added to a messageContext object only before the </del> <ins> Properties may be added to a MessageContext object only before the </ins> context is used for sending.  Once a messageContext has been used <del> with a Send call, modifying any of its parameters is invalid. </del> <ins> with a Send call, modifying any of its properties is invalid. </ins> Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is

Related discussion:
text: Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM
Code change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, <del> as shown here.  All TLS notation comes from RFC8446; Section 3. </del> <ins> as shown here.  All TLS notation comes from RFC8446, Section 3. </ins> 3.

Related discussion:
text: This addresses . cc NAME NAME NAME NAME NAME
This looks fine, though I'll note that since an HTTPSSVC record is public and the outer ClientHello record is public, it's not unreasonable to pull values from there to put in the public fields since the observer already knows (or can get) them. Restricting them to come only from the ECHOConfig seems unnecessary. I think the key observation in this PR is that the outer ClientHello isn't really offering to establish a TLS connection -- it's a not-crazy-looking wrapper for the actual ClientHello inside the ECHO extension, and the vehicle for the recovery flow. The only things a server can legitimately do are respond to the inner ClientHello or do a recovery handshake. Thus, most of the things you might set on the outer ClientHello are irrelevant; they can be chosen to look innocuous, chosen at random, or copied from the inner ClientHello as the implementation chooses.
NAME does this seem reasonable to you?
Seems reasonable.
Code change:
applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the <del> application requirements and network conditions. </del> <ins> application requirements and network conditions, without requiring a change to the application.  Further, this flexibility does not only enable faster deployment of new feature and protocols, it can also support applications with racing and fallback mechanisms which today usually need to be implemented in each application separately. </ins> This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I- <del> D.ietf-taps-impl documents. </del> <ins> D.ietf-taps-impl documents.  Although following the Transport Services Architecture does of course not mean that all APIs and implementations have to be identical, agreeing on a common minimal set of features and representing them in a similar fashion improves the ability to easily port applications from one system to the another. </ins> 1.1.

Related discussion:
text: Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.
Code change:
maintain backwards compatibility.  However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. <del> This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </del> <ins> This document only describes differences compared to RFC5216.  When EAP-TLS is used with TLS 1.3, some references are updated as specified in updateref.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3.  The specification for how other

Related discussion:
text: The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing
Code change:
If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message. <del> The error code is one of the following, with additional values available in IANA: </del> [[ See issue #79 [15] ]] 3.7.

Related discussion:
text: for
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7273a059b212bf18879f131a5a18d9a776a2918 Inspect the deploy log: Browse the preview:
Error Response: Editor's note: I think we will need a more robust error mechanism, and we need to be more clear about what error states are allowed in what circumstances. Additionally, is the "error" parameter exclusive with others in the return?
As a starting point, I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters. The error code indicates that a request is malformed. The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't identify a client instance (the error code can be ). The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't authenticate a client instance (the error code can be ). The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance (the error code can be , , and so on).
Addressed by , still need error codes for things like token management.
The type of the of the error property in a response is currently ambiguous. In section 3 it is defined as an and in section 3.6 it is defined as a .
NAME thanks for catching that -- looks like both "error" and "errordescription" should be added to the list of parameters. I think the intent might have been for the value of "error" to be an object with "errorcode" and "error_description" fields inside of it though, so it might be better to align things in that direction instead. Do you have thoughts on which is preferable? Interop testing of error conditions is really difficult in practice, so this is a great catch!
Yaron: The AS MUST ignore any unknown extension. Justin: I’m OK with this stance, but it needs to be consistent throughout the protocol, not just at this level. Yaron: we can actually have one policy for an AS that doesn't understand something defined in the RFC (e.g. a token binding method) vs. extensions. Unknown extensions clearly must be ignored, otherwise you cannot deploy extensions incrementally. For RFC elements, this is more nuanced.
Code change:
If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message. <del> The error code is one of the following, with additional values available in IANA: </del> [[ See issue #79 [15] ]] 3.7.

Related discussion:
text: With the guidance on extension points from and error codes from and similar, this should now be covered by the current text.