jiebi/CodeConvo huggingface dataset:
Change:
connection error of type H3_FRAME_UNEXPECTED (errors).  In particular, a DATA frame before any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame is considered invalid. <ins> Other frame types, especially unknown frame types, might be permitted subject to their own rules; see extensions. </ins> A server MAY send one or more PUSH_PROMISE frames (frame-push- promise) before, after, or interleaved with the frames of a response

Discussion:
NAME does this address your concerns?
Section 7.2.8: URL These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. So I am uncertain if it is acceptable to shoehorn in a reserved frame after a frame that is supposed to be the last and then result in a close of the frame? Based on what is written I would lean to the interpretation that it is allowed, as the frame sender has decided to not close the stream yet, and thus it is open. If this is correct interpretation than it is up to the editor if they like to clarify more. Else something needs to be done.
The best example here is sending a reserved frame after a Request stream is opened by the client. Perhaps it is useful to call that out in section 4.1. is a bit loose. You can't send frames on qpack streams for instance, or as the first bytes on a push stream. Maybe we can rephrase it as, "Can be sent on any stream where frames are permitted to be sent"
There are no frames that close the stream, because stream closure is handled by the transport. SETTINGS is special in that it is required to be first, and is covered by : It would hypothetically apply to a future frame type which is required to come at the end of the stream as well, but we have no such frames at this time. ( does impose specific ordering on DATA and HEADERS frames relative to each other, but says nothing about other frame types.) NAME point is well-taken, and I'll take that text.
NAME does the PR address your issue?
Yes, I think this PR clarifies things a bit and are sufficient to resolve my issue.
Labeling this as "editorial" based on
Change:
portal systems might not count traffic to whitelisted servers, such as the API server, but clients cannot rely on such behavior. <ins> The valid JSON keys can be extended by adding entries to the Captive Portal API Keys Registry iana-section.  If a client receives a key that it does not recognize, it MUST ignore the key and any associated values.  All keys other than the ones defined in this document as "required" will be considered optional. </ins> 4.3. A client connected to a captive network upon discovering the URI of

Discussion:
As discussed in , define an IANA registry for extending JSON keys use for Captive Portal API.
NAME NAME thanks for the comments. Please take another pass!
Should we define an IANA registry for adding new keys?
Yes, yes we should.
and i already commented in the PR, but if possible it would be beneficial to have some distinction between IETF or a relevant organization (like WFA, WBA) requested keys vs from some individual organization
Would we want to suggest having a nested dictionary format for organization-specific extensions? Like "wba" as a key to a dictionary; or a sub-dictionary indicating that there are WISPr-related settings to be aware of?
i think it would be a good idea. We have seen WBA start to take active interest in the documents. Also there's work happening in WFA that could benefit from having an extension point
RFC 6648 might suggest otherwise. If there are things that a group wants to add that are truly unique to that group, this is probably fine.
Yes, I think that more than having per-group keys (with almost certain overlap), I'd imagine that compatibility with certain technologies would be handled via these sub-dictionaries, such as what I mentioned for WISPr. Not sure how critical mentioning this is in the document though.
Can we call this one done?
I'm assuming we will go down the path of defining an IANA registry with access technology specific extension ?
The description in "Captive Portal API Keys Registry" gives some guidance for prefixes, etc. I assume the experts once designated can work with WFA/WBA to define proper entries.
Change:
QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every <del> other packet, and for every packet (for a short while) when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </del> <ins> other packet, and for every packet when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </ins> 3.

Discussion:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24
Change:
construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21. <ins> Metadata may also be arbitrarily long or bounded in length.  The amount of permitted metadata may be determined by application or by the underlying cryptographic protocol. </ins> 6.1. Note that any metadata bits of information can be used to further

