jiebi/CodeConvo huggingface dataset:
Code change:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.04. </del> <ins> The changes in this draft are summarized in changes.since.05. </ins> 1.

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.
Code change:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.04. </del> <ins> The changes in this draft are summarized in changes.since.05. </ins> 1.

Related discussion:
text: I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.
Code change:
response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested. <ins> The above does not imply that a server will send all requested ranges.  In some cases, it may only be possible (or efficient) to send a portion of the requested ranges first, while expecting the client to re-request the remaining portions later if they are still desired (see status.206). </ins> If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a

Related discussion:
text: URL This seems to place a requirement on the server to serve enough of the representation that all satisfiable ranges requested are fulfilled. But that's actually a burden and makes range requests not as useful as they could be: a server might well not want to implement multipart/byteranges, which is an awkward format that can't be streamed without prior knowledge of what strings are safe to use as separators; responding with a single range is much simpler to implement. If all satisfiable ranges must be served, then, without multipart/byteranges, the only compliant options for responding to a range request with large distances between the requested ranges involve sending all of the bytes in between. Even reading the text as meaning that servers MUST NOT only serve a portion of the satisfiable ranges, client behaviour when faced with a misbehaving server is under-specified; the sensible options are re-requesting unfulfilled ranges, retrying without ranges, or signalling an error. Retrying without ranges may be wasteful, and raising an error seems overly fussy - and, if either of those is the better or even necessary option, that definitely ought to be called out. I'd be surprised if retrying without ranges or erroring was needed, because section 10.3.7.3 (Combining Parts) already deals with combining multiple 206 responses together. So, I think it'd make sense to make two changes here: An explicit SHOULD on clients receiving a 206 to check the ranges that they actually received and make further range requests if they still need any ranges which weren't included despite being satisfiable, which they can determine because Content-Range includes enough information to tell which were unsatisfiable and which were simply not fulfilled. Explicitly say that servers MAY only serve a portion of the satisfiable ranges.
It says "one or more" for exactly that reason. A requirement to send all would have to say ALL, so this is clearly not the case.
Wouldn't the text then be or something very similar? As presently written, I can't come up with a parse that unambiguously means that some of the satisfiable requested ranges may not be fulfilled - and, in any case, I do think the client behaviour on ranges not being fulfilled needs to be specced a bit more.
Code change:
response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested. <ins> The above does not imply that a server will send all requested ranges.  In some cases, it may only be possible (or efficient) to send a portion of the requested ranges first, while expecting the client to re-request the remaining portions later if they are still desired (see status.206). </ins> If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a

Related discussion:
text: I read the current text as implying that in normal operation, the server will send all of the requested data back in some form; it might be in one range or multiple ranges, depending on its preferences and capabilities. NAME AIUI you want to rewrite this so that when a client sends (for example) requests for ranges 10-100, 500-1000 and 5000-6000, the server can just choose to send one (or two, in theory) of those ranges back, rather than all of them. That might be easier for the server in a number of ways, but it relies on the client recognising that the missing ranges need to be re-requested, one-by-one; effectively, it's a new protocol. As such, if you want to enable this new pattern, I think you'd need to signal support for it in some fashion from the client. That's out of scope for this spec effort; it would be an extension.
That is indeed what I'd like to have. I think there's definitely still room for at least clarifying the situation, given that two editors here read the text in two contradictory ways! Hmm, I don't quite agree. A well-behaved server would want to see support signalled before leaving some ranges unfulfilled and I agree that that would be a new protocol, but a malfunctioning or badly-behaved server might be ignoring the send-all-ranges requirement - I think that's especially likely to be happening in the wild given that the spec here is hard to interpret. Clients will still have to deal with that, and the spec can at least list reasonable options (re-request satisfiable-but-unfulfilled ranges, re-request the whole thing, error). Here's a new straw suggestion that (I think) doesn't change the required behaviours, just formalising and clarifying exactly what's required: An explicit MUST on servers returning enough of the representation to fulfil all satisfiable ranges. An explicit SHOULD on clients checking the Content-Ranges sent back, just in case a server is misbehaving, and list the three sensible options after detecting misbehaviour with MAY.
In normal operation, a server will try to send all of the requested information just for the sake of avoiding another request, unless it doesn't want to for its own reason that we have no need to describe. A 206 response is self-descriptive.
Code change:
response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested. <ins> The above does not imply that a server will send all requested ranges.  In some cases, it may only be possible (or efficient) to send a portion of the requested ranges first, while expecting the client to re-request the remaining portions later if they are still desired (see status.206). </ins> If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a

