jiebi/CodeConvo huggingface dataset:
Code change:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </del> <ins> start and end of the range are inclusive.  EndGroup MUST specify the same or a later group than StartGroup.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error.

Related discussion:
text: This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The terms "HTTP message", "HTTP method", "HTTP request", "HTTP response", "absolute-form", "absolute-path", "effective request URI", "gateway", "header field", "intermediary", "request-target", "sender", and "recipient" are used as defined in RFC7230. </del> <ins> The terms "HTTP message", "HTTP request", "HTTP response", "absolute- form", "absolute-path", "effective request URI", "gateway", "header field", "intermediary", "request-target", "sender", and "recipient" are used as defined in MESSAGING. The term "method" is to be interpreted as defined in Section 4 of SEMANTICS. </ins> For brevity, the term "signature" on its own is used in this document to refer to both digital signatures and keyed MACs.  Similarly, the

Related discussion:
text: separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.
Code change:
Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </del> <ins> The ALPN header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </ins> indistinguishable from the case where either client or proxy does not <del> support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> <ins> support the ALPN header field. The value of the ALPN header field could be falsified by a client. If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the ALPN header field as a policy input in all cases. </ins>

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
might be strongly correlated to membership in a particular ethnic group.  An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites <del> that have been whitelisted, perhaps via interaction after detecting a </del> <ins> that have been explicitly permitted, perhaps via interaction after detecting a </ins> header field that indicates language negotiation might be useful.

Related discussion:
text: Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.
Code change:
have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as an Integer number of seconds delta from the Unix Epoch (00:00:00 UTC on <del> 1 January 1970, excluding leap seconds). </del> <ins> 1 January 1970, excluding leap seconds), using the Date Structured Fields data type defined in date-type. </ins> For example, an Expires field could be mapped as:

Related discussion:
text: I still believe this change should end up in the revision of SF.
That's
Some have pushed back on using integers for dates, see eg URL As I suggested there, one accommodation would be to define a new structured type for them. That could be done in retrofit, or separately.
I see no mention of fractional seconds ? I think we need to ponder that, if the goal is (eventual) convergence for all timestamps in HTTP ? Considering how much effort we spend on speeding up HTTP, I find the "human readable" argument utterly bogus. Only a very tiny fraction of these timestamps are ever read by humans, and most are in a context where software trivially can render the number in 8601 format if so desired. In terms of efficiency, I will concede that, in a HTTP context, it is almost always possible to perform the necessary calculations and comparisons on raw ISO-8601 timestamps, without resorting to the full calendrical conversions, but once all the necessary paranoia is included, I doubt it is an optimization. My preference is seconds since epoch, (and this is largely why has three decimals in the first place), because it gives us fast processing, good compression and millisecond resolution. PS: A Twitter poll with only 40 respondents, carried out on the first monday after new-years ? Really ?!
One argument against any "seconds since epoch" representation is that (at least under the ) it is incapable of representing an instant within a positive leap second (since "each and every day shall be accounted for by exactly 86400 seconds_", any such time would be interpreted as being in the first second of the following UTC day).
For HTTP I think subsecond precision is an overkill due to RTT / intermediaries.
IMHO: I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable. I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ.
Code change:
have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as an Integer number of seconds delta from the Unix Epoch (00:00:00 UTC on <del> 1 January 1970, excluding leap seconds). </del> <ins> 1 January 1970, excluding leap seconds), using the Date Structured Fields data type defined in date-type. </ins> For example, an Expires field could be mapped as:

Related discussion:
text: Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation. I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO. I do like the leap-second argument. I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.
Seems reasonable to me. +1 Not sure this is an "interface" that HTTP exposes / should be relied upon.
I suspect the experience of pretty much everybody writing and deploying HTTP intermediaries and servers at scale is different -- at those rates, cycles wasted on parsing do matter, especially when architectures have many layers of intermediaries to go through.
See linked PR for a proposal.
Re leapseconds: as written ("excluding leap-seconds") means that timestamps will be illegal, effectively mandating POSIX leap-second (non-)handling. To make able to handle leap-seconds requires that every HTTP handling entity needs an up to date file, either at system level or application level, and that the upper limit on the "internal data model range" becomes indeterminable, since we cannot predict how many leap seconds will happen in the future, nor what sign they may have. That is a total no-go from a systems engineering and complexity point of view, in particular as the rest of the world converges on either papering over leap-seconds or abolishing them. If the textual format cannot handle leap-seconds (without requiring a boat-load of complexity), then, why take the extra expense in CPU-load and code complexity ? As stated earlier, we should go for the more efficient and less error-prone solution: POSIX time_t (with optional milliseconds) as a .
Code change:
have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as an Integer number of seconds delta from the Unix Epoch (00:00:00 UTC on <del> 1 January 1970, excluding leap seconds). </del> <ins> 1 January 1970, excluding leap seconds), using the Date Structured Fields data type defined in date-type. </ins> For example, an Expires field could be mapped as:

