jiebi/CodeConvo huggingface dataset:
Code change:
the result is "LogicalTrue"; if the function's declared result type is "NodesType", it tests whether the result is non-empty.  If the function's declared result type is "ValueType", its use in a test <del> expression is not well-typed. </del> <ins> expression is not well typed. </ins> Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and

Related discussion:
text: 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.
Code change:
the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how much redundancy a system adds to cope from link impairments, without <del> reducing the good-put when the channel quality is high.  There is </del> <ins> reducing the good-put when the channel quality is good.  There is </ins> usually enough redundancy to guarantee a Quasi-Error Free <del> transmission.  However, physical layer reliability mechanisms may not recover transmission losses (e.g. with a mobile user) and layer 2 (or above) re-transmissions induce 500 ms one-way delay with a geostationary satellite.  Further exploiting coding schemes at higher OSI-layers is an opportunity for releasing constraints on the physical layer in such cases and improving the performance of SATCOM systems. </del> <ins> transmission.  The recovery time depends on the encoding block size. Considering for instance geostationary satellite system (GEO), physical or link layers erasure coding mechanisms recover transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to an non- negligible additional delay in particular over GEO link.  Further exploiting coding schemes at application or transport layers is an opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. </ins> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to

Related discussion:
text: with a mobile user) and layer 2 (or above) re-transmissions induce 500 ms one-way delay with a geostationary satellite" Look, forward error coding (FEC) and link ACKs are complementary on a sliding scale depending on delay/channel quality, and this is talking solely about retransmissions. In fact, link or channel FEC do recover a large number of transmission bit/symbol losses without adding extra delay.
We have clarified this point in PR
Code change:
different online protocol. Intra-data-center communication.  Machine-to-machine communication <del> within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </del> <ins> within a single data center or point-of-presence (PoP) may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

Related discussion:
text: Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.
Code change:
topic is used to correlate push messages sent to the same subscription and does not convey any other semantics. <del> The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. </del> <ins> The grammar for the Topic header field uses the "token" rule defined in RFC7230. </ins> For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64

Related discussion:
text: NAME suggested this. It's a simplification that should reduce errors. It prevents topics like "Hello world!", but that's probably a good thing on balance.
Code change:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records, at its discretion.  The HTTP server may be made available over either HTTPS or unencrypted HTTP; the client tells the server in its response which to check. </del> <ins> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "simpleHttp"

Related discussion:
text: On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants.
Code change:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records, at its discretion.  The HTTP server may be made available over either HTTPS or unencrypted HTTP; the client tells the server in its response which to check. </del> <ins> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "simpleHttp"

Related discussion:
text: The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Code change:
9. <del> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </del> <ins> 9.1. The application can set per-connection Properties.  Certain Connection Properties may be read-only, on a protocol- and property- specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </ins> At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~

Related discussion:
text: This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.
Code change:
This parameter holds a part of the IV value.  When using the COSE_Encrypted structure, frequently a portion of the IV is part of the context associated with the key value.  This field is used <del> to carry the portion of the IV that changes for each message.  As the IV is authenticated by the encryption process, this value can be placed in the unprotected header bucket.  The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT be present in the same security layer. The final IV is generated by concatenating the fixed portion of the IV, a zero string and the changing portion of the IV.  The length of the zero string is computed by taking the required IV length and subtracting the lengths of the fixed and changing IV portions. </del> <ins> to carry a value that causes the IV to be changed for each message.  As the IV is authenticated by the encryption process, this value can be placed in the unprotected header bucket.  The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT be present in the same security layer. The message IV is generated by the following steps: Left pad the partial IV with zeros to the length of IV. XOR the padded partial IV with the context IV. </ins> This parameter holds a counter signature value.  Counter signatures provide a method of having a second party sign some

Related discussion:
text: This was inspired by the IV computation for TLS. It may or may not make things more secure. The old behavior is easy to get by making the context IV have trailing zeros.
Code change:
This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and <del> one client, have been used for authentication in TLS. </del> <ins> one client, have been used for authentication in TLS.  There was no attempt to prioritize the examples in any particular order. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

Related discussion:
text: Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.
Code change:
transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be <del> collected from or about each layer.  The corresponding claims can be </del> <ins> collected from or about each layer.  The corresponding Claims can be </ins> structured in a nested fashion that reflects the nesting of the <del> Attester's layers. </del> <ins> Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by Endorsers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system

Related discussion:
text: Added clarifying text -
" including roots of trust" from .
We should add the sentence "Normally, claims are not self-asserted by a layer or root of trust." in the section describing layered attester / layering. around line 1120?
I'd not object that. I'd be okay with "Normally, claims are not self-asserted by a root of trust."
Code change:
fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Sections 6.3 and 6.5 of SEMANTICS. </del> <ins> Sections 6.3 and 6.5 of RFC9110. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together

