jiebi/CodeConvo huggingface dataset:
Code change:
distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. <del> Since the WebSocket protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception. </del> 3.4. When a client does not receive any response for some time after

Related discussion:
text: That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., ​URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed.
Code change:
distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. <del> Since the WebSocket protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed. The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception. </del> 3.4. When a client does not receive any response for some time after

Related discussion:
text: The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?
Code change:
Do all of: <del> If the bundle's contained URLs (e.g. in the manifest and index) are derived from the request for the bundle, percent-encode [1] (URL) any bytes that are greater than 0x7E or are not URL code points [2] (URL) in these URLs.  It is particularly important to make sure no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) appear. </del> <ins> If the bundle's contained URLs (e.g. in the index) are derived from the request for the bundle, percent-encode [1] (URL) any bytes that are greater than 0x7E or are not URL code points [2] (URL) in these URLs.  It is particularly important to make sure no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) appear. </ins> Similarly, if the request headers for any contained resource are based on the headers sent while requesting the bundle, only

Related discussion:
text: This PR removes the manifest section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading, which does not need a manifest. This and other removed sections can be defined in other documents in the future. Adapted from URL
We might want to make sure the impact of removing manifest section from the bundle format on the chromium. NAME NAME Does Chrome have any usages of manifest section? It seems doesn't use it, however, I am wondering whether there is existing use case for that, I am not aware of.
I never really understood the motivation of this section, since the primary URL response can contain a header pointing to the manifest.
Imagine the situation of application distribution, it is very useful to have a manifest section. For example, we can display the application icon without parsing the HTML of the primary URL. But I agree that the manifest section can be outside the scope of the "core" bundle specification. So removing it from the core spec looks good to me.
LGTM (just for record). Thanks for working on this.
Code change:
RECOMMENDED to not trust a single source of randomness and to not put unaugmented random numbers on the wire. <ins> Implementations might consider deriving secret and non-secret randomness from different PNRG/PRF/KDF instances to limit the damage if the PNRG/PRF/KDF turns out to be fundamentally broken.  NIST generally forbids deriving secret and non-secret randomness from the same KDF instance, but this decision has been criticized by Krawczyk HKDFpaper and doing so is common practice.  In addition to IVs, other examples are the challenge in EAP-TTLS, the RAND in 3GPP AKAs, and the Session-Id in EAP-TLS 1.3.  Note that part of KEYSTREAM_2 is also non-secret randomness as it is known or predictable to an attacker. As explained by Krawczyk, if any attack is mitigated by the NIST requirement it would mean that the KDF is fully broken and would have to be replaced anyway. </ins> If ECDSA is supported, "deterministic ECDSA" as specified in RFC6979 MAY be used.  Pure deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized

Related discussion:
text: I think this can be merged.
Fixed the problem with ':' in refs. Now merging.
Based on Stephens review
Referring to this in :
From the PR : "As explained by Krawczyk, any attack mitigated by the NIST requiment would mean that the KDF is fully broken and would have to be replaced anyway." I didn't understand "any attack mitigated by the NIST requirement", and how mitigation could imply that something is broken. As far as I understand, the statement is something like "if there is a problem deriving secret and non-secret material from the same KDF, then there is a problem with the KDF" Perhaps "an attack based on the violation of the NIST requirement is an attack on the KDF itself"?
Yes, it was likely meants to say "if any attack is mitigate" Let's reformulate according to your suggestion
I made a commit to correct spelling and grammar. I don't think we can give applications more guidance here. How to gererate e.g. private key in certificates are way outside of EDHOC, and it would anyway be hard to say something general as deployments might look very different.I did not want to say anything about randomly generated conenction ID as that is not how connection IDs is meant to be generated. They are intended to be as short as possible. An implentation is allowed to use long random bytestrings but is not recommended in general.
PR merged
Code change:
outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. <ins> A sender SHOULD avoid retransmitting information from packets once they are acknowledged.  This includes packets that are acknowledged after being declared lost, which can happen in the presence of network reordering.  Doing so requires senders to retain information about packets after they are declared lost.  A sender can discard this information after a period of time elapses that adequately allows for reordering, such as a PTO (Section 6.2 of QUIC-RECOVERY), or on other events, such as reaching a memory limit. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: Added changes to recovery as well.
By design, TCP is capable of handling late-arriving acks. If a TCP endpoint receives an ack for a byte range after declaring loss of that byte range, retransmission of that byte range is cancelled. In contrast, QUIC uses monotonically increasing packet numbers. That is definitely an improvement, but does have a downside. If loss detection is too sensitive, and if endpoints drop information regarding what had been sent in a packet at the moment that packet is declared lost, then it would not recognize the late acks. I think that we should suggest (even if not recommend) QUIC endpoints to recognize late-arriving acks, so that our loss detection can be as aggressive and as effective as TCP, if not better. (Please let me know if such text already exists. I am opening the issue because I could not find one)
I have to agree. We had to implement late acknowledgment by marking "lost" packets and retaining them. I believe that this was very helpful in reducing the amount of redundant information we send. Failing to retain packets that were marked as lost was also the cause of a bug. As the lost packet was removed from our outstanding calculation (a different value to the "in-flight" counter we use for congestion control), we believed that there were no packets outstanding and we didn't try to send anything when the next PTO fired. As the loss detection timer is shorter than the PTO timer, we believed that there was nothing to send often (and we don't check all sources of frames, which would have told us otherwise).
Agreed.
Yeah, we should have text on this if we don't already.
The resolution in introduces a new recommendation for senders, so this ought to be considered a design issue if we're happy with that resolution.
URL we have this text:
NAME Thank you for pointing that out. I missed that. I tend to think that we should adopt . As stated in my original comment, handling of late acks is the prerequisite of many of the normative requirements that exist in the recovery draft. Therefore, it is better to have a normative requirement for handling of late acks.
I'm not opposing adding new normative text. If new text is added, I think that the existing text should be aligned to it.
Code change:
outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. <ins> A sender SHOULD avoid retransmitting information from packets once they are acknowledged.  This includes packets that are acknowledged after being declared lost, which can happen in the presence of network reordering.  Doing so requires senders to retain information about packets after they are declared lost.  A sender can discard this information after a period of time elapses that adequately allows for reordering, such as a PTO (Section 6.2 of QUIC-RECOVERY), or on other events, such as reaching a memory limit. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: In the PR, it recommends 3PTO, but the recovery draft A.1 says 1RTT.
FWIW, our implementation, as of a little while ago, tracks for the current PTO. If everything is working nicely, that limits our commitment. As we are sending probes, the time lengthens so that we send a probe before discarding state. If it takes two probes to get an ACK, we won't recognize that, but we will always catch an ACK for the last set of probes. And the state commitment is minimal unless we're forced to probe.
I'll note that the PR is against transport, but this issue is tagged as recovery.
Thanks for pointing out this inconsistency, NAME I would argue that this should be a PTO, since that allows for including the RTT variance in the waiting period. Using a PTO includes the maximum ack delay as well -- which may not be necessary -- but it's convenient to use the PTO period.
I wanted to clarify my comment on the PR about believing that 1 RTT is a preferable recommendation to 3*PTO. We definitely don't want to discard this information BEFORE the packet is lost or acknowledged. But after it's been declared lost, there's no need to wait longer than the reordering window to receive an acknowledgement, because an immediate ACK will be sent when the out of order packet arrives. I tend to think an RTT is a plenty long reordering window in practice. If nothing is inflight before and nothing sent after the packet is lost AND the late immediate ACK for the reordered packet is lost, then it could take longer than the reordering window to receive an ACK, but that seems like an edge case that's not very interesting.
NAME : I've changed it to 1 PTO. We've commonly used PTO as a time period for everything else in the transport, and so it's convenient to use PTO here too. Ultimately, this is the amount of time you're holding on to packets marked as lost, so the extra time waiting for a PTO (over an RTT) really shouldn't make any measurable difference. If you still think we should say RTT, I'm fine with that.
I'm fine with PTO, and I prefer PTO above RTT.
Code change:
outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. <ins> A sender SHOULD avoid retransmitting information from packets once they are acknowledged.  This includes packets that are acknowledged after being declared lost, which can happen in the presence of network reordering.  Doing so requires senders to retain information about packets after they are declared lost.  A sender can discard this information after a period of time elapses that adequately allows for reordering, such as a PTO (Section 6.2 of QUIC-RECOVERY), or on other events, such as reaching a memory limit. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: There could be reasons where there are some packet reordering due to multiple paths being used (e.g., ECMP, clustered endpoint). In such case, the variance of latency becomes more like a constant independent of RTT. I think it is a good idea to recommend a value (i.e. PTO) that can cover such constant even if RTT is very small. PTO has that would cover that constant.
I'm not convinced I understand the rationale completely, but I'm ok with 1 PTO. I believe we should update the recovery draft in the same PR.
So, design?
We have text about this in recovery, but it's there was no normative text and it's in the appendix, so I think this is design.
Let's not thrash too much on this one.
Code change:
extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters <del> with an "x-<vendor>" identifier, e.g. "x-acme-policy", "x-acme- burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del> <ins> with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </ins> 2.2.

Related discussion:
text: See .
iirc there was a discussion on stuff. In general I'm ok with just NAME do you see any issue with that?
No issue, I was aware of the BCP and I think this case fits the first provision for segregating the name spaces in the Appendix B, so any one of the proposed solutions there, including yours, is fine with me.
Code change:
alternatively be absent ("Nothing"). "OptionalNodes" is an abstraction of a "filter-path" (which <del> appears in an existence test or as a function argument). </del> <ins> appears in a test expression or as a function argument). </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.

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:
alternatively be absent ("Nothing"). "OptionalNodes" is an abstraction of a "filter-path" (which <del> appears in an existence test or as a function argument). </del> <ins> appears in a test expression or as a function argument). </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.

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:
Existence tests differ from comparisons in that: they work with arbitrary relative or absolute queries (not just <del> Singular Queries). </del> <ins> singular queries). </ins> they work with queries that select structured values.

Related discussion:
text: 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").
After merging in my changes from main, it appears some Singular Queries still need fixing.
Code change:
When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS <del> alert (QUIC error code 0x178; see tls-errors) if an application </del> <ins> alert (QUIC error code 0x0178; see tls-errors) if an application </ins> protocol is not negotiated.  While ALPN only specifies that servers <del> use this alert, QUIC clients MUST use error 0x178 to terminate a </del> <ins> use this alert, QUIC clients MUST use error 0x0178 to terminate a </ins> connection when ALPN negotiation fails. An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a <del> connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </del> <ins> connection error of type 0x0178 (no_application_protocol). Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x0178. </ins> 8.2.

Related discussion:
text: One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.