Related discussion:
text: A client cannot interpret the response differently than how the response describes itself. The client cannot assume it has all the requested ranges it requested. There is no need to require that a server send all requested parts. There is no reason for a client to assume it would receive all of the parts without looking at the response. Hence, this is not subject to an interop requirement. The text I'd consider adding is a note at the end of that paragraph, like
Alternatively, just add that requirement to the section on 206.
I think the most compliant server response, if it doesn't support multipart/byteranges, is to respond with the range 10-6000. Servers are allowed to send different ranges than the client asked for, but I think a server omitting some of the requested ranges can't really claim to be "successfully fulfilling a range request." The server's response needs to include the bytes the client asked for. That said, I think something like NAME suggested text would be helpful. I've seen clients get tripped up before when the server produces a different set of requested ranges, either by extending a requested range or by coalescing ranges. It looks like a rewording of the text at the end of 10.3.7.2, which would be appropriate to either replicate in 10.3.7.1 (you can't expect exactly the range you requested) or move up to 10.3.7.
Code change:
After that is complete, please update the new registry with the field names listed in the following table. <del> Furthermore, the field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </del> <ins> The field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </ins> header field (field.vary).

Related discussion:
text: The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.
Code change:
The header field corresponding to the referenced entry is emitted. <del> The referenced header table entry is added to the header table. </del> <ins> The referenced header table entry is added to the reference set. </ins> A _literal representation_ that is _not added_ to the header table entails the following action:

Related discussion:
text: Instructions for Indexed Representation of entry already in header table say to add entry to header table again, don't mention reference set.
Code change:
6. <del> This specification defines the media type which describes the VP-SD-JWT with the following components: </del> <ins> This section defines encoding, validation and processing rules for VP-SD-JWTs. </ins> 6.1. <del> The following is a non-normative example of a VP-SD-JWT without holder binding: </del> <ins> VP-SD-JWTs compliant with this specification MUST use the media type </ins> <del> The following is a non-normative example of a VP-SD-JWT with holder binding: </del> <ins> as defined in {#application-vp-sd-jwt}. </ins> 6.2. <del> TBD: same as VC-SD-JWT (-> refer to SD-JWT) + Holder Binding </del> <ins> VP-SD-JWTs MUST be encoded using the SD-JWT Combined Format for Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. VP-SD-JWTs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. 6.2.1. If the VP-SD-JWT includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored. 6.3. The following is a non-normative example of a VP-SD-JWT without Holder Binding: The following is a non-normative example of a VP-SD-JWT with Holder Binding: 6.4. The Verifier MUST process and verify an VP-SD-JWT as follows: </ins> 7. <del> TBD </del> <ins> TBD: Verifier provided . </ins> 8. <del> TBD </del> <ins> TBD: Holder provided nonce via . </ins> 9.

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
Code change:
knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST <del> include an Http2SettingsHeader header field. </del> <ins> include exactly one Http2SettingsHeader header field. </ins> Requests that contain a request entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that

Related discussion:
text: I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.
Code change:
Expired cookies. <del> Cookies whose secure-only-flag is not set, and which share a domain field with more than a predetermined number of other cookies. </del> <ins> Cookies whose secure-only-flag is false, and which share a domain field with more than a predetermined number of other cookies. </ins> Cookies that share a domain field with more than a predetermined number of other cookies.

Related discussion:
text: The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .
Code change:
Signed Statement about an Artifact.  Issuers may Register new Signed Statements about Artifacts, but they cannot delete or alter Signed Statements previously added to the append-only Log.  A Transparency <del> Service may restrict access to Signed Statements through Role Based Access Control, however third parties such as Auditors would be </del> <ins> Service may restrict access to Signed Statements through access control policies.  However, third parties (such as Auditors) would be </ins> granted access as needed to attest to the validity of the Artifact, <del> Feed or entirety of the Transparency Service. </del> <ins> Feed or the entirety of the Transparency Service. </ins> Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
will buffer or delay message forwarding for the sake of network efficiency, security checks, or payload transformations. <del> 5.5.1. </del> <ins> 5.6.1. </ins> The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on

Related discussion:
text: and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.
Code change:
TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but <del> has a different name.  This makes it ambiguous whether post-handshake authentication is allowed in TLS 1.3. </del> <ins> the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. </ins> <del> This document clarifies that the prohibition applies to post- handshake authentication but not to key updates. </del> <ins> This document updates HTTP/2 to similarly forbid TLS 1.3 post- handshake authentication. </ins> 2.

Related discussion:
text: This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.
Code change:
tx-mode: Implementations SHOULD NOT include this parameter within SDP. If no tx-mode parameter is present, a value of "SRST" MUST be inferred. <del> Support for the "MRST" and "MRMT" modes is OPTIONAL; implementations that do not support the "MRST" or "MRMT" modes MUST NOT include these modes in the tx-mode parameter. </del> <ins> Implementations MUST support "SRST"; support for "MRST" and "MRMT" is OPTIONAL. Implementations that do not support "MRST" or "MRMT" MUST NOT include these tx-mode values in SDP. </ins> sprop-sps, sprop-pps, sprop-vps, sprop-sei: H.265 allows sequence and picture information to be sent both in-band and out-of-band.  WebRTC implementations

Related discussion:
text: Add discussion of the tx-mode SDP parameter. Fix for Rebase of
NAME PTAL
I think we need a different approach. We want to say that support for "SRST" mode is mandatory If no tx-mode parameter is present, a value of "SRST" MUST be inferred. It is up to the offering implementation whether to include SRST or omit it. implementations that do not implement the other modes should not negotiate a codec with that mode
NAME Updated the PR to include your suggestions.
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.