Discussion:
Replace suggested registry with list of other options. The rationale is that a registry may be sufficient but not necessary. There are other options that might work. I suggest we work with NAME on a draft describing these techniques in more detail. cc NAME
There's currently no text around token expiration. Minimally, we could say that tokens expire when issuer (and verifier) keys rotate. Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens? For example, one might imagine using PMB-like constructions to encode an expiration "epoch" into the metadata bits. The single metadata bit variant would allow two epochs that way. NAME NAME what do you think?
I'm not sure what baking the expiry into the tokens gives that can't be managed by rotating the issuer/verifier keys (or using public metadata (which is effectively the key used to sign))? That way issuers that care about more fine grained token expiration use the key rotation for that and issuers that only care about coarse token expiration use it for other metadata, allowing the protocol to treat both in the same way?
Yeah, I think the only two options are (a) rotate keys or (b) include the expiry information as public metadata (and need not be tied to the key used to sign). I'm not advocating for one or the other. Sure, that's reasonable. We should probably have text on this point. (That's partly why I filed this issue.)
We should also make sure to note that the validity window does narrow the anonymity set.
This LGTM. Agreed that working on a document that tackles these questions specifically would be worthwhile.
Change:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <ins> "good" or "deactivated" </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation.

Discussion:
This simplifies both the spec and the implementation, and does not attempt to impose specific data retention policy on the CA.
I don't really agree about that one. Why not delete completely the data instead of deactivating? Why shouldn't a user be able to request full deletion and no retention of any of their account data?
Nothing in this change prevents CAs from choosing to delete account data immediately upon deactivation, but the spec should not try to dictate policy.
I think this PR is fine in principal, but I have some minor concerns: If we're going to use the field, we should prefer to use the values that are already there, namely and . Do you think there's a semantic difference between that and what you're proposing? Your edits remove the guidance on what the server should return from these requests. Please add that back in. It occurs to me looking at this that the first version of authz deletion should have specified that the server MUST verify that the account is the owner of the authz before allowing it to deactivate the authz. Could you please add that while you're editing here?
Done.
Change:
Both "End-to-End" and "Hop-by-Hop" media encryption have implications for streaming operators. <del> 5.1. </del> <ins> 4.1. </ins> The use of strong encryption does provide confidentiality for encrypted streaming media, from the sender to either an intermediary

Discussion:
Reverts ietf-wg-mops/draft-ietf-mops-streaming-opcons (still learning github)
Change:
the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. <del> Key or Key Length: 3 bits This field containts the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </del> <ins> Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </ins> If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes:

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets. <del> 4.11.2. </del> <ins> 4.9.2. </ins> An endpoint MUST discard its handshake keys when the TLS handshake is confirmed (handshake-confirmed).  The server MUST send a HANDSHAKE_DONE frame as soon as it completes the handshake. <del> 4.11.3. </del> <ins> 4.9.3. </ins> 0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
7.5. <ins> During the handshake, some packet protection keys might not be available when a packet arrives.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive, and 1-RTT packets cannot be processed until the handshake completes. Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the peer has packet protection keys to process those packets. 7.6. </ins> Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in flight, since these packets adds network load without establishing

Discussion:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.
Change:
attest to the health of the client providing the Appraisal Policy needs to be considered. <del> 13. </del> <ins> 12. </ins> This document does not require any actions by IANA. <del> 14. </del> <ins> 13. </ins> Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for <del> user indefinitely, in order to be able to include them in the </del> <ins> users indefinitely, in order to be able to include them in the </ins> responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo.

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> A token SHOULD be constructed in a way that allows the server to distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </del> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time,

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of <del> comparison.  Used By: Verifier; Produced By: Reference Value Provider. </del> <ins> comparison. Consumed By: Verifier Produced By: Reference Value Provider </ins> 5.

Discussion:
harmonized phrasing in the terminology section -> roles are finally roles and changed Terminology item format
This sentence: creates a bit of cognitive dissonance. In the Terminology section, the Endorser, Ref-val Provider, RP Owner and Verifier Owner are defined as "entities", however, they don't include any of the roles (Verifier, RP, Attester).
That is a weirdly persistent bug that we have to squash once and for all. Attester, Verifier, Endorser, RVP, RP, RP Owner, and Verifier Owner are all roles. Roles are instantiated by entities, which is the term we now use under the premisethat the well-established and understood term principal is to hard to understand for a reader (sry, got a bit rant'y here). I think I added all the changes that fixes this issue to a PR that was abandoned at the end. It seems we missed to rescue my corresponding changes from that PR, though. Can anybody provide a pointer to these changes? Otherwise we have to dig that up in the next meeting.
Change:
masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits <del> (config-rotation).  Note that either of these techniques exposes information to outside observers, as traffic destined for each server set can be easily distinguished. </del> <ins> (config-rotation).  Note that either solution has a privay impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. <del> 10.4. </del> <ins> 10.5. </ins> Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del> <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.

Discussion:
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
Change:
7.2. <ins> In order to reduce the overhead of sending multiple small Messages on a Connection, the application may want to batch several Send actions together.  This provides a hint to the system that the sending of these Messages should be coalesced when possible, and that sending any of the batched Messages may be delayed until the last Message in the batch is enqueued. 7.3. </ins> Sender-side framing allows a caller to provide the interface with a function that takes a Message of an appropriate application-layer type and returns an array of octets, the on-the-wire representation

Discussion:
See issue The one question I have here is the semantics around batching. In our implementation, we use block semantics (from clang), to batch looks like: connectionbatch(^{ connectionsend(...); connection_send(...); }); where the block is called inline, and the batch is over when the block returns. I'm not sure what the right style for the pseudo-code is for the draft.
In aligning the implementation with the API for the initial draft, we removed this text since we still need text in the API: Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately. To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete. This can also help context switches when enqueuing data in the interface driver if the operation can be batched.
This seems equivalent to the idea of PUSH in existing systems and would make sense for lots of short write calls.
+1. The higher-level question here is how to support high-performance applications. Send batching is one thing you can do here. Receive batching would be another obvious one. Zero-copy is another, though that's probably so tied to implementation and platform that it's not useful to standardize. But there should be some way for this interface to coexist with it...
+1 from me too
+1 In my opinion, support for high-performance applications is nothing we can add to the API, but rather something we must sure to not prevent or make hard to implement. So we should ask ourselves for every point in the API "can this be implemented zero-copy" or "can an implementation batch this" – if the answer is no, we have to fix that.
this one seems to have consensus and does not seem to be too much work. NAME if you can get a PR in in the next week or so let's ship it with ietf-00...
I'll try to get this in soon!
fixed with merge of
LGTM, we can worry about the right way to pseudocode this later.
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 which is an array and selects all the elements of the input node.  The result is a list of three </del> <ins> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three </ins> nodes: "{"b":0}", "{"b":1}", and "{"c":2}". Finally, ".b" selects from any input node of type object with a

Discussion:
... and some minor edits ...
Indeed. I'll do a small PR with my points.
a little late to the party ... thanks
[ ] 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?
This PR could be merged to make progress. Further changes as indicated by NAME are probably needed, either now or in a subsequent PR.