jiebi/CodeConvo huggingface dataset:
Code change:
presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks. <del> 5.5. </del> <ins> 5.2.6. </ins> Since DNS-SD is in wide use, and provides for ad-hoc, self- configuring advertising using the mDNS transport, this is a suitable

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value. <del> If the first character of input_string is not lcalpha, fail </del> <ins> If the first character of input_string is not lcalpha or "*", fail </ins> parsing. Let output_string be an empty string.

Related discussion:
text: This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.
Code change:
2.1.4. The "received-status" parameter's value indicates the HTTP status <del> code that the intermediary received from the next hop server. </del> <ins> code that the intermediary received from the next hop server when obtaining this response. </ins> The value MUST be an sf-integer.

Related discussion:
text: I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!
Code change:
not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- <del> provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del> <ins> provided NAT64 will not work.  Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6 PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix. A stub router SHOULD request stub network prefixes with length 64. If the stub router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the stub router obtains a prefix with length greater than 64, the stub router MUST treat the prefix as unusable and allocate a prefix out of its ULA prefix instead. </ins> 5.3.

Related discussion:
text: states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix.
Code change:
not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- <del> provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del> <ins> provided NAT64 will not work.  Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6 PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix. A stub router SHOULD request stub network prefixes with length 64. If the stub router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the stub router obtains a prefix with length greater than 64, the stub router MUST treat the prefix as unusable and allocate a prefix out of its ULA prefix instead. </ins> 5.3.

Related discussion:
text: and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.
Code change:
sequence of procedures. 1) If the client is aware that the server supports resumable upload, <del> it can use the Upload Creation Procedure with the "Upload-Incomplete" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </del> <ins> it can use the Upload Creation Procedure with the "Upload-Complete: ?0" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </ins> 2) After creation, the following parts are sent using the Upload Appending Procedure (upload-appending), and the last part of the <del> upload does not have the "Upload-Incomplete" header. </del> <ins> upload has the "Upload-Complete: ?1" header to indicate the complete transfer. </ins> 4.

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."
Code change:
sequence of procedures. 1) If the client is aware that the server supports resumable upload, <del> it can use the Upload Creation Procedure with the "Upload-Incomplete" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </del> <ins> it can use the Upload Creation Procedure with the "Upload-Complete: ?0" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </ins> 2) After creation, the following parts are sent using the Upload Appending Procedure (upload-appending), and the last part of the <del> upload does not have the "Upload-Incomplete" header. </del> <ins> upload has the "Upload-Complete: ?1" header to indicate the complete transfer. </ins> 4.

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
1.2. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del> <ins> notation of RFC5234, extended with the notation for case-sensitivity in strings defined in RFC7405. It also uses a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </ins> collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation.

Related discussion:
text: Also: change scripts that BAP is invoked with correct options. Note: I did not use "%i" for case-insensitive strings as this is the default anyway. If there is confusion about how a certain protocol element is matched, we should re-state that IMHO in the prose. The collected ABNF uses non-extended ABNF syntax. If this is a problem I'll need to do a bit more work on the tooling.
Should we just adopt wherever we use a string?
Yes, I think that's what the IESG wants us to do. (We were directed to use it in alt-svc)
I've started a branch (mnot-133). Question: do we want to convert things like this: into: ? We do that a fair amount for case-sensitive strings.
Yes. Let me take care of this.
+1
OK. I'll leave my branch there if you want to start with it; otherwise feel free to delete it.
FWIW, I'd prefer to do this only in the places where the string actually is case-sensitive.
I guess I forgot to close the ticket.
Looks good to me. I checked and we also say that they're case-sensitive in the accompanying prose for each instance (although for weak ETags, it's a bit far away).
Code change:
The client MUST NOT start more than one append (upload-appending) based on the resumption offset from a single offset retrieving <del> (offset-retrieving) request. </del> <ins> request. </ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store".

