jiebi/CodeConvo huggingface dataset:
Code change:
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 </del> <ins> to those in HTTP/2 as defined RFC8441.  HTTP/3 requires that HTTP/3 </ins> settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Related discussion:
text: NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!
Code change:
A proxy forwarding a response is not allowed to modify the field value in any way. <del> Authentication-Info can be used inside trailers (trailer.fields) when the authentication scheme explicitly allows this. </del> <ins> Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 11.3.3.1.

Related discussion:
text: Does this mean it's now valid to interleave HTTP/2 DATA frames and HEADER frames?
Does this mean we cannot implement this on HTTP/2?
The feature was removed during WGLC, but no -- it would have required a new frame type.
Okay, so chunk extensions remains a unique feature of HTTP/1 chunked encoding and there is no plan to expand that further?
Yes.
As discussed in and URL, mid-stream trailers (i.e., those that arrive before the end of the payload body) are interesting. A few things to discuss: [ ] What are some potential use cases?[ ] We recently stopped automatically combining trailers into headers, as that created a lot of issues. What about these -- are they yet again distinct from trailers as well as headers? Or can they be "downgraded" into trailers automatically? In other words, when transitioning from a hop that supports these from one that doesn't, are they just dropped onto the floor?[ ] Related - is the expectation that implementations will create separate APIs for these, or would it be that trailers are just available / writable early?[ ] What relationship does one of these have to the payload body? E.g., could I write one that "knows" exactly where in the body it occurs, so that it could sign a chunk of the body relative to it? Or could a handling implementation change its ordering in relation to body bytes?
Some preliminary considerations. Incremental checksums eg. Service management (eg. convey the ETA of the transfer, ...) Sending signatures of partial body (in mid-stream) has some complexities respect to sending a signature of the whole message in the header/trailer section, and requires a security URL trailers, when used for integrity can't be dropped without informing the user agent They probably need to be defined as 1#field-item because mid-stream trailers will be sent multiple times (eg. one per chunk) Whenever they are tied to the partial transmitted representation, they will eventually be unuseful when merged, unless they have some associative propertyThey will be especially useful when tied to a portion of the body They will be significantly less useful when not tied to a portion of the body
Potential use cases mostly limited to long-lived streaming traffic, i.e.
Code change:
A proxy forwarding a response is not allowed to modify the field value in any way. <del> Authentication-Info can be used inside trailers (trailer.fields) when the authentication scheme explicitly allows this. </del> <ins> Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 11.3.3.1.

Related discussion:
text: long-lived "uploading/downloading" in-band signaling support such as load reporting, app-level flow-control, authn update etc Semantics trailers are a special case of mid-stream metadata, e.g. only trailers are able to convey the status of the entire transaction or the entire resource (body) our experience is that in-order delivery is useful and often assumed, since the underlying transport (for HTTP body) is in-order and reliable. Out-of-order metadata is likely a use case for connection-level metadata, IMO with the above assumption on in-order delivery, you really only need one API for delivering in-stream or trailer metadata Multi-part without in-stream metadata, you would have to use multipart (with all the overhead) for structured data, the original content-type can be preserved, e.g. JSON stream; and for media data, the content-type may have to be application/octet-stream
Copying over the questions from NAME over in URL, as they are good ones:
The semantic model of trailers is that they provide additional metadata that may (or may not) be useful to recipients but was not available prior to the initial body data sent. How the are useful and what they might contain would be defined by the field name. A recipient is free to drop the trailer metadata. A mid-stream trailer frame would have the same role in flow control as a HEADERS frame, which is none at the current time. The proposed frames would not have any specific position, but the values inside trailer fields might identify specific positions (on their own, regardless of framing). A cache would either drop the values or store them separately as trailer fields in the order received.
HTTP/2's flow control only cares about DATA frames. But all frames are subject to TCP's flow control. In HTTP/3, all frames are sent on streams which is subject to QUIC's flow control. Responding to the original question, I don't know what a "new form of flow control" would look like and I don't see how one would improve things.
What's the minimal change that would need to happen to semantics to enable this in a future version of HTTP (or an extension to an existing one)?
I think you would need to make "trailer part" less special, and simply say that a version of HTTP can define a way to carry additional field sections during or after the body.
Code change:
A proxy forwarding a response is not allowed to modify the field value in any way. <del> Authentication-Info can be used inside trailers (trailer.fields) when the authentication scheme explicitly allows this. </del> <ins> Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 11.3.3.1.

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the "Object Send Order" specified in </del> <ins> All objects on the stream have the "Publisher Priority" specified in </ins> the stream header. All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". To send an Object with "Object Forwarding Preference" = "Group", find <del> the open stream that is associated with the subscription, "Group ID" and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del> <ins> the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.

Related discussion:
text: There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM
Code change:
part of the connection header. Prior to receiving a SETTINGS frame that sets a value for <del> SETTINGS_INITIAL_WINDOW_SIZE, a client can only use the default </del> <ins> SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default </ins> initial window size when sending flow controlled frames.  Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for all current streams.  When the value of SETTINGS_INITIAL_WINDOW_SIZE <del> changes, a receiver MUST adjust the size of all flow control windows that it maintains by the difference between the new value and the old value. </del> <ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and the old value.  A SETTINGS frame cannot alter the connection flow control window. </ins> A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available space in a flow control window to become negative.  A sender MUST

