jiebi/CodeConvo huggingface dataset:
Code change:
Optional parameters: n/a <del> Encoding considerations: binary; A JWT-based Status List is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. </del> <ins> Encoding considerations: See status-list-token-jwt of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
dictionary to turn it into a tracking cookie. To mitigate any additional tracking concerns, clients MUST treat <del> dictionaries in the same way that they treat cookies.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </del> <ins> dictionaries in the same way that they treat cookies RFC6265.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </ins>

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If <del> intermediaries want to specify prioritizaton on a multiplexed HTTP </del> <ins> intermediaries want to specify prioritization on a multiplexed HTTP </ins> connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.

Related discussion:
text: Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.
Code change:
to know where to get these security statements from producers and third-parties related to the software product in a timely and <del> unambiguous fashion, </del> <ins> unambiguous fashion </ins> <del> how to attribute them to an authoritative issuer, </del> <ins> how to attribute them to an authoritative issuer </ins> how to associate the statements in a meaningful manner via a set <del> of well-known semantic relationships, and </del> <ins> of well-known semantic relationships </ins> how to consistently, efficiently, and homogeneously check their <del> authenticity. </del> <ins> authenticity </ins> There is no standardized way to: <del> know the various sources of statements, </del> <ins> know the various sources of statements </ins> <del> how to express the provenance and historicity of statements, </del> <ins> how to express the provenance and historicity of statements </ins> how to related/link various heterogeneous statements in a simple <del> fashion, and </del> <ins> fashion </ins> check that the statement comes from a source with authority to <del> issue that statement. </del> <ins> issue that statement </ins> 3.4.

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
format-informational. A response message can include any number of informational responses <del> that precede a final status code.  These convey an information status code and a header block. </del> <ins> that precede a final status code.  These convey an informational status code and a header block. </ins> If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
require that the user go through a redirect-based flow at any stage of the process based on its own risk assessment. <del> 8.3. </del> <ins> 9.3. </ins> Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically

Related discussion:
text: I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Code change:
9.1. <del> The permanent message header field registry (see RFC3864) needs to be </del> <ins> The HTTP Field Name Registry (see HttpFieldNameRegistry) needs to be </ins> updated with the following registration: Cookie

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
9.1. <del> The permanent message header field registry (see RFC3864) needs to be </del> <ins> The HTTP Field Name Registry (see HttpFieldNameRegistry) needs to be </ins> updated with the following registration: Cookie

Related discussion:
text: Adds suggestions for how servers could fulfill the requirement Adds suggestion that servers be mindful of the number and size of the cookies they set to avoid hitting their own header length limits. Also mention that UA should consider splitting longer fields.
If that's the case, I'd recommend punting on getting this in 6265bis - which has had a goal of documenting reality.
It is not unusual for servers to reject HTTP requests that contain individual headers longer than a certain limit. If a client sends a header longer than around 8-9K bytes, the risk is quite large that it will get a 40x response back which effectively blocks the client from continuing what it is set out to do. Because of the rather complicated results of such a "too long" cookie header, I think it could be worth mentioning this in the spec. For newcomers in cookie land, this is perhaps not completely obvious. The spec currently mentions size-limits per cookie, but a server can easily send a few large cookies and have the combined size of them outgrow 8K. I would perhaps suggest wording that says a client SHOULD keep its lines shorter than NNN bytes and servers SHOULD accept cookie lines up to at least NNN bytes. (in curl we have the limit set to 8190 bytes) HTTP related specs rarely speak of this kind of size limits, but I know my implementation could have avoided some issues if this real-world limit had been mentioned.
Seems like a worthwhile warning to me.
RFC 6265 had a requirement that a client MUST generate a single cookie header. HTTP/2 and HTTP/3 allow "cookie crumbling" that permits multiple Cookie headers. 6265bis says in URL What is tolerance really? Why are we stating MUST requirement that are immediately invalidated by two of the versions of HTTP in wide usage? Section 5 is huge, what requirement is the text in section 4.2 forward referencing to? I think there's some room for improvement in this area. An HTTP/2 or HTTP/3 is being instructed as a MUST requirement in the relevant RFCs to combine multiple cookie headers into one e.g. URL but if the server MUST be tolerant to multiple Cookies, maybe we can relax the HTTP/2 or HTTP/3 requirements?
This was the output of the discussion in URL
Thanks Mike, I missed that discussion first time around.
Code change:
9.1. <del> The permanent message header field registry (see RFC3864) needs to be </del> <ins> The HTTP Field Name Registry (see HttpFieldNameRegistry) needs to be </ins> updated with the following registration: Cookie