Related discussion:
text: (If we want to designate the timestamps with a senteniel, 'NAME is a particular bad choice, since the HPACK huffmann assigns it 13 bits.) PS: In context of four digit years: Century scale predictions, based on orbital considerations, expect the current leap-second regieme to break down in approx 2000 years, because we will need leap seconds more often than every month.
Do any current HTTP implementations take leap seconds into account? Regarding HPACK - it's one character. Let's not over-optimise here.
I don't know, but leap seconds are explicitly supported by : And the difference between 23:59:60 and following-day 00:00:00 would certainly be relevant for e.g. Last-Modified.
I have spent a lot of time over the years searching, but I have yet to see a 23:59:60 timestamp in the wild...
Now there's a picture in my mind of PHK walking the wilds, searching for an elusive date stamp.
I don't know what counts as "in the wild", but there is certainly documentation of and .
Discussion at IETF114 wasn't conclusive, but we now seem to be focusing on these options: Do nothing. Dates in SF are Integers (unless folks fall back to Strings), and recipients need to know that they're dates and how to handle them. Create a Date SF type along the lines of the PR. The textual representation is human-friendly, and it's identified as a date in a machine-readable way without special knowledge. Create a Date SF type but use an Integer; e.g., . The textual representation is not human-friendly, but it is identified as a date in a machine-readable way without special knowledge. I'll observe that if we believe that we'll eventually have a binary representation of structured fields widely in use, (2) is preferable in that it has the best properties -- it's both efficient and human-friendly. Of course, that's not at all certain. I'll also observe that in the discussions I've had, the people who want human-friendly representation are generally those who are working with tools and developers, "closer" to the application. The infrastructure folks and "lower layer" folks tend to minimise this aspect.
PR updated to reflect (3) above.
I personally support (2) or because it covers similar use cases than HTTP-date.
Code change:
have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as an Integer number of seconds delta from the Unix Epoch (00:00:00 UTC on <del> 1 January 1970, excluding leap seconds). </del> <ins> 1 January 1970, excluding leap seconds), using the Date Structured Fields data type defined in date-type. </ins> For example, an Expires field could be mapped as:

Related discussion:
text: In case of (3) I think we can just use an Integer SF, like we do Signatures and other specs. Side note: we sometimes hear that RFC3339 is ambiguous. I think it is, and after ~20 years it probably requires a RFC3339bis that clearly specifies a basic profile ( T, Z uppercase; Always ). I'd be happy to start this work.
Why do the number of decimals need to be specified? Surely we could just say the format is nnnnn[.ddddddd] or similar where an integer-only parser stops at whitespace or a '.' while those who care about sub-second parsing continue on until they are satisfied with the resolution or they run out of digits. The senders decides how many decimals to provide, perhaps with a recommendation of three or upto their clock resolution? So "123456789" and "123456789.1" and "123456789.123456789" are all equally valid.
I like this direction; thanks.
Code change:
community has gained much more experience with indications of congestion beyond packet loss. <ins> Multicast congestion controls are a considerably less mature field of study and are not in scope for this document.  However, Section 4 of the UDP Usage Guidelines RFC8085 provide additional guidelines for multicast and broadcast usage of UDP. </ins> Multiple congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft.

Related discussion:
text: Adding a scope that excludes multicast.
Uh, is a PR addressing the same issue -- you were supposed to review it?
Would if this variant is merged
Discussed at IETF-118. At least we can mention Sect 4 of Multicast UDP Usage Guidelines in RFC8085.
IETF 118: Possibility that we could rule this out of scope Also some interest in this as a separate document that comes after the -bis
So just to provide the background for my question. The Reliable Multicast Transport WG (RMT) did produce two expermential congestion control specifications for multicast: So these specifications exists. Most mulitcast deployments are done in controlled environments however, with [Automatic Multicast Tunneling] (URL) multicast traffic these days have more probability to occur across links where this traffic would share bottlenecks with other unicast traffic. However, this amount of traffic is still normally bit-rate bound so it might be considered just in-elastic and consuming the bit-rate it does. I also want to state that I am fine with declaring multicast out of scope, but maybe some information about that there exist algorithms should be includeded in the draft. So an explicit out of scope with some background section/appendix.
We will put it out of scope and point to RFC 8085
Sorry, just reading through these changes now -- Why does a PR on multipath close an issue on multicast? Am I missing something here?
Whoops, that does not seem correct, re-opened this issue.
To answer NAME more directly, I don't think this draft is in the business of listing algorithms unless it requires new proposals to be measured against them, and not even that if the topic is out of scope. 5033bis is not a congestion control tutorial.
NAME I think it is a question of how one resolve this and if one declares it out of scope. Are we explicitly stating something like this: Multicast congestion control algorithms is out scope, and the rules and requirements within this specification has not been evaluated on their applicability for multicast congestion control. Future work on multicast congesiton control to specify new algorithms or update existing [webrc][TFMCC] will have to evaluate what is applicable and if additional requirements are necessary.
Add a changelog item (as in ) and it LGTM.
Code change:
values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). <del> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a </del> <ins> Header lists are collections of zero or more header fields.  When transmitted over a connection, a header list is serialized into a </ins> header block using COMPRESSION.  The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames. <del> HTTP Header Compression does not preserve the relative ordering of header fields.  Header fields with multiple values are encoded into a single header field using a special delimiter (see HeaderOrdering), this preserves the relative order of values for that header field. </del> The COOKIE is treated specially by the HTTP mapping (see CompressCookie). A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header <del> set. </del> <ins> list. </ins> A complete header block consists of either:

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
Code change:
solely responsible for adding the token in the authorization header to calls to the resource server. <del> 6.3.2.1. </del> <ins> 6.4.2.1. </ins> The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself.

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
[3] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 <ins> [4] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 </ins>

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:
forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string. <del> Historically, HTTP field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab ( ).  This document assumes that any such obsolete line folding has been removed prior to interpreting the field value (e.g., as described in line.folding). </del> 5.6. 5.6.1.

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.