Related discussion:
text: Curious why the connection flow control window initial size is 64K (65536 bytes) but the stream flow control window initial size is 65535 bytes. The negative flow control example (taken from the SPDY spec) states that the initial stream flow control window is 64K (the SPDY/3 value).
I have to stop trusting Will's edits. He, rightfully, challenged the use of SETTINGS to end connection-level flow control because WINDOW_UPDATE provided another way to do the same, and two ways to do the same thing is bad. I'll fix that up.
Code change:
multiple receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement. <del> 4.3. </del> <ins> 4.4. </ins> The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
5.2. <del> (TODO: Write this section) </del> <ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics. IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts.  This might place limits on the complexity of any given algorithm.  These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric. Furthermore, many IoT applications do not a have a human in the loop, and therefore have weaker latency constraints because they do not relate to a user experience. Extremely low-power links can lead to very low throughput and a low bandwidth- delay product, well below the standard operating range of most Internet flows. </ins> 5.3.

Related discussion:
text: I am not an IoT guy but I took a stab at it.
NAME do you have suggested text, or should I submit this is as a start and you can open a new issue?
Section 5.1 is just a TODO to write about this.
OK, that's a start. But there are two possible angles: could resource constrained devices use this spec? And, how would this spec coexist with IoT specific transports, such as "single buffer" implementations?Looks like a start (I fixed a typo). We don't speak about scale ... in that although the sending rate is often low (or short flows), the number of endpoints can be high.
Code change:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. <del> 10.10. </del> <ins> 10.9. </ins> When Key Binding is not enforced, any entity in possession of an SD- JWT Presentation can forward the contents to third parties.  When

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
against one another for consistency when these lists are used by the application profile. <del> 7.6. </del> <ins> 7.7. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server

Related discussion:
text: The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.
Code change:
against one another for consistency when these lists are used by the application profile. <del> 7.6. </del> <ins> 7.7. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter <del> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter <del> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.
Code change:
TODO: Register them from here. <del> 5.4. </del> <ins> 6.4. </ins> This section requests registration of the "application/ scitt.receipt+cose" media type RFC2046 in the "Media Types" registry

Related discussion:
text: Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs
Code change:
If field_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is not empty, fail parsing.

Related discussion:
text: From Magnus's feedback
also NAME PTAL
This does not instill much of a panicked reaction in me, which is probably a good sign. I trust it is intentional to not apply a similar treatment to inner lists (which also has a prose description I had commented on previously) on the grounds of them not resembling existing top-level header field structures? That's certainly defensible, though I have to wonder whether someone will simply assume that it must be the same (not that we have much hope of changing such a person's behavior).
How does this vibe with ? I know we spent a bit of time on it, but it's long enough ago that I can't recall detail.
Ah, right, I think I remember. Doing it this way means inner-list is different: The original motivation to remove tabs was because the above was going to be but there was consternation about RWS. Most of the discussion is in
NAME was where my mind went first too, but that seems to be just about in inner lists (which makes sense). I think this is separate; intermediaries that don't know about the semantics and syntactic limitations of a given field shouldn't be meddling inside it (which inner list delimitation is).
NAME I think so -- that's the only reason to allow this. Existing servers may already legitimately be using TAB when combining multiple field lines. And I suppose it makes sense, given the recent discussion about not breaking up individual list or dictionary members over multiple lines, that we don't need to replace *SP with OWS everywhere. I'm okay with this change -- does it warrant a note in the prose somewhere that this special case only exists to accommodate field concatenation? Let's hope we don't need to add VTAB or FF to this, too :)
NAME I don't know that that's necessary; we already pretty clearly. In SF, I looked at changing "whitespace", but in each case the ABNF and algorithms make it clear what we're talking about, so I don't see a strong need to disambiguate.
I'm ok with the change over here; that said, the Semantics spec could be clearer. Opened URL
NAME and I have been talking about this, and have come to the conclusion that this change went too far.
Code change:
If field_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is not empty, fail parsing.

Related discussion:
text: Specifically, steps 1 and 5 in "Parsing Structured Fields" should just be SP, not OWS, because there isn't any risk of an intermediary inserting TAB before the first field line or after the last field line; it's only between List and Dictionary members that we need to be concerned. Reverting that part of the change also makes writing the test cases considerably simpler. See 6842793e.
This is so that field line combination as per the Semantics spec can happen, right? I note that currently says: Note that it says "comma an optional whitespace", not "OWS". Depending on how you read it, it might include other whitespace characters. I believe this needs to be fixed in the Semantics spec.I dont think I ever saw a TAB in a HTTP header in real life, but I am OK with this.
Code change:
10.1.5. <del> The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content. For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field.  This allows a recipient to perform the same check on the fly as it receives the content. A sender that intends to generate one or more trailer fields in a message SHOULD generate a header field in the header section of that message to indicate which fields might be present in the trailers. If an intermediary discards the trailer section in transit, the field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields. 10.1.6. </del> The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work

Related discussion:
text: This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho