jiebi/CodeConvo huggingface dataset:
Code change:
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> The request MUST NOT include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </del> <ins> The request MUST NOT include an "Upload-Offset", "Upload-Complete", or "Upload-Length" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </ins> If the server considers the upload resource to be active, it MUST respond with a "204 (No Content)" or "200 (OK)" status code.  The

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
The following payload is used for the SD-JWT: <del> The respective Disclosures are created by the Issuer: </del> <ins> The respective Disclosures, created by the Issuer, are listed below. In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". </ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT:

Related discussion:
text: URL and I don't know why my response isn't on the mail archive yet but here's a copy: !
oh hey that's fun:
sadness addressed in 9b7ad2d010e0f49e3dd8b5833c59fe4642e2892b (on the surface anyway)
isn't part of this duplicate of ?
Yeah, I did it here first just to fix things. Then decided fixing the build process should be decoupled from addressing one more of Mike's previous review comments.
Now overcome by events. I'm going to resurrect exactly one of my previous review comments that was not addressed. The original comment was: Issuance: There are many places from here on where the label "SHA-256 Hash" is used, for instance "SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4". Change all of these to "Base64url-Encoded SHA-256 Hash" for correctness. Brian responded "The current wording might not be as descriptive as you'd like but it is correct." I'll water down my request if you're not willing to change all the occurrences to "Base64url-Encoded SHA-256 Hash" to then please at least add a textual caveat before the first such occurrence along the lines of: In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". As I said in my initial review, I look forward to this specification being published as an RFC. Best wishes, -- Mike From: Rifaat Shekh-Yusef Sent: Tuesday, September 3, 2024 3:39 AM To: oauth Subject: [OAUTH-WG] WGLC for SD-JWT All, As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by Sep 17th. Regards, Rifaat & Hannes
Code change:
send-order or priority ordering-by-priorities value. Object Payload Length: The length of the following Object Payload. <del> The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </del> <ins> If this field is absent, the object payload continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.

Related discussion:
text: and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands
Code change:
5.2. <ins> An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering.  This cannot be assumed.  An internet Path can also include complex subnetworks where the minimum delay changes over various time scales, resulting in a non-stationary minimum delay. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The Jitter from variation over short timescales might not be distinguishable similar from other effects. Proposals SHOULD be evaluated to ensure their operation is robust when there is a significant change in the minimum delay. 5.3. </ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics.

Related discussion:
text: In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
Code change:
7.1. <del> Storing a malicious payload in a cache can extend the reach of an </del> <ins> Storing malicious content in a cache can extend the reach of an </ins> attacker to affect multiple users.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.

Related discussion:
text: In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"
Code change:
to correlate actions of a single client or server over time.  This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams, <del> timing of reactions to stimulus, and handling of any optional features. </del> <ins> timing of reactions to stimulus, and handling of any features that are controlled by settings. </ins> As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
A client that makes a request to an "http" URI without prior 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 <del> Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </del> <ins> Upgrade header field identifying HTTP/2.0 with the h2 token.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </ins> Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that a large

Related discussion:
text: TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.
Code change:
supposed to be confidential (such as behind a firewall or internal to a secured service).  Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or <del> "data" URI.  A user agent MUST NOT send a </del> <ins> "data" URI.  A user agent SHOULD NOT send a header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent.  A user agent MUST NOT send a </ins> <del> header field in an unsecured HTTP request if the referring page was received with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </del> <ins> header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol.  See sensitive.information.in.uris for additional security considerations. </ins> Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests.  This has the

Related discussion:
text: defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.
Code change:
Response: <del> Note that a "204 No Content" response without payload data but with the same "Digest" field-value would have been legitimate too. </del> <ins> Note that a "204 No Content" response without content but with the same "Digest" field-value would have been legitimate too. </ins> 10.10.

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
scheme", "charset", and "protocol element" as they are defined in RFC6365. <del> 1.2.1. </del> <ins> 1.6.1. </ins> This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and

Related discussion:
text: I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!
Code change:
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <del> The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </del> <ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known <del> to the origin server).  In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. </del> <ins> to the origin server).  The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects.  Appendix E.5 of TLS13 also describes other effects produced by processing duplicated requests. </ins> The request method's safety (RFC7231, Section 4.2.1) is one way to <del> determine this.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </del> <ins> determine if a request is free from side effects.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </ins> It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such

Related discussion:
text: Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!
Code change:
malformed. A proxy that supports CONNECT establishes a TCP to the host and port <del> identified in the </del> <ins> identified in the " </ins> <del> pseudo-header field.  Once this connection is successfully </del> <ins> " pseudo-header field.  Once this connection is successfully </ins> established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in HTTP.

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.15. </del> <ins> 6.14. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.

Related discussion:
text: Into SUBSCRIBEDONE. I didn't remove the SUBSCRIBEERROR message in favor of SUBSCRIBE_CLOSED as NAME suggested in this PR. Addresses some comments in , but possibly not all
So my notes from this discussion. CLOSE is confusing with QUIC layer. People seemed to prefer UNSUBSCRIBE over SUBSCRIBE_CLOSE. I love the move aware from RST and FIN as naming.
Propose names from my understanding of discussion call Announce (send by publisher) , AnnouceOK, AnnouceError UnAnnounce (send by publisher) UnAnnounceOK, UnAnnounceError AnnouceEnd ( sent by thing that received Annouce) , AnnouceEndOK, AnnouceEndOK Subscribe (send by subscriber) , SubscribeOK, SubscribeError UnSubscribe (send by subscriber) , SubscribeOK, SubscribeError SubscribeEnd (send by thing that received subscriber), SubscribeOK, SubscribeError Mostly trying to get rid of FIN / RST and have different names for the messages that flow in opposite directions.
I don't like the name of the different messages used to terminate. I'd rather have one message that transitions to the terminal state, with an optional error code and final group/object. IMO the subscription flow: And the ANNOUNCE flow mirrors: The brackets mean a message is optional. The sender is responsible for creating and the receiver is responsible for closing, possibly at the bequest of the sender (like QUIC's STOP_SENDING).
has been merged, adding yet another term (CANCEL), but I figured we'd clean that up with this issue.
Since we are bikeshedding, I prefer ANNOUNCE_RESCIND instead of CANCEL, since an announce is more of a declarative statement than an active request from the sender.
Heh and UNANNOUNCE and UNSUBSCRIBE stick out because they don't share the same prefix.
I like the names being proposed as they help make make is easier to understand. I do want to separate out one issue. The STOP / CLOSE type thing happens way after the initial SUBSCRIBE thus it can end up in a situation where auth has expired or something else has gone wrong this I like the current design that allows an OK or ERROR to be returned for those. I think it is also key for sender of the things stoping the subscribe to know that the other side has acted on that so we need the OK.
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.15. </del> <ins> 6.14. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.

Related discussion:
text: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?