jiebi/CodeConvo huggingface dataset:
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: The encoder at both client and server is initialized with a dynamic table size of 4,096 bytes, the initial value of the SETTINGSHEADERTABLESIZE setting. Any change by the decoder to the maximum value takes effect...". This makes it clear that the initially advertised value is a change, which currently is the main point of disagreement. Proabably that we should wait for the end of new year holiday before merging it, so that other implementers for whom this is a change of behavior can have a look.
NAME NAME it would be nice if you, as implementers, could have a look at the proposals here, given that your implementations will need to be updated as well. In haproxy this results in a little ugly trick where the H2 layer has to inject an HPACK opcode (0x20). That's trivial but ugly enough that it warrants a second thought before jumping on any final solution.
NAME Apache is lazy and uses libnghttp2 for h2 protocol handling. It does not change the dynamic table size and all its handling and ACKs are done by nghttp2 transparently. If any changes are necessary, I'd expect them to come with an updated version of libnghttp2 and, since that is linked dynamically, no need to us to release anything new.
NAME I actually wonder if you failed to push the branch here, I saw new commits being pushed to URL instead.
Ugh, my bad. Having two remotes sometimes bites me. Sorry about that Willy. (And thanks for noticing Kazuho.)
No problem Martin, don't be sorry, you're the one doing the job :-) I'm almost fine, almost everything is OK but there remains one ambiguity in that sentence: "A decoder MUST treat a field block without a sufficiently small Dynamic Table Size Update instruction that follows an acknowledgment of a reduction of SETTINGSHEADERTABLESIZE as ...". It ought to be "a reduction of SETTINGSHEADERTABLESIZE below the current size of the header table size etc" (which is slightly different since we don't want to have to re-emit a DTSU if the previous value was already smaller).
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: Given that this principle was explained in the previous sentence, I think we can simply address this by adding the word "such" before "a reduction": "... follows an acknowledgement of such a reduction of SETTINGSHEADERTABLE_SIZE", or probably even simpler, write "acknowledgement of such a change".
Ahh, yeah, it's hard to balance correct and clear here.
I think it's OK now. NAME NAME , care to recheck ?
Good catch indeed!
OK for me as well now. Let's hope it will not cause difficulties (e.g. for those who would pre-queue stream frames).
Enqueuing stream frames (or any frame) and then allowing a settings change to occur ahead of those frames is very risky. Anything that you do in those frames might violate a changed constraint. If you must, enqueue all frames, SETTINGS included.
I generally agree, but it's a matter of design choice (or constraints). Before this change nothing implied a possible change of headers frames representation after the requests started to flow, so that was technically possible. There are not that many H2 implementations anyway so we'll see. But I also agree that here at least we keep the option of postponing the SETTINGS ACK frame, which leaves some options open if this issue is raised. Thanks!
Hi Cory, I suspect, as you suggested in your last sentence, that writing "HPACK encoder" and "HPACK decoder" here would remove any ambiguity. Of course we know it's not the HPACK encoder in terms of code that acks for example, but it's the same endpoint and that is sufficient to declare who does what.
I've taken Mike's suggestion and mixed in a few "HPACK decoder" and "HPACK encoder" statements, using "endpoint" for protocol actions (settings, connection errors). Tell if this makes more sense to you NAME or if I've messed it up.
aside the typo above, LGTM. Thanks Martin!
NAME I guess we've left it long enough for reviews, it's probably okay to merge it by now, what do you think ? As a bonus it would close the last issue.
Opening a new issue as I notice that has been merged already.
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: Text added by states: An encoder sends a Dynamic Table Size Update instruction after acknowledging a change of SETTINGSHEADERTABLESIZE even if it is not changing the size of the dynamic table or an increase to the maximum size is subsequently reverted before the field block is sent. I am not sure if this correct interpretation of RFC 7541, and also am concerned that this text might cause new interoperability issues. states: A change in the maximum size of the dynamic table is signaled via a dynamic table size update (see Section 6.3). This dynamic table size update MUST occur at the beginning of the first header block following the change to the dynamic table size. In HTTP/2, this follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]). As can be seen, this paragraph of RFC 7541 starts "a change." When an HTTP/2 endpoint is using an HPACK encoder with a dynamic table of size 4,096 (the default) and receives SETTINGSMAXHEADERLISTSIZE of 4096, it is not changing the size of the dynamic table. My interpretation of RFC 7541 would be that it does not require Dynamic Table Update Size to be sent when the table size remains the same. Interoperability-wise, do existing servers respond with a Dynamic Table Update Size instruction when the client sends SETTINGSMAXHEADERLIST_SIZE no less than 4096? It seems to me that this newly added text suggest such behavior is required, but I'm not sure if many servers behave as such. added text indicating that endpoints MAY error-close the connection when not seeing such behavior. Even if we are to agree that Dynamic Table Size Update MUST be sent in all cases, I'm concerned that we might see more interoperability issues by suggesting that endpoints can error-close.
Yup, I think this works well. Nice work NAME
Code change:
4.1. When a cache receives a request that can be satisfied by a stored <del> response that has a </del> <ins> response and that stored response contains a </ins> <del> header field (field.vary), it MUST NOT use that response unless all the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request. </del> <ins> header field (field.vary), the cache MUST NOT use that stored response without revalidation unless all the selecting header fields (nominated by that Vary field value) in the present request match those fields in the original request (i.e., the request that caused the cached response to be stored). </ins> The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in