Related discussion:
text: There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!
Code change:
When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can <del> treat it as a signal that the server is interested in receiving </del> <ins> treat it as a signal that the application is interested in receiving </ins> specified request header fields that match the advertised field- <del> values; subsequent requests initiated to the same server and, optionally any subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in, can include the request header fields that match the advertised field-values. </del> <ins> values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field- values. </ins> For example, based on Accept-CH example above, a user agent could <del> append DPR, Width, Viewport-Width, and Downlink header fields to all </del> <ins> append DPR, Width, and Viewport-Width header fields to all </ins> subresource requests initiated by the page constructed from the <del> response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </del> <ins> response. </ins> 2.2.2. <ins> Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin, and on subresource requests initiated as a result of processing a response from the origin. The field-value indicates that the Accept-CH preference should be considered stale after its age is greater than the specified number of seconds. For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day).  Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin. 2.2.3. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
representation. For example, a browser might decode the content coding of a response <del> payload while it is being received, creating a disconnect between the data it has stored and the response payload's original metadata. Updating that stored metadata with a different </del> <ins> while it is being received, creating a disconnect between the data it has stored and the response's original metadata.  Updating that stored metadata with a different </ins> header field would be problematic.  Likewise, a browser might store a <del> post-parse tree representation of HTML, rather than the payload </del> <ins> post-parse tree representation of HTML, rather than the content </ins> received in the response; updating the header field would not be workable in this case, because any

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-03 </del> <ins> draft-ietf-avtcore-rtp-j2k-scl-04 </ins> Abstract

Related discussion:
text: specifies the The low-order bits should be specifies the low-order bits Subbands to Sub-bands signalling to signaling
URL
Code change:
7.2. <del> This memo sets this specification to be the establishing document for the Hash Algorithms for HTTP Digest Fields [2] registry defined in </del> <ins> IANA is requested to create the new "Hash Algorithms for HTTP Digest Fields" registry at https://www.iana.org/assignments/http-digest- hash-alg/ [1] and populate it with the entries in iana-hash- algorithm-table.  The procedure for new registrations is provided in </ins> algorithms. <del> IANA is asked to initialize the registry with the entries in iana- hash-algorithm-table. </del> 8.  References 8.1.  URIs <del> [1] https://www.iana.org/assignments/http-dig-alg/ [2] https://www.iana.org/assignments/http-structured-dig-alg/ </del> <ins> [1] https://www.iana.org/assignments/http-digest-hash-alg/ </ins>

Related discussion:
text: Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)
Code change:
to the resource server.  If these values are not identical, the data contained in the response MUST NOT be used. <ins> These validation actions can thwart impersonation attacks, as described in Impersonation. </ins> 4. To support use cases in which the set of legitimate protected

Related discussion:
text: Cc NAME
Section 3.3 should reference the attack described in section 7.3 URL And evaluate whether it makes sense to add a back reference from 7.3 to 3.3.
Looks good to me.
Code change:
Other fields: As described in canonical-object-fields. An "OBJECT_DATAGRAM" message carries a single object in a datagram. <del> There is no explicit length of the payload; it is determined by the length of the datagram. </del> An Object received in an "OBJECT_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram".  To send an Object with "Object

Related discussion:
text: This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM
Code change:
current_age is defined in age.calculations. Clients can send the max-age or min-fresh request directives (cache- <del> request-directive) to constrain or relax freshness calculations for the corresponding response.  However, caches are not required to </del> <ins> request-directive) to suggest limits on the freshness calculations for the corresponding response.  However, caches are not required to </ins> honor them. When calculating freshness, to avoid common problems in date parsing:

Related discussion:
text: replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...
Code change:
compromised due to an insider risk - be it malicious or otherwise to confirm that the publishers know if their deliverable has been <del> compromised.  Can they trust their key protection or audit logging? </del> <ins> compromised.  (For example, can they trust their key protection or audit logging?) </ins> to know how the update client on an instance of a health monitoring system discerns a general update from one specially

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.