jiebi/CodeConvo huggingface dataset:
Code change:
1. <del> This specification updates the HTTP SEARCH method originally defined in RFC5323. </del> <ins> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. </ins> <del> Many existing HTTP-based applications use the HTTP GET and POST methods in various ways to implement the functionality provided by SEARCH. </del> <ins> Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.  For example, while this is an common and interoperable query: </ins> <del> Using a GET request with some combination of query parameters included within the request URI (as illustrated in the example below) is arguably the most common mechanism for implementing search in web applications.  With this approach, implementations are required to parse the request URI into distinct path (everything before the '?') and query elements (everything after the '?').  The path identifies the resource processing the query (in this case 'http://example.org/ feed') while the query identifies the specific parameters of the search operation. </del> <ins> if the query parameters extend to several kilobytes or more of data it may not be, because many implementations place limits on their size.  Often these limits are not known or discoverable ahead of time, because a request can pass through many uncoordinated systems. Additionally, expressing some data in the target URI is inefficient, because it needs to be encoded to be a valid URI. </ins> <del> A typical use of HTTP GET for requesting a search While there are definite advantages to using GET requests in this manner, the disadvantages should not be overlooked.  Specifically: </del> <ins> Encoding query parameters directly into the request URI also effectively casts every possible combination of query inputs as distinct resources.  Depending on the application, that may not be desirable. </ins> As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example

Related discussion:
text: For this use case, we just need a way for the server to also point to a GETtable resource (maybe with a lifetime). If we solved that problem, would we still need full cacheability?
Needs to sync with .
Code change:
1. <del> This specification updates the HTTP SEARCH method originally defined in RFC5323. </del> <ins> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. </ins> <del> Many existing HTTP-based applications use the HTTP GET and POST methods in various ways to implement the functionality provided by SEARCH. </del> <ins> Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.  For example, while this is an common and interoperable query: </ins> <del> Using a GET request with some combination of query parameters included within the request URI (as illustrated in the example below) is arguably the most common mechanism for implementing search in web applications.  With this approach, implementations are required to parse the request URI into distinct path (everything before the '?') and query elements (everything after the '?').  The path identifies the resource processing the query (in this case 'http://example.org/ feed') while the query identifies the specific parameters of the search operation. </del> <ins> if the query parameters extend to several kilobytes or more of data it may not be, because many implementations place limits on their size.  Often these limits are not known or discoverable ahead of time, because a request can pass through many uncoordinated systems. Additionally, expressing some data in the target URI is inefficient, because it needs to be encoded to be a valid URI. </ins> <del> A typical use of HTTP GET for requesting a search While there are definite advantages to using GET requests in this manner, the disadvantages should not be overlooked.  Specifically: </del> <ins> Encoding query parameters directly into the request URI also effectively casts every possible combination of query inputs as distinct resources.  Depending on the application, that may not be desirable. </ins> As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example

Related discussion:
text: If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.
Code change:
fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against <del> malicious tampering with HTTP messages.  This can be achieved by combining it with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </del> <ins> malicious tampering with HTTP messages.  In the absence of additional security mechanisms, an on-path, malicious actor can remove or recalculate and substitute a digest value.  This attack can be mitigated by combining mechanisms described in this document with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </ins> 6.2.

Related discussion:
text: ballot position feedback
[x] §6.1 Recommend adding cautionary language about the capabilities of an adversary like those stated in Peter’s SECDIR review [x] Appendix A, typo[x] Section 6.5, e.g.
Code change:
that can differ for different types of services and for different providers/solutions. <del> The top layer represents the application/flow view of </del> <ins> The top layer represents the application/flow view of service </ins> connectivity. <del> Basis for the Operator Network and Services Models that provides topological information of the network.  It provides the core multi-layer topology model/data and how to connect them to the other models/data. </del> <ins> The document defines the following terms: Digital Map is a data model that provides a view of the operator's networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate amongs layers and correlate between them.  This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). </ins> The set of principles, guidelines, and conventions to model the Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other <del> entities o. </del> <ins> entities. </ins> Defines the core topological entities, their role in the network, <del> core properties and relationships both inside each layer and between the layers. </del> <ins> core topological properties and relationships both inside each layer and between the layers. </ins> It is the basic topological model with the links to other models and connects them all: configuration, maintenance, assurance

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps: <del> Issuer Key Discovery The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup. This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. Signature verification The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. Signed Statement validation The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. </del> <ins> The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup.  This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. </ins> <del> Apply Registration Policy For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. </del> <ins> The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. </ins> <del> Register the Signed Statement to the append-only log. Return the Transparent Statement, which includes the Receipt. </del> <ins> The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. Register the Signed Statement to the append-only log Return the Transparent Statement, which includes the Receipt </ins> Details about generating Receipts are described in Receipt. The last two steps may be shared between a batch of Signed Statements

Related discussion:
text: A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)
Code change:
4. <ins> 4.1. </ins> There are two ways a client can receive updates for a resource: At a high level, an ALTO client opens a persistent HTTP connection

Related discussion:
text: NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.
Code change:
for example, it may be the home router providing connectivity to an ISP. <del> 5.4. </del> <ins> 5.2.5. </ins> The stub router MAY advertise itself as a default router on the stub network, if it itself has a default route on the AIL.  In some cases

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:
acknowledgement (see HTTP2). Multiple updates to the maximum table size can occur between the <del> sending of two header blocks.  In the case that the value of this parameter is changed more than once, if any changed value is smaller than the new maximum size, the smallest value for the parameter MUST be sent in an encoding context update.  The altered maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on the decoder table size (see entry.eviction). </del> <ins> sending of two header blocks.  In the case that this size is changed more than once in this interval, the smallest maximum table size that occurs in that interval MUST be sent in an encoding context update. The final maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on reductions in decoder table size (see entry.eviction). </ins> This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.
Code change:
_RFC EDITOR: please remove this section before publication_ <del> This work was originally based on draft-cavage-http-signatures-12, but has since diverged from it, to reflect discussion since adoption by the HTTP Working Group.  In particular, it addresses issues that have been identified, and adds features to support new use cases.  It is a work-in-progress and not yet suitable for deployment. </del> <ins> Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/signatures [3]. </ins> 1.

Related discussion:
text: This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.
Code change:
request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data. <ins> A server that supports range requests MAY ignore a header field when the selected representation has no body (i.e., the selected representation data is of zero length). </ins> A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific

Related discussion:
text: In 416 status code section, remove duplicate definition of what makes a range satisfiable and refer instead to each range unit's definition. In sections on bytes ranges and Range, clarify that a selected representation of zero length can only be satisfiable as a suffix range and that a server can still ignore Range for that case.
Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others: I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions). Perhaps the following can be added at the end of section 3.1: "If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response." (someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.) I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again. All suggestions and feedback are welcome.
So how do we get this fixed? There was a discussion about it in the IETF mailing list, in which others confirmed the issue. I opened an errata, but it was closed saying it's not an errata. I was pointed here to open the issue, but got no response in 9 months so far. What can I do to get a response or to help move this forward?
Code change:
request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data. <ins> A server that supports range requests MAY ignore a header field when the selected representation has no body (i.e., the selected representation data is of zero length). </ins> A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific

Related discussion:
text: If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it. If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.
We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there. See Roy's response in particular: URL
Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).
NAME Thanks for resolving the issues! Better late than never :-) Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)
An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.
ok. Thanks again!
Code change:
by signalling of connection inforation (bandwidth, latency) based on data sent by the receiver. <del> 4.6. </del> <ins> 4.2.2. </ins> *Senders/Receivers*: One to One *Bi-directional*: No *Latency*: <del> Ultra-Low to Low </del> <ins> Ull-200 to Ultra-Low </ins> Where media is sent onwards to another platform for further distribution.  The media may be compressed down to a bitrate lower than source, but larger than final distribution output.  Streams may be redundant with failover mechanisms in place. <del> 4.7. </del> <ins> 4.2.3. *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: Ull-200 to Ultra-Low Where media is received from a live broadcast or stream.  This may comprise of multiple audio or video outputs with different codecs or bitrates.  This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate change of behaviour in client such as advertisement breaks).  The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past. 4.3. 4.3.1. ** James, can you fill this section in?** 4.3.2. </ins> *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: On Demand

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
such a canonical form. Content identifiers are defined using production grammar defined by <del> RFC8941.  The content identifier is an "sf-string" value.  The </del> <ins> RFC8941.  The content identifier itself is an "sf-string" value.  The </ins> content identifier type MAY define parameters which are included using the "parameters" rule.

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.