Related discussion:
text: replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...
Code change:
and leave last-byte-pos absent.  A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) may respond with a 206 status code (Partial <del> Content) with a Content-Range header indicating the currently </del> <ins> Content) with a Content-Range header field indicating the currently </ins> satisfiable byte range.  For example: returns a response of the form:

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
4.1.1. <del> HTTP header fields are registered within the "Message Headers" registry located at <https://www.iana.org/assignments/message- headers>, as defined by BCP90, with the protocol "http". </del> <ins> The "Hypertext Transfer Protocol (HTTP) Header Field Registry" defines the namespace for HTTP header field names Any party can request registration of a HTTP header field.  See considerations.for.new.header.fields for considerations to take into account when creating a new HTTP header field. The "HTTP Header Field Name" registry is located at "https://www.iana.org/assignments/http-headers/".  Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Header field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Header fields with the status 'permanent' are Specification Required (using terminology from RFC8126). Registration requests consist of at least the following information: The Expert(s) can define additional fields to be collected in the registry, in consultation with the community. Standards-defined names have a status of "permanent".  Other names can also be registered as permanent, if the Expert(s) find that they are in use, in consultation with the community.  Other names should be registered as "provisional". Provisional entries can be removed by the Expert(s) if -- in consultation with the community -- the Expert(s) find that they are not in use.  The Experts can change a provisional entry's status to permanent at any time. Note that names can be registered by third parties (including the Expert(s)), if the Expert(s) determines that an unregistered name is widely deployed and not likely to be registered in a timely manner otherwise. </ins> 4.1.2.

Related discussion:
text: For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.
Code change:
. <ins> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (RFC1952).  The compression only applies to the frame in which it is signalled, and no compression state is carried over from frame to frame.  An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless it receives a parameter set to a value of 1.  An endpoint that has not both set this parameter to 1 and had it acknowledged MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type

Related discussion:
text: A proposal for adding GZIP compression to DATA frames. One possible resolution for .
This looks good. Thanks for putting this together. We'll see how the discussion progresses.
I realise we might also want to modify Section 8.1.3.5 Malformed Messages, to explain that Content-Length either cannot be sent if any frame is compressed, or measures the length after inflation, depending on how closely this maps to transfer encoding (URL). I suppose that's a follow-up issue for the WG to discuss.
No. You are right. Content-length applies pre-compression or post-decompression. We need to that clear. On Apr 22, 2014 4:28 PM, "Matthew Kerwin" EMAIL wrote:
Code change:
6. <del> SNAC networks rely on IPv6 to enable routing between links, which </del> <ins> stub networks rely on IPv6 to enable routing between links, which </ins> would not be possible with IPv4 due to the lack of a standard mechanism similar to Router Advertisements in IPv4.  However, it can <del> stll be useful for hosts on the SNAC network to establish </del> <ins> stll be useful for hosts on the stub network to establish </ins> communications with IPv4-only hosts on the infrastructure network. Although NAT64 provides IPv6-only hosts with a way to reach IPv4 hosts, there is no easy way for an IPv4 host to use NAT64 to originate communication with an IPv6 host.  Therefore, this document <del> enables IPv6 hosts on the SNAC network to discover and reach with </del> <ins> enables IPv6 hosts on the stub network to discover and reach with </ins> IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the <del> SNAC network. </del> <ins> stub network. </ins> This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6

Related discussion:
text: As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed
Code change:
resources which uses a checksum that is calculated independently of the content (see Section 6.4 of SEMANTICS).  It uses the representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the content, or not contained at all: </del> <ins> or partially contained in the content, or not contained at all. </ins> This takes into account the effect of the HTTP semantics on the messages; for example, the content can be affected by Range Requests

Related discussion:
text: [x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] * 4. A reference to SEMANTICS 12.4.2 is necessary.
Code change:
Abstract <del> This document explains the risks of using early data for HTTP and describes techniques for reducing them.  In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation. </del> <ins> Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay. </ins> 1.

Related discussion:
text: John Mattsson pointed out that we didn't really discuss the risks of use of early data. That's fair, but we don't need to. This rewrites the abstract.
Just one fix : s/mechanisms that allows/mechanisms that allow/ Nice overall.
Code change:
. The <del> claim is used to express the type or types of the JSON object that is contained in the JWT payload.  In the general case, the </del> <ins> claim is used to express the type of the JSON object that is contained in the JWT payload.  The </ins> <del> value is an array of case-sensitive strings, each containing a value.  In the special case when the SD-JWT has one credential type, the value MAY be a single case-sensitive string containing a </del> <ins> value MUST be a case-sensitive </ins> value. The following is a non-normative example of how <del> is used to express a single type: The following is a non-normative example of how is used to express multiple types: </del> <ins> is used to express a type: </ins> 5.1.2.2.

Related discussion:
text: Pros: selective disclosure of types possible to increase privacy and to reduce contextual info more granular types possible issuers don't have to issue multiple credentials Cons: polymorphism always is a challenge, we that with no support in SD-JWT yet to selectively disclose array elements
After further discussions it seems that multiple types might cause difficulties with JSON schemas. If multiple types are required in the future (e.g. more implementer's feedback), we can update the specification. So, let's make a single string value.
Code change:
The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.

Related discussion:
text: It seems like it would be better to transfer this in the STREAMHEADERTRACK and equivalent. Thoughts on that ? I also worry about how long a subscribe would wait to find out this information - that seems like it could be problematic for the client knowing when to give up on a subscribe. Hopefully we can discuss in Denver
Code change:
The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.

Related discussion:
text: This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.
Code change:
The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.

Related discussion:
text: Regardless of where they're retrieved from and over time.
I put a two very small nit comments but don't care either way. They do not change the substance of the PR and +1 on the overall thing this is saying.
This came as part of interim at Denver when discussing multiple announce for same track. There needs to text that mandates, if 2 objects comes with same name, they need to be bit identical. Also needs to clarify on how long the name needs to be unique