jiebi/CodeConvo huggingface dataset:
Code change:
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>

Related discussion:
text: As for the general case of c14n, it's unfortunate that this is necessary, but it is probably better than relying on having some shared understanding of an abstract model for the resource representation. I would not build this on any assumption that XML c14n is possible. A complete solution there is likely impossible. I know less about the warts of JSON, but even that is entering into dangerous territory. You might get more traction with schema-aware c14n with the understanding that it is not generally applicable to any document. That is, define tools so that specific XML- or JSON-based formats can opt in to the use of c14n. People might then apply that c14n if the format allows it; people might also apply the c14n if the format does not, but we have not promised them anything and so guarantees might not apply.
nod there's going to be a tradeoff between the amount of knowledge/processing necessary for c14n and cache efficiency. It might be good to explore what conventions a format needs to follow to make it easily canonical; I can't help but think that most use cases for this are going to be defining a new query language, not reusing an existing document or even data format.
I think that caching is a "must have", though probably we could just provide minimal hints and leave clients the onus of hitting the cache (eg. clients c14n-izing requests in some may increase cache hits). I won't mess with the request media-type (json? xml? x-www-form-urlencoded? ...) and just use the content checksum (eg. ). I think that supporting media-type aware caches is really hard to implement (eg. see rfc8785 and rfc7493 only for json): there's room for experimental specs though... That's ok, though see (2) about supporting media-types is hard Agree wrt Security Considerations IF we want to support a caching based on a response cache key, this could be implemented with some caveats without re-sending the at all: Authentication information should be processed; MUST NOT contain authnz information
Caching will be tricky for "similar" requests sent by different clients. On the other hand, caching could be simple for requests that are repeated by the same client (like in a refresh operation).
Code change:
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>

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:
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>

Related discussion:
text: (opening this so it has a discussion venue) Currently, the spec uses "SEARCH" (for the reasons given in the spec). Alternatives: 1) pick a new name 2) use GET with payload (probably unrealistic, just listed for completeness) 3) use POST and find a way to label it as safe 4) re-use another existing safe method that takes a body (PROPFIND, REPORT) (just listed for completeness) The obvious drawback in "pick a new name" is the forseealke bike-shedding.
Just my .02. Using is initially attractive because it's familiar; effectively we'd be extending the semantics of the method with a header. However, I'm not sure it's a good idea. implies certain guarantees to clients, servers and intermediaries -- e.g., write-through. If an extension can change those guarantees, it's important that they're visible to all components, and an extension (e.g., a header) by nature can't guarantee that. It seems to me that one of the critical things to do is to get a positive indication from the user agent that the request they're sending doesn't have write-through, so a extension would need to carry an indication from the client. However, the origin server is also likely to need to convey a cache key and perhaps additional information, which leads this approach to something that's looking complex; the client has to send a certain header, the server has to send a certain header, and an intermediary still might not understand what's going on (which might be good or bad). So that makes me lean towards the status quo, (1), or (4) as being more straightforward. Reusing an already-deployed name has been discussed elsewhere; I'm not convinced that it's going to add a lot of value, considering that most traffic is HTTPS now and so intermediaries with fixed lists of supported methods are much less common. If we had data that they'd get through e.g., an enterprise virus scanning proxy whereas a new method wouldn't, I'd be interested to see that. Still, if fits the bill adequately, I think it's fine. The real test will be whether folks (especially HTTP API developers) find it compelling enough to use; I'm not sure quite gets there, but it's in the ballpark. If we're going to consider new names, I'd suggest .
Code change:
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>

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:
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The request content MAY be empty.  If the "Upload-Complete" header field is then set to true, the client intends to upload an empty entity.  An "Upload-Complete" header field is set to false is also valid.  This can be used to create an upload resource URL before transferring data, which can save client or server resources.  Since informational responses are optional, this technique provides another mechanism to learn the URL, at the cost of an additional round-trip before data upload can commence. The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a

Related discussion:
text: This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?
Code change:
Let output be an empty string. <del> For each member mem of input_dictionary: </del> <ins> For each (member, parameters) of input_dictionary: </ins> Let name be the result of applying Serializing a Key (ser-key) <del> to mem's member-name. </del> <ins> to member's member-name. </ins> Append name to output. Append "=" to output. <del> If mem is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to mem. </del> <ins> If member is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to member. </ins> Otherwise, let value be the result of applying Serializing an <del> Item (ser-item) to mem. </del> <ins> Item (ser-item) to member. </ins> Append value to output. <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_dictionary: Append a COMMA to output.

Related discussion:
text: Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
Code change:
This specification registers the following entry in the HTTP/2 Settings registry established by HTTP2: <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES </ins> 0x9

Related discussion:
text: RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.
Code change:
Bit 2 is reserved for future use. <del> Bit 3 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </del> <ins> Bit 3 being set indicates that the Pad Low field is present. </ins> <del> Bit 4 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST

Related discussion:
text: Felt that this order was clearer since the requirement then back-referenced the previous flag instead of forward-referencing it. Feel free to ignore if you disagree.
I considered that option. I think that it's easier if the order of the bits is the same as the order the fields appear. I'll reopen and take this if others point this out though.
Confused by that. In the as-written docs the flags are: [R, R, R, R, PADLOW, PADHIGH, R, ENDSTREAM] but the frame layout is: [PADHIGH (8)], [PAD_LOW(8)] so the order of the bits is opposite the field order.
Let's chalk this up as yet another case of blindness on my part.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: Fixes URL
nit: can you wrap the lines at 80 chars?
In the call last Wednesday, we agreed this design was the correct approach, so merging even though there are some reviews outstanding requesting changes.
Consider an edge relay, receiving and forwarding relative SUBSCRIBE requests for -5, -3, and -1 for the same track. The first object it receives back is group 37. It cannot tell where to place this object in the sequence and must therefore hold it until it knows more information. If the next object is Group 39, it still cannot forward it, because the head sate is undefined. We can solve this problem simply by having the SUBSCRIBEOK response indicate the latest group and object number: SUBSCRIBEOK { Track Namespace (b), Track Name (b), Track Alias (i), Expires (i), LastestGroup(i), LastestObject(i) } One consequence of adding these fields is that an edge, which has no active subscription for the track, cannot send the SUBSCRIBEOK response until it itself receives a SUBSCRIBEOK after forwarding the SUBSCRIBE. This makes subscription an async process in which the acknowledgment of the subscription may take in some cases a RTT back to the origin. I think this is necessary for stable state management.
+1 this is required to build a relay and a non-realtime player. This was required anyway, otherwise the relay would swallow any application SUBSCRIBEERROR codes. My mental model is that SUBSCRIBEOK == HTTP response headers.
Moqt is a pub/sub protocol and is hop-by-hop protocol. A subscribe ok means the susbcribe request was validated at the relay. A OK isn't tied to getting a OK from the original publisher. Its sub/sub-ok is a async operation ( like any typical pub/sub systems out there). An ok for subscribe means a promise that if there is a matching data ( either in cache or coming in from a live publisher at some point), it will be forwarded .
Clarifying question , if the use-case is something like VOD or non real-time flows, I think the same can be done by
I absolutely don't want this behavior. It means that a generic relay will always return SUBSCRIBEOK, even if it cannot route (or authenticate) a SUBSCRIBE. A typo or finished broadcast would be indistinguishable from a valid request unless OBJECTs start to flow.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: SUBSCRIBEOK would be equivalent to HTTP 100 CONTINUE, which is truly useless, and there would be no equivalent to 200 OK or 404 Not Found. Pub/sub doesn't mean black hole simulator either. I've only used RabbitMQ a long time ago, but if you tried to bind a queue (ie. SUBSCRIBE) to an exchange (ie. ANNOUNCE) it will return an error if the exchange doesn't exist. Is the justification that pub/sub protocols are supposed to black hole, or is this behavior that you actually want? Instead of hanging indefinitely if a relay can't route a SUBSCRIBE, wouldn't it just be better to receive a 404 Not Found? You're allowed to try again, but now there's no timers or guess work as to if the SUBSCRIBE could be routed to an origin.
It's for higher latency targets. HLS/DASH clients don't start at the latest segment, but rather start further back based on the target latency. If I understand correctly, you're saying the relay: has an empty cache. receives a and . issues issues a live subscription upstream: waits for the first OBJECT to arrive for that subscribe, using it as the live playhead: issues a backfill subscribe upstream: forwards any objects based on the mapping from relative to absolute. It works for relays, but at the cost of an extra round-trip to origin. However, it won't work for clients that want to start playback N groups back (jitter buffer size), because the player doesn't know when/what to render without first receiving N distinct groups. Here's what we would like: has an empty cache. receives a and . (re)issues a subscription upstream: waits for forwards any objects based on the mapping from relative to absolute.
Individual Comment: I think SUBSCRIBEOK needs to resolve all relative Subscribe Hints that were passed in the Subscribe. Otherwise, I'm really not sure how my library will know when an Object arrives if it belongs to a particular subscription or not -- the OBJECTs that arrive have only track name and absolute group/object numbers. I see the use case for some relays wanting to optimistically SUBSCRIBEOK, but then there would need to be a follow up message that resolves the relative hints when the relay finds out where they map.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: Couple of observations what use-cases would involve same client sending multiple subscription hints at the same time ? Hints are read access points on the same track and if a client ask for multiple such points, it will get objects on the same track regardless .. how relays puts them together in such a case for a given client cannot be normatively specified NAME can you give me a concrete use-case example of "resolve all relative Subscribe Hints that were passed in the Subscribe" from a single client so that it helps understand the issue better. I personally don't think the issue being discussed is directly related to this ...
The use case of an edge relay forwarding simultaneous requests from multiple connected clients. This is a common use-case for any edge or fan-out relay.
Individual Comment: This is definitely one use case. Another is a client making two simultaneous subscriptions: eg live edge and range request starting some time in the past.
One thing that will not scale is every subscription needing to go back to the original publisher. Consider the cases of a million users are joining a session that starts at the top of the hour and that is published from a mobile device. I think that in any real system there is also going to be no single idea of the live edge. The live edge is relative to which relay you subscribed to. If the relay you are on is over a geo sync satellite, it is going to be behind ones that are not. So here is what I think we should do. We should not allow relative subscription to things in the past. I think the uses cases I have heard for this can be deal with as subscribe to live edge forward and as once the client find out what object that is, do an absolute subscribe for any data in the past to fill in buffers etc. So to be clear, no relative group or object sequences that are negative but still allows absolute. This seems to meet the use cases and remove a ton of edge case design problems. To be clear, I think we should be able to subscribe to the current group, but give me object 0 forward in that group. If it is a group per GOP, this allows one to get everything needed to decode the current frame.
But not every subscription has to go back to publisher. It only has to go back to a node that is already subscribed and understands the live edge. Furthermore, concurrent requests would be coalesced at each node.