jiebi/CodeConvo huggingface dataset:
Editorial change only. The idea is to read as soon as data arrives in the TCP buffer. In practice, this is not necessary, but leaving things in the TCP buffer indefinitely can deadlock. (Some implementations of over TCP-based protocols do this and in this case it is BAD.) For .
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer.
The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12.
----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Yeah, good rewording here.
Leaves registration of "" for .
Yes, seems to be a bug in bap. Will check.
it uses "" / #vary but "vary" is a token, and token allows "" anyway. Also, see .
In particular, "" is a valid field name. We probably should reserve it in the registry.
(CORS has an issue like that as well, including for a method; see the note at URL)
Proposal: vary-by = "" / field-name Vary = 1#vary-by Then state that if "" appears, no "real" field-name is allowed to appear as well (for backwards compat). Do we need to discuss cases like Vary: , ?
I don't see why that is an improvement.
I thought we were going to reserve and define its meaning in prose...
I.e., it should just be
which implies registering "*" as reserved field name, right?
Yes. That's
Discussed; will create a PR to move ABNF and prose to list-based.
Do we need to list that as change from 7230?
Probably a good idea; will commit to master and link here.
hit the wrong option
Closes URL NAME mind taking a look?
(NAME would you mind adding NAME to the repo as a collaborator so I can ask him to review via the GitHub tool? :) )
Ping.
Invite was sent a while back. Still listed as "pending."
It is an internal flag, but I don't think the PR needs additional documentation. The change we're making is in the middle of an algorithm, and is basically a variable that was set earlier in the process. I think folks reading the document will understand that. :)
Thanks for the review! I'll merge this, and look forward to your PR adding yourself as an editor.
RFC 6265 section 5.3 defines a cookie by the name, domain, and path. However, given these two headers in a response from a request to URL Set-Cookie: mycookie=nothostonly; URL Set-Cookie: mycookie=hostonly Most browsers will have two cookies since they include host-only-flag in their definition of a unique cookie. I'd like to update section 4.1.2 and 5.3 to reflect the behavior of modern browsers with regards to host-only-flag.
Discussed in Berlin; seems reasonable.
I probably need to read more of the context but would it be useful to point out that this is an internal flag for the user agent? It is, right? Inferred from whether the setting of the cookie included the domain or not.
Small editorial clarification on duplicate track alias for subscriptions that addresses aspects of
As I read the draft, is the distinguisher of a given subscription. is made unique for a subscription state by indicating "If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error." The is mentioned as "A session specific identifier for the track.". It is initially set by the subscriber, where the publisher MAY reject... likely not if it wants to avoid long subscribe times. The draft does not indicate that the track alias is a hash of track or not. If the client implementation uses a sequence ID for both subscribe ID and track alias, then it could result in duplicate subscribes that would result in the relay building state, propagating the subscribe toward the publisher to solicit a response of OK/ERROR. In some implementations that support headless publishers, the relay would send a subscribe OK immediately. The edge relay that has the connection to the publisher performs state compression of subscribes, but that's only at the level per the draft. In this case, the track alias is different, resulting in a new subscribe (duplicate when looking at the ) being created to the publisher. The publisher receives the subscribe with a new and and starts to publish data objects using the and that match internally the track . If one or more clients do this repeatedly, it would result in all relays and the actual publisher itself sending duplicate data that matches . Below diagram illustrates the above. I'm sure there are many reasonable fixes for this... below are a few. This would change the verbiage of duplicate track detection to perform duplication check on and instead of only on track alias. The state machine for subscribe SHOULD change to move from TO . This simplifies the state machine by reducing the complexity in: detection and elimination of duplicate subscribes eliminating the challenges with having to deal with trial and error responses A hash of namespace and name would allow for the duplicate track detection to work per draft, but... Track alias has a max value of 62 bits. Collisions are the largest pitfall for using a hash of two values. Registry/directory service could act as gatekeeper of track aliases. While this would work, it introduces another micro service for a simple pub/sub, which isn't great. It will also slow the subscribe process down. Many other issues will likely arise with this approach.
I don't understand duplicate subscribes issue here ? can you please elaborate .
If a subscriber sends 2 subscriptions for the same track to a publisher ( ignoring relays for a bit here and also ignoring any form if Ids ), what should be the expected behavior of the publisher ? There are few options Publisher sends 2 copies of the objects (wherever they overlap) Publisher rejects the second subscribe since it is in the same connection Publisher sends only 1 copy of the overlapping objects What is in draft today allows for 1.
Clarification on relay vs publisher needs to be distinct here. When discussing this topic, we need to be distinct on is the request for a range of objects (aka fetch operation where there is a start and finish?) or subscribe to live stream where there is no known end? Some of the challenges here are introduced with the MOQT decision to overload to support both fetch operation and subscribe to live stream, possibility starting at X. In the case of fetch operation, subscribes do not get forwarded to original publisher or to other relays, they are instead immediately fulfilled by the first hop relay, which may pull the data from some distributed/localized cache. It is totally acceptable that fetch based subscribes (aka filter type 0x4), can be in duplicate... although I suspect that is a mistake/error on the client side to request at the same time overlapping/exact same data. Regardless, it's not a big deal for the relay to satisfy this repeated request over the same data at the exact same time, but there needs to be some level of rate limits established to mitigate DoS. While MOQT doesn't need to define the limits, it does need to support error responses that the limit has exceeded. In the case of live stream, IMO it's 100% mistake for any client to ask for the same live stream twice via the same QUIC connection. While talking with NAME , he mentioned a possible use-case where there are two or more displays that you want to display the same content to. If the display has IP connectivity, it should be reasonable that the display would have connected and subscribed to the content, hence moot. In the case where the display does not have IP connectivity, a HUB device could be used that does have IP to act as the MOQT client to receive the data content.
IMO, it does not make sense that anyone would want duplicate live feeds of the same data via the same QUIC connection. Instead, if the HUB device has multiple displays that are not IP connected and cannot make MOQT connections themselves, they likely have some other method to mirror content, such as an HDMI splitter. I'm interest in hearing the use-cases that require MOQT to directly support and require relays to support duplication of live streams to the same QUIC connection. Per discussion with NAME , the relay peering would never duplicate the live feeds. It would de-dup all these requests using the track , regardless of how many track aliases were used by a client subscribe. The original publisher would realize this aggregation/de-duplication. In other words, each subscribe from the same QUIC connection or from multiple QUIC connections (in theory different clients) would be grouped together by the relay using the . Each of the and values together represent a feed. In this sense, only or is needed for this process, not both when considering live feeds. Again, fetch is different and is distinguished not only by , , but also by start and end ranges. I'm interesting in hearing the use-cases of why MOQT requires of the relay to support duplicate fetch requests for the exact same ranges at the same time when the other hasn't finished yet. Seems like it would make sense that if the same QUIC connection (aka client endpoint) request range X - Y and while still sending X - Y, it requests it again, that it would cancel the previous and start over. Add some text around that endpoint to relay can establish duplicate live streams by using different track aliases for the same namespace/name. The relay or original publisher MAY implement rate limits on the number of active subscribes for the same namespace+name. The relay and/or original publisher may implement different rate limits based on FITLER TYPE. For example, filter type 04 may allow a maximum of 10 active subscribes for the same namespace+name, while filter types less than 4 that involve live stream feeds is restricted to 1.
The status quo of having both needs to be fixed at some point, see
Does this mean we close the complete quic session? Can we just reject the subscribe?
I noticed that the consolidation of SD-JWT terminology in c6a27373dee13cc7c3f70a8b7fd374e62306f5a0 introduced a mistake in the "Enveloping" section title by including the word "Presentation" while the section talks about enveloping either issued or presented SD-JWTs. While fixing that, I decided to remove the SHOULD recommending the use of an unregistered claim name . I also tried to align the example enveloping payload a bit with a move minimal set of claims similar to those used in key binding. I realize I probably should have just fixed the section title and not expanded the scope of the changes. But there I was and these few little changes were so inviting... See it here: URL
Proposal to replace . I think that this is a little clearer this way. Also, it's strange that this was not added earlier, but then sometimes the most obvious things get missed. cc NAME
So I'm not seeing how the new sentence is any different than this one two paragraphs below: A receiver MUST terminate the connection with a connection error of type COMPRESSIONERROR if it does not decompress a header block. My chief concern (merely editorial) is that HPACK consistently uses the phrase "decoding error" whereas here we are using the phrase "decompress." I think it good to make clear that any and all decoding errors MUST result in connection errors of type COMPRESSIONERROR. Picky, I know. ;-)
I think that Martin's proposal tries to specifically address your concern. The sentence two paragraphs below address the case of an endpoint deciding for whatever reason not to decompress a header block: this also has to result in a COMPRESSION_ERROR. So I think that both are useful.
Ahhh - thanks NAME Makes perfect sense and I agree.
I didn't want to make this too disruptive, so I concentrated on the high points. Related to the changes in . Breakdown: integrity is important (existing text) HTTPS provides integrity, but you have to be careful with truncation (includes existing example) HTTP provides no integrity extensions can be used to provide additional protection, including managing the risk of intermediaries messing around (massaging existing text)
talks about message integrity in general terms. The introductory sentence is good, but it then seemingly intermingles several different factors that might be relevant: Accidental corruption of messages in the network. This is not something that applies to HTTPS, but it is relevant for the cleartext variant. The use of intermediaries that might not be trusted not to modify messages. Noting here that this is likely selective as intermediaries need to modify certain parts of messages. Attacks on the protocol, which break down further: a. Attacks on cleartext HTTP, which has no real defense. b. Attacks on TLS, which has good defenses on the whole, though less so with respect to truncation of responses. This is due to the way that HTTP/1.1 allows connection termination (which is under attacker influence) to end a response and the way that TLS in practice is really poor at propagating close_notify in a way that is distinguishable from TCP closure. Overall, I think that this text could be made clearer.
This encodes the conclusions from interim discussions: CR, LF, and NUL cannot appear anywhere in field names or values. SP and HTAB cannot appear at the start or end of field names or values. COLON cannot appear anywhere in a field name, except for the colon at the start of a pseudo-header field name. The strong requirements about validating fields according to ABNF has been replaced. The text is clearer about how the pieces fit together: it is HPACK that allows any octet, whereas HTTP/2 makes certain choices invalid.
This allows whitespace and control characters in field names. Is that intentional?
This was intentional, but it can be revised by expanding the set of characters we prohibit. I had imagined that this would not be different from HTTP/1.1 where "Foo\tBar: ?1" might parse, but is not valid in the same way that "Foo\Bar: ?1" is not. I thought that we had agreed that a close policing of the field name grammar was not required from HTTP/2 implementations.
NAME take another look. I've refactored your suggestion.
Yes.
NAME if you can suggest text that would address your remaining concerns, that would be good, but I think we're going to include this text in the next draft. Of course, there will be ample time to improve on this; we just want to make sure that we have an updated draft to discuss at the upcoming interim meeting.
NAME What I think is missing is a description of what this change is trying to achieve. The text identifies that there is a set of , but notes that that is a super-set of of . It then gives text description of what the set of is, but it is not clear exactly what the intent of that set is meant to be? The possibilities are: == union . But if this was the case then why not define it in terms of the HTTP ABNF? == union union . This seems a strange thing to do, but the motivation was originally given that this was describing what existing implementations do? If this is the case then it should be described as such. == intersection . I think this is what the text is actually striving for, but a) it would be good to say so; b) it is unclear to me why h2 needs a superset of option 1. above... if so it should be said why.
If it is indeed option 3. then I assume that there are some fields in the set that are nether in the nor sets. What are those fields and what should an implementation do with them? We are told later in the update that if we are an intermediary then we can validate strictly against the HTTP ABNF and that if we don't we risk invalid fields (and by inference of the section title encapsulation attacks). But what do we do with those fields if we are not an intermediary? Do we pass them onto our applications and let them work it out that they are not members of ? There is nothing there that says we MAY treat such messages as malformed - so at the very least, it would be a good addition to the text to say that non-intermediaries can do stricter validation. So in short, I can see lots of text defining , but it is entirely unmotivated as to why it is > . Finally, to harp on my original complaint, I still do not understand why is defined in 4 bullet points of prose that have already confused some readers. There is a paragraph about how field names have to be lowercase and then the bullet points ignore that and define all visible characters except space (so if space is visible does that mean tab, CR, LF are also visible?) and except colon. Some simple ABNF would be so much better: Or better yet, just go with HTTP field names, but with names in lower-case: Edit: removed comment about ESC... I would looking at an ASCII table from before I was born!
No it doesn't. It gives a text description of a set of invalid H2 fields. The text does not say these are the only limitations on h2 field validity (noting that there is also an ABNF description that applies when -semantics applies), neither does it say that any field that doesn't contain any invalid characters as described in this section is valid. I do think the text could be clearer in saying that this is a non-exhaustive list of reasons why a header field may be invalid, but at the same time I'm reluctant to have this document spend too much time re-hashing reasons that exist in other specifications that are presumed to apply. This question is one for -semantics, not for HTTP/2.