jiebi/CodeConvo huggingface dataset:
Change:
The current item is selected if and only if the result is "true". <del> Notes: </del> <ins> Paths in filter expressions are Singular Paths, each of which selects at most one node. </ins> <del> Parentheses can be used with "boolean-expr" for grouping.  So filter selection syntax in the original proposal "[?(<expr>)]" is naturally contained in the current lean syntax "[?<expr>]" as a special case. </del> <ins> Parentheses can be used with "boolean-expr" for grouping.  So filter selection syntax in the original proposal "[?(<expr>)]" is naturally contained in the current lean syntax "[?<expr>]" as a special case. </ins> <del> Comparisons are restricted to primitive values (such as number, string, "true", "false", "null").  Comparisons with complex values will fail, i.e. no selection occurs. </del> <ins> Comparisons are restricted to Singular Path values and primitive values (such as number, string, "true", "false", "null"). </ins> <del> Data types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. </del> <ins> Comparisons with complex values will fail, i.e. no selection occurs. </ins> <del> A member or element value by itself in a Boolean context is interpreted as "false" only if it does not exist.  Otherwise it is interpreted as "true".  To be more specific about the actual value, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with structured values. </del> <ins> Data types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. </ins> <del> Paths in filter expressions are Singular Paths, each of which selects at most one node. </del> <ins> A member or element value by itself in a Boolean context is interpreted as "false" only if it does not exist.  Otherwise it is interpreted as "true".  To be more specific about the actual value, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with structured values. </ins> <del> The regular expressions in the string-literals on the right-hand side of "=~" are as defined in I-D.draft-bormann-jsonpath-iregexp. Regular expression tests can be applied to JSON string values (RFC8259) only (on the left-hand side of "=~"); they yield false otherwise. </del> <ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". </ins> <del> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". </del> <ins> "true", "false", and "null" are lower-case only (case-sensitive). </ins> <del> false, null, true are lower-case only (case-sensitive). </del> <ins> Regular expression tests can be applied to JSON string values (RFC8259) only (on the left-hand side of "=~"); they yield false otherwise. The syntax of regular expressions in the string-literals on the right-hand side of "=~" is as defined in I-D.draft-bormann-jsonpath- iregexp. </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least

Discussion:
Fixes URL
The notes need separating out into paragraphs. The semantics section needs to be expanded.
Change:
authenticate itself to the Issuer.  In settings where the Attester is a Client-trusted service, one way Attesters can authenticate to Issuers is via mutually-authenticated TLS.  However, alernative <del> authentication mechanisms are possible.  This arrangement is shown below. </del> <ins> authentication mechanisms are possible.  This arrangement is shown in fig-deploy-joint-origin. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account

Discussion:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.
Change:
requests with a Stream ID greater than or equal to the identifier received in a GOAWAY frame, those requests will not be processed. Clients can safely retry unprocessed requests on a different <del> connection. </del> <ins> connection.  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. </ins> Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the server might have been processed; their status cannot be

Discussion:
Move "A client that is unable to retry requests [...]" sentence from the beginning of an entirely unrelated paragraph to somewhere more appropriate. Change Push ID requirement on subsequent GOAWAY frames. This was presumably an oversight, because "An endpoint MAY send multiple GOAWAY frames indicating different identifiers [...]" paragraph above is pretty clear and covers both directions already.
Change:
Trade-offs: RST Packet Injection has a few advantages that make it extremely popular as a censorship technique.  RST Packet Injection is <del> an out-of-band prevention mechanism, allowing the avoidance of the </del> <ins> an out-of-band interference mechanism, allowing the avoidance of the </ins> the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to inspect a copy of the information, usually mirrored by an optical

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.
Change:
access of the RS and no longer needs the token. The following sections and examples contain specific guidance on how <del> to use the GNAP protocol in different situations and deployments. </del> <ins> to use GNAP in different situations and deployments. </ins> 1.4.1.

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
a host which only functions as an ACME server could place the directory under path "/". <del> The dictionary MAY additionally contain a key "meta".  If present, it MUST be a JSON dictionary; each item in the dictionary is an item of </del> <ins> The object MAY additionally contain a key "meta".  If present, it MUST be a JSON object; each field in the object is an item of </ins> metadata relating to the service provided by the ACME server. The following metadata items are defined, all of which are OPTIONAL:

Discussion:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.
Change:
client identifier and the context identifier (if it was set and included in the initial access token response by the AS) in the 'kid' field in the 'cnf' parameter of the token, with the same structure <del> defined in kid.  These identifiers need to be included in the response, in order for the RS to identify the previously generated Security Context. </del> <ins> defined in kid.  These identifiers need to be included in the token in order for the RS to identify the previously generated Security Context. </ins> ex5 shows an example of such an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations.  The

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del> <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. Once all the session-level lines have been parsed, processing

Discussion:
Not sure I love what I have done here.
Section 5.7.2 should include a statement (probably at the end) that implementations may know and process attributes other than those described in this section.
Section Media Section Parsing Text As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. proposal update that text to say something about OK to process things are known but not specified in JSEP.
Change:
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence. </del> <ins> input to the hash function is a CBOR Sequence.  Note that TH_4 can be computed and cached already in the processing of message_3. </ins> Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface,

Discussion:
This note needs to be updated. The sentence is a remnant since TH3 was defined as H(TH2, PLAINTEXT_2)
Change:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". <del> This section defines the extension point as well as four function </del> <ins> This section defines the extension point as well as some function </ins> extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are expected to be implemented like any

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
1. <del> As per RFC5077, and as described in RFC8446, TLS servers send clients </del> <ins> As per RFC5077, and as described in RFC8446, TLS servers vend clients </ins> an arbitrary number of session tickets at their own discretion in NewSessionTicket messages.  There are two limitations with this design.  First, servers choose some (often hard-coded) number of tickets vended per connection.  Second, clients do not have a way of <del> expressing their desired number of tickets, which may impact future connection establishment.  For example, clients may open multiple TLS connections to the same server for HTTP, or may race TLS connections </del> <ins> expressing their desired number of tickets, which can impact future connection establishment.  For example, clients can open multiple TLS connections to the same server for HTTP, or race TLS connections </ins> across different network interfaces.  The latter is especially useful in transport systems that implement Happy Eyeballs RFC8305.  Since clients control connection concurrency and resumption, a standard mechanism for requesting more than one ticket is desirable. This document specifies a new TLS extension - "ticket_request" - that <del> may be used by clients to express their desired number of session tickets.  Servers may use this extension as a hint of the number of </del> <ins> can be used by clients to express their desired number of session tickets.  Servers can use this extension as a hint of the number of </ins> NewSessionTicket messages to vend.  This extension is only applicable to TLS 1.3 RFC8446, DTLS 1.3 I-D.ietf-tls-dtls13, and future versions thereof.

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
3. <ins> The issuance protocols defined in this document embody the core of Privacy Pass.  Clients receive TokenChallenge inputs from the redemption protocol (AUTHSCHEME, Section 2.1) and use the issuance protocols to produce corresponding Token values (AUTHSCHEME, Section 2.2).  The issuance protocol describes how Clients and Issuers interact to compute a token using a one-round protocol consisting of a TokenRequest from the Client and TokenResponse from the Issuer.  This interaction is shown below. The TokenChallenge inputs to the issuance protocols described in this document can be interactive or non-interactive, and per-origin or cross-origin. The issuance protocols defined in this document are compatible with any deployment model defined in Section 4 of ARCHITECTURE.  The details of attestation are outside the scope of the issuance protocol; see Section 4 of ARCHITECTURE for information about how attestation can be implemented in each of the relevant deployment models. This document describes two variants of the issuance protocol: one that is privately verifiable (private-flow) using the issuance private key based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable (public-flow) using the issuance public key based on the blind RSA signature scheme BLINDRSA. 4. </ins> Issuers MUST provide two parameters for configuration: Issuer Request URI: A token request URL for generating access

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in fig_detnet_cw MUST be present in all DetNet packets containing app- <del> flow data. </del> <ins> flow data.  This format of the d-CW was created in order (1) to allow larger S/N space to avoid S/N rollover frequency in some applications and (2) to allow non-skip zero S/N what simplifies implementation. </ins>

Discussion:
Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done
Change:
2.2.2.1. <del> When the decoder finishes decoding a header block containing dynamic </del> <ins> After the decoder finishes decoding a header block containing dynamic </ins> table references, it MUST emit a Header Acknowledgement instruction (header-acknowledgement).  A stream may carry multiple header blocks in the case of intermediate responses, trailers, and pushed requests.

Discussion:
Add MUST to sentence about requirement on decoder to emit a Header Acknowledgement instruction every time it decodes a header block with non-zero Required Insert Count.
That's a good point, I haven't thought about it. Would changing "When the decoder finishes decoding..." to "After the decoder finishes decoding..." be sufficient to allow for delayed ACKs?
Works for me.
Done. Thanks for raising this issue.
You can't coalesce Header Acks like you can Insert Count Increment or transport Acks. The only overhead savings comes from when these are sent to the peer - eg: transport overhead. The text only says the Ack, and doesn't really describe how quickly it has to be conveyed. But I don't really have a problem with when vs. after either.
This doesn't allow for a delay in sending an ack. That delay might be useful in reducing overheads. That might be a new issue though.
Change:
If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this when fixing profiles], as specified in I-D.ietf-mmusic-sctp- sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del> <ins> "application" and the <proto> field MUST be set to exactly match the field in the offer; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
MUST occur in a specific order, and with a specific syntax, as defined in RFC4566, Section 5.  Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the <del> same type (typically "a=") can occur in any order, and their ordering is not meaningful. </del> <ins> same type (typically "a=") can occur in any order. </ins> The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked.

Discussion:
BLOCKER: Section 5.7.1, first paragraph: this claims that a= lines are order insensitive. Nothing in SDP's base definition makes this true, and nothing precludes specific attributes from assigning meaning to the order in which they appear. See draft-ietf-slim-negotiating-human-language-08 for an example of an SDP extension that does apply meaning to the order in which attributes appear (for better or worse).
Section Session-Level Parsing Text is First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order, and their ordering is not meaningful. Remove the text "and their ordering is not meaningful." from above para
FWIW ... some of SDP implementations I work with save a lines in non ordered sets and I never knew this was a bug. Bummer
Agree with proposal.
LGTM