jiebi/CodeConvo huggingface dataset:
Code change:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Related discussion:
text: one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular <del> Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent </del> <ins> Queries are Normalized Paths.  For example, "$[-3]" is a singular query, but is not a Normalized Path.  The Normalized Path equivalent </ins> to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)
Code change:
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.

Related discussion:
text: example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <ins> Functions are referred to using the function name followed by a pair of parentheses, as in "fname()". </ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all
Code change:
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.

Related discussion:
text: 2.3.2.2. <del> A "wildcard" selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </del> <ins> A wildcard selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </ins> resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist. <del> The "wildcard" selector selects nothing from a primitive JSON value </del> <ins> The wildcard selector selects nothing from a primitive JSON value </ins> (that is, a number, a string, "true", "false", or "null"). 2.3.2.3.
Code change:
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.

Related discussion:
text: Queries: <del> The examples in tbl-wild show the "wildcard" selector in use by a child segment: </del> <ins> The examples in tbl-wild show the wildcard selector in use by a child segment: </ins> The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it
Code change:
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.

Related discussion:
text: If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del> <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.
Code change:
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.

Related discussion:
text: 2.4.4. <del> The "length" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </del> <ins> The "length()" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "ValueType" (possibly taken from a singular query, as in the example above).  The result also is an
Code change:
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.

Related discussion:
text: 2.4.5. <del> The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </del> <ins> The "count()" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </ins> Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that
Code change:
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.

Related discussion:
text: 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.
Code change:
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.

Related discussion:
text: 2.4.7. <del> The "search" function extension provides a way to check whether a </del> <ins> The "search()" function extension provides a way to check whether a </ins> given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.
Code change:
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.

Related discussion:
text: 2.4.8. <del> The "value" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </del> <ins> The "value()" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "NodesType" (possibly taken from a "filter-query", as in the example above).  The result is an
Code change:
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.

Related discussion:
text: result is "Nothing". Note: a singular query may be used anywhere where a ValueType is <del> expected, so there is no need to use the "value" function extension </del> <ins> expected, so there is no need to use the "value()" function extension </ins> with a singular query. 2.4.9.
Code change:
I'm going to guess that order is not significant. But imagine that an endpoint would only honor a request for N addresses but the requester asks for N+Y. The endpoint has to pick a subset somehow.
What do you mean by "is the list ... significant"? I don't understand the comment about subsetting either --- if you ask for N+Y addresses and get back only N, you have N usable addresses (ranges)
How does the other end decide the which N to pick? Without declaring if the request order is significant, then there can be no expectations of behaviour and we might find interop problems if assumptions don't align.
If you request, say, 4 specific addresses, and the other side can satisfy 3 of the requests because they're still available, it will include those 3. It's implementation-defined it if wants to provide a 4th address that is not the one you requested, or NAK it. However at no point in time was order significant --- you asked for all of these addresses, not any of these addresses.
Friendly amendment: it may include those 3. It could also choose to only assign one, or a different address entirely if the implementation was so inclined.
You are pedantically correct :). I was trying to give a specific worked example.
This design seems reasonable. It might help to state clearly somewhere that the value of the request ID has no significance other than as a unique handle, and that the ordering of and in a single capsule has no significance. This is in contrast to the ROUTE_ADVERTISEMENT where the ordering of things is very significant.
That's a good suggestion Lucas.
My intention when writing this was for the order in the lists to not carry semantics, and similarly for the request ID to only exist for unicity. We should spell that out clearly. One thing we could do however, is saying that request IDs in ADDRESS_REQUEST MUST be increasing, to make duplicate detection easier on the receiver. If we do it, it adds a constraint on the sender and means that the receiver will check, while if we don't add the constraint then receivers won't bother to check. Any thoughts on this point?
I have no strong feeling about the potential to add such rules.
NAME can you propose text here?

Related discussion:
text: If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <ins> Note that the ordering of Requested Addresses does not carry any semantics.  Similarly, the Request ID is only meant as a unique identifier, it does not convey any priority or importance. </ins> 4.7.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the
Code change:
Say for example that A and B have the same IP Version and they have the same or overlapping Start IP Address / End IP Address ranges. A's IP Protocol is zero (the wildcard) whereas B's is non-zero. That causes a weird kind of overlap even though all the requirements are followed. Is it worth disallowing in the spec?
Earlier in this section, the version is defined as such: I think then this is OK, since zeros aren't allowed in route advertisements. NAME that sound OK?
The IP Verson cannot be zero in the ROUTEADVERTISEMENT, but the IP Protocol can: The following ROUTEADVERTISEMENT follows the requirements (the IP Protocol of A is lower than the IP Protocol of B), yet there is an overlap:
Oh, I see, I misread. I do think that it makes sense to put the wildcard first — so 0 shows up before others. And then the more specific protocol rules can potentially have different ranges. I still think this is acceptable to leave as-is.

Related discussion:
text: meet these requirements, it MUST abort the IP proxying request stream. <ins> Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has IP protocol set to zero and the other set to non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way.  Validating this requirement is OPTIONAL, but if an endpoint detects the violation, it MUST abort the IP proxying request stream. </ins> 5. The mechanism for proxying IP in HTTP defined in this document allows
Code change:
From Vinny Parla on the :
I don't think we need to make normative changes to the protocol, but adding a note for implementers that they might want to treat extension headers differently that other IP protocols sounds like a good change. Some additional review comments from an internal review that I wanted to share with you. Section 4.6 has a minor issue as the IANA registry mixes IPv6 extension header with layer-4 headers. It should also specify the use of RFC 5952 for representing IPv6 addresses. However, this can be ignored for now. Section 4.7.1 unsure whether "IP Version" field is useful as it can be derived from "IP Address" length/notation, also not critical but perhaps this would reduce unnecessary information. There is also a minimum 68-byte MTU for IPv4 ;-) - not sure that is important, but wanted to share. The recursive DNS server info (found in RA and DHCP), is not present. Was this an intentional decision or perhaps something that was not considered for some reason? There is no discussion of link-local addresses / ULA (I would expect both end of the 'tunnel' to have link-local addresses), or link-local multicast (e.g., ff02::1). Or perhaps the IP proxy send an IPv6 RA ? or should be prevented from sending one ? Should IP proxy reply to ff02::2 (all link-local routers), ... -Vinny

Related discussion:
text: of the destinations included in the scope, then the IP proxy can immediately fail the request. <ins> Note that IP protocol numbers represent both upper layers (as defined in IPv6, examples include TCP and UDP) and IPv6 extension headers (as defined in IPv6, examples include Fragment and Options headers).  IP proxies MAY reject requests to scope to protocol numbers that are used for extension headers.  Upon receiving packets, implementations that support scoping by IP protocol number MUST walk the chain of extensions to find the matching IP protocol number. </ins> 4.7. This document defines multiple new capsule types that allow endpoints