Related discussion:
text: My question comes about because of some HTTP/2 code I looked at that simply implements HTTP/2 and so combines the multiple fields back into one. But as NAME and NAME alluded to their comments on , the splitting could be done for some reason thst isn't purely about H2 or H3 compression optimization. It seems there are actually use cases where keeping the split is useful, and not just in a private deployment. Of course relaxing things more might have unintended consequences. I find the current text too terse to be useful. This is a cookie spec, it seems like the right place to ba adding commentary about how to handle cookies across various version and conversions. Especially some anecdotal examples about why some clients actually do it.
Mentioning why a server should be tolerant, and what shape that could take, seems reasonable to me. Especially given how nicely it dovetails with . What forward reference are you referring to? ?
In that mention, I think it's worth including that re-combining the Cookie lines before passing to the next layer is a form of tolerance from the client's perspective.
Some more text sounds good and I'm happy to review. In Section 4.2.1:
Still LGTM, thanks!
Code change:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  The MD5 algorithm is NOT RECOMMENDED as it's now </del> <ins> RFC4648.  The MD5 algorithm MUST NOT be used as it's now </ins> vulnerable to collision attacks CMU-836068. Reference: RFC1321, RFC4648, this document. <del> Status: obsoleted </del> <ins> Status: deprecated </ins>

Related discussion:
text: States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!
Code change:
state of each path, and demonstrate independent congestion control for each path being used.  Authors of a proposed multipath congestion control algorithm that implements path fail-over MUST evaluate the <del> harm resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness.  These effects also ought to be evaluated. </del> <ins> harm to performance resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness. These effects also ought to be evaluated. </ins> Another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.

Related discussion:
text: This modifies parsing to consider empty or not-present header fields as empty containers; serialisation omits them from output.
The SH syntax does not directly allow empty field values, such as defined for Accept, although this might be allowed by field definitions like MyField = [ sh-list ] Likewise, the list types do not allow for empty lists. sh-list = list-member *( OWS "," OWS list-member ) list-member = sh-item I think this is a very odd choice for a generic syntax because the empty set is often given semantic meaning in generic communication. It's hard to do math without zero. If this is intended, the rationale should be explained in the spec, and there should be some discussion with examples about defining fields as an optional value.
FWIW, even if empty lists may be problematic top-level, the situation is different when they are nested...
ietf104 - interest in the room in supporting empty (perhaps null?) syntax
I agree this is something important. It may be used to mean "I know I must pass the info but I don't know the info", which is different from "I don't care about the protocol" or passing a dummy value just to fill the hole.
In the original base material of header definitions, empty values were generally just not sent at all. Having a specific Null value may or not make sense, not sure.
I personally like the distinction between "known to be empty" and "not presented either because I don't know or because it's empty". Some semantics might explicitly require the presence of some fields which we would enforce by the protocol. This doesn't mean they can't be empty, they must be present, for example, to make sure they weren't dropped in the middle. For example, "Connection: foo" gets rid of the field, not just the value. Just my two cents, Willy
Do we have any RFC'ed headers where there is a difference between a non-present and an empty header ?
There's an accept-something if I remember well. Also I've been using "Host:" in many occasions with HTTP/1.1 requests when I didn't know the host name and this tends to work where no Host field fails ;-) Willy
I'm not against a '?N' null token (along the lines of true/false), but I have a hard time thinking of a use for it.
Code change:
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.

Related discussion:
text: URL
Wouldn't an empty list be equivalent to an empty value, thus we don't need a new syntax?
Putting an empty list where for instance an integer is expected, just to say that there will be none, sounds counter-intuitive to me.
On Fri, Apr 05, 2019 at 01:37:11AM -0700, Julian Reschke wrote: Indeed, probably.
On Fri, Apr 05, 2019 at 03:11:00AM -0700, Poul-Henning Kamp wrote: Agreed in general. My point was that sometimes specs use "MUST send" when the sender doesn't know, resulting in stupid values appearing. That's exactly what led a number of agents to place a content-length with stupid values (0 or huge ones) with the CONNECT method a long time ago. An empty value where an integer is needed by the application is more of an application-level error than a protocol-level one in my opinion : it's up to the application to decide how to recover from this missing piece of information (is it really needed to process the request or not). For me it can mean "don't care", "don't know" or "not representable". After all floats support "NaN" for the same reason :-) Willy
If there is a "MUST send" requirement, there must also be something available in the same spec that can be sent ?
There is not, and never has been, an interop problem with sending empty field values. They are a list value of zero items or a string item of zero length. Accept and Host, respectively.
NAME how do you know that?
Because if a recipient drops an empty Host field the request will be rejected with 400. There have been no reports of such breakage in 25 years. It isn’t even a likely scenario given how message fields are parsed and reproduced.
If a recipient doesn't drop an empty host header, the request will still be rejected with 400, surely? Regardless, I'd note that many headers address this situation with a reserved value like . Is there value in standardising on one such value for future headers?