Related discussion:
text: These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.
Code change:
Relying Party or for a Verifier, then integrity of the process is compromised. <del> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </del> <ins> The security protecting conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </ins> context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not

Related discussion:
text: rebased.
` The first sentence seems to say ‘you can do whatever you want’, but the second seems to say “you should sign the messages” This doesn’t seem to be about integrity; it says Evidence must be confidential. Is that actually a requirement?
I don't see where it says RATS messages have to be confidential. 'end-to-end' means between RATS roles. Which can be achieved at different nesting levels; where nesting is interpreted to mean nesting in the message (data) layers. Summary - I don't see a problem with the proposed text.
I am inclined to agree with Ned here, but we could change the first line, while we're at it. The reuse of the word "protected" used in the 1st sentence in the 2nd sentence now might make it more clear that this message protection can happen on many layers.
Ok but this PR merges into the branch instead of master. Recommend rebasing on master so that order of merge doesn't matter.
Code change:
""index"" (index-section) <del> ""manifest"" (manifest-section) </del> ""critical"" (critical-section) ""responses"" (responses-section)

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:
If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are <del> permissible based on the Path Selection Properties passed by the </del> <ins> permissible based on the Selection Properties passed by the </ins> application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport

Related discussion:
text: Several small updates, mostly to clean things up a bit, and align property names and such.
NAME - I think you're wrong: my understanding (and also the way the text is written - otherwise we'd have to change it in the API draft) was that Connection Properties can (and should) also be set on Preconnections, to give as much input as possible for Connection establishment. In the API draft, the Selection Properties in Section 5.2 can only be used on Preconnections: you can't ask for congestion control after establishment. You can't say that you'd rather have multistreaming support after establishment. But that doesn't exclude Connection properties from being usable earlier. Required minimum checksum coverage could influence choosing UDP-Lite vs. UDP. Bounds on Send or Receive Rate could influence the interface choice. The capacity profile could influence various things (and no, there isn't a matching Selection Property now - there is a per-Message override). So... I think that either you're wrong, or I'm missing something and the API draft heavily lags behind a decision that was made. I hope not!
NAME The API drafts says: I interpret this as only the Selection Properties influence selection and the Connection properties are used to further configure the connections according to user preferences. Otherwise what is the difference between them?
If you interpret it as you do, I think the text isn't clear enough (indeed it isn't super clear - in particular, "eventually established" is misleading IMO). Though, note that it says that Connection properties can also be used later. Regarding the difference between them: Selection Properties only make sense for Preconnections.
NAME - sorry lost this thread. But I saw that you have started cleaning up some Connection properties that had mixed Connection and Selection properties up in the API draft. Does it mean that we are now in synch and agree that only Selection properties are used in the selection and Connection properties are used for configuration (both during establisment and also after the connection setup).
NAME the other PR means nothing about what I said here: it only tried to address issue which is about a wording inconsistency in a specific property. You say that Connection properties can also be used during establishment - if you agree with allowing this, then why not allow to configure them as early as possible and allow them to influence selection?
Code change:
If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are <del> permissible based on the Path Selection Properties passed by the </del> <ins> permissible based on the Selection Properties passed by the </ins> application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport

Related discussion:
text: What's bad about having more information available that can guide the selection process?
NAME the problem is that the Connection properties are not expressed in a way suitable for selection. If they should also be used for Selection they would have to be reworked to be of type Preference. Otherwise I do not know what they mean for selection. What does it mean if I pick say a particular connection group transmission scheduler? Is it required or preferred? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don't seem useful, but some do... generally we may not have good guidance on how they should be used by an implementation, but giving the system freedom to use as many inputs as possible is probably a good thing. Regarding the type, require/prefer//ignore/avoid/prohibit obviously works fine for a "wishlist" of boolean character: having something, or not having it. The selection properties are generally like that - except "Interface Instance or Type" and "Provisioning Domain Instance or Type" which are, well... wishlist-collections. Consider the capacity profile. Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive, you may even want to put this traffic on a specific network interface! But if you'd want to make a copy of the capacity profile as a "proper" selection property, how would you do it? Apply require/prefer/ignore/avoid/prohibit for each of its values? Then I could say "prefer" low latency/non-interactive but "avoid" low latency/non-interactive, which would surely be odd. Apply the qualifier to the whole thing? Then it's about, e.g. "avoiding" to use a capacity profile at all. That's odd as well. I think it's in the nature of the current selection properties that they merely say "I want to be able to do this, and this is how important it is to me", which is different from configuring something. That's also why, as written, they simply wouldn't work for later connection configuration.