jiebi/CodeConvo huggingface dataset:
Should we mention this on the mailing list?
Sure.
specified that identity content-coding could be made unacceptable (e.g., indicating very strong preference for response compression) by means of an Accept-Encoding request header field value like or without an identity-specific preference, and then recommended that the server SHOULD respond with 406 (Not Acceptable) when it cannot send an acceptable response. But and the update that last point to "SHOULD send a response without any content-coding", presumably primarily intended to avoid sending 406 (Not Acceptable) when the acceptability of identity content-coding is unspecified. The text still includes a description of when identity content-coding is unacceptable and still accommodates a "compression is mandatory" interpretation of , but seems to strongly discourage it in the sense of ("there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course"). I suspect this to be unintentional, and would propose clarification in semantics: In the absence of such clarification, the text describing when identity content-coding is unacceptable seems to be largely pointless.
I agree that this is not optimal, but the proposed text would change the protocol from what is has been since RFC 7231. Given that the current draft is approved and in the publication queue, I don't think that a change is possible or even desirable.
The move away from sending 406 was intentional in RFC7231. There is no implementation support for identity;q=0 overriding basic interoperability (200 response without encoding), unlike Accept for unwanted media types, because encodings are often applied late in the request handling process based on the server's analysis of whether they are efficient/possible. Hence, clients simply list the acceptable encodings and variance in the field values cause unwanted cache misses. The feature only made sense for non-compression encodings. This does not prevent a server from responding with 406, but doing so is less interoperable (without some additional knowledge about why the client is asking for that) than sending no encoding.
If it is indeed intentional for absence of content coding to always be considered acceptable, then what is the purpose of keeping (emphasis mine)?
I meant that the move away from 406 was intentional. Suggesting that "identity;q=0" not be respected was not intentional, but is also not implemented AFAIK (It only makes sense for encryption-related encodings).
I'm not totally sure what to do with the special value of 0 for StartObject and EndObject. If StartObject == 0, that's requesting the whole group. But if it's 1, that maps to a first object of zero, which is also consistent with requesting the whole group. For EndObject, the special value makes sense, because the subscriber might not know how many objects there are. There's also the error case where StartObject == 0 and EndObject != 0, or the reverse. IMO it would make more sense for EndObject to have the special value at zero, but not StartObject.
You're correct, this was an editorial error on my part. I did not intend to make StartObject have a special value.
The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.
The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM
It is spelled as Acknowledgments in every RFC. Fix the one inconsistent case instead.
FWIW, I checked the style guide. Will check again. That doesn't support what you say. The current text uses the slightly minority spelling which is also the one used in the RFC Styled Guide. Feel free to flip to the other spelling if you have a strong preference.
Well, FFS, the style guide also says to use either US spelling or British spelling, but not both. It is spelled Acknowledgments in the US and all RFCs prior to that style guide. The RFC editor deliberately changed my text to Acknowledgments the last time this came up. I don't care which way it is spelled.
[x] Section 9.1. , paragraph 2, comment: I'm not sure I understand what is meant by "transport link" and how connections would "apply" to one. Editors: URL
[x] Section 9.4. , paragraph 4, comment: Using larger number of multiple connections can even cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. Editors: URL
[x] Section 13.1. , paragraph 14, comment: This can become an informative reference, so to not create a DOWNREF, since it's only used in the description of an IANA codepoint. Editors: URL
[X] Section 13.2. , paragraph 12, comment: I think it is common practice to normatively cite an RFC that is being obsoleted. Editors: URL
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
[X] Section 9.3. , paragraph 3, nit: This got garbled, the suggestion was to rephrase to: A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field in the most recently received message (Section 7.6.1 of [Semantics]), if any: Editors: URL
[X] Section 11.2. , paragraph 2, nit:[X] Section 12.3. , paragraph 3, nit: Editors: this is intentional. Leave it to the RFC Editor?
[X] Section 7.1.1. , paragraph 6, nit: Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Editors: URL
[x] Section 9.5. , paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] Section 9.8. , paragraph 2, nit: The abbreviation is missing a period after the last letter. Editors: URL
[X] Section 10.2. , paragraph 17, nit: Consider using "many". Editors: this is in 11.4. URL
[x] "Appendix B. ", paragraph 2, nit: Did you mean "ought to stop"? Editors: URL
[x] "B.3. ", paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. [x] "B.4. ", paragraph 1, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] "C.2.2. ", paragraph 4, nit: This abbreviation for "identification" is spelled all-uppercase. Editors: URL
[x] Uncited references: [RFC7231]. Editors: URL
[x] Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose).
Editors: this is indeed intended, as we're citing something that is in 2068 but not 2616
[x] These URLs point to URL, which is being deprecated: URL URL Editors: these are added by xml2rfc; you may want to open a ticket for that tool :-)
[x] These URLs in the document can probably be converted to HTTPS: URL Editors: URL
It is used normatively for the definition of the "compress" coding. (also, this is no change from RFC 723x).
Sorry? We are obsoleting that spec, thus we will not have a normative dependency on it.
would "apply" to one. Suggest:
otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. With some light editing, I think this would be useful to add.
I think we should commit this now and let the RFC editor decide on spelling.
(related to )
NAME could you please take a look and let me know if it's an accurate description?
I'm merging this, so we make sure that WARP is included. If we got anything wrong, please let us know - we'll make sure it gets fixed.
Luke Curley has written . It's QUIC based, using CMAF for encapsulation, stream based, has no ALPN amongst other features. That said, it should be included in the "prior art" section of the document.
Agreed!
Some things worth considering, but you guys decide what is worth mentioning. Warp is the only protocol that is not frame based. Instead it attempts to map the GoP structure to QUIC streams. High quality media is basically linear within a GoP in order to maximize compression, which fits very nicely with QUIC's streams. There's no point delivering frames out of order if they cannot be decoded out of order. Warp uses prioritization instead of deadlines to achieve dynamic latency. This removes the need for feedback outside of QUIC ACKs. It avoids a whole class of problems caused by dropped/delayed feedback. Warp uses CMAF segments for full compatibility with HLS/DASH, avoiding transmuxing on edge or at origin. Warp uses the full suite of QUIC functionality. This includes fragmentation, congestion control, flow control, streams (multiplexing + cancellation), etc. Some other protocols use QUIC datagrams and disable everything else, effectively using QUIC as a complex DTLS replacement. Warp supports a bidirectional API using QUIC streams however this was not in scope for the first version of the draft. I wanted to avoid bike shedding to focus instead on the above features. The actual version in production allows the player to manually choose the rendition and pause/play. Warp uses WebTransport at the moment, but we can decide if it's better suited for native QUIC (with ALPN) or even HTTP/3. Warp would even work over HTTP/2 (and Http2Transport) albeit with additional head-of-line blocking.
OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.
In internet drafts, the IANA Considerations and Security Considerations sections are mandatory. Exact text for security can be adapted also later on if needed.
It's not really true that stub routers create a security problem by sending RAs: rather, it's the case that this security problem potentially exists on networks where RA guard is present, but this issue is in no way our responsibility, and probably shouldn't be mentioned in security considerations.
NAME I've removed the RA Guard text. It was there not because SNAC-routers introduce a security issue, but because we think that there's a group of people/network-administrators/IETFers/others who consider any device that can autostart acting as IPv6 router and can autostart sending ND message on a link as a "security hazard" even if it's not. Mentioning RA Guard there could be a proactive way to hopefully avoid too many discussions around this during future document reviews.
For security we may add: risk of advertising self-generated ULA prefix? Any specifics? if site employs technology like RA-guard, the RAs of our unmanaged stub router will be blocked
These sound more like operational considerations than security considerations. I suppose if we want to advise sites that do not want stub routers attaching to block RA, that would make sense, but I don't think that's really a problem unique to stub routers. Regarding the ULA prefix, the only risk is one we've already addressed: that the prefix could be used for tracking. I think the text on varying prefixes per-link probably needs work, but that addresses the privacy concern.
As discussed in URL and URL, describe fairness and how that relates to priorities.
As part of the TSVART review, Bob said This seems like a fair point and we likely shouldn't say anything. We can remove this statement entirely but it is normative text so it'll be a change.
I initially thought the same, but now I have a counter-argument. This section (Section 13. Fairness) discusses distributing bandwidth between multiple connections. and 13.2 cover considerations when intermediaries coalesce requests originating from multiple connections onto a single backend connection, or split requests being received on one connection to multiple backend connections. Section 13.3 distributing bandwidth between multiple connections that might share same path. I would argue that all of these belong to IETF, and that they should be covered in the document. We can probably improve the explanation to avoid confusion.
OK that works for me too, could you tackle that?
:+1: Will do alongside .
From the TSVART review, Bob says: We should address this.
I think there's confusion here. Section 13 discusses fairness of bandwidth allocated between end clients, not requests. I think clarifying this might help.
Minor edits
As discussed on the OSW, this PR adds a small section with security considerations on the use of (a.k.a. "web messaging") to this draft. It makes reference to , which already discusses the security implications of in-browser communication flows in detail. Since (silent) iframe flows and popup flows are especially used in browser-based apps, we think that it makes sense to include security considerations of their in-browser communication into this draft. Please let us know what you think about this. We appreciate any feedback.
Sounds good to me, thanks!
It isn't a normative change because the ABNF already requires port to be present in this form of request. The description is just inconsistent. I also intend to change the reference to 3986 to the right section of this document.
The as used for CONNECT describes the request target as comprising an authority, which consists of an IP or reg-name and, optionally, a port number. The example shows an explicit port of 80. What happens if an explicit port is not included? Does the proxy use the port number associated with the implied protocol (80 if the inbound connection is TCP without TLS, 443 if it is TLS)? Or is it an error? As far as I am aware, a port is always provided in practice. Maybe the answer is to explicitly require that the port number is always present and note that no default port can be supplied in this case as there is no scheme and therefore no associated default port.
cc NAME
NAME +1. This is the most natural outcome based on our established consensus in H2 and H3 that CONNECT requests is not accompanied by a scheme.
It's supposed to be a 400 error.
I verified that Apache mod_proxy will respond with 400 if there is no ":" or if the port is empty or non-numeric, and 403 if the port is not configured for use.
Is this something that needs to be listed as normatice change?
"endpoint" is still mentioned in there, unsure we we completely want to get rid of it
Section '8.1. Status List Request' currently states: This seems redundant when the endpoint is used to retrieve a Status List Token, as the Token's integrity is already guaranteed by requiring it to be signed using an asymmetric cryptographic algorithm. If requiring TLS was intended for providing confidentiality of the Token, this seems unnecessary. The endpoint is publicly accessible - there does not seem to be any client authentication mechanisms described for it - thus the Tokens could be retrieved by anybody.
Hi NAME , thanks for the feedback! I think you are correct that we could relax using TLS when a Status List Token is queried. However, if an unsigned Status List is returned, we need TLS as an integrity mechanism.
Yes I vehemently agree :) Btw, perhaps the issue is a bit broader that just permitting plain HTTP when obtaining Status List Tokens. I don't think it's currently explicitly stated in the specification whether a Status List Provider should/must simultaneously provide both plain Status Lists and Status List Tokens. Ie the standard states that an RP should use the Accept-Header to indicate the requested response type, but it does not specify what the Status List Provider should do if it is unable to provide the requested response type. I think this is somewhat relevant under this issue as: if you were to simply add a sentence to the spec permitting plain HTTP for Status List Tokens then an Issuer would have to decide whether to put an HTTP or HTTPS URI in the claim of the Referenced Token but this somewhat contradicts with the Accept-Header mechanism which would seem to indicate (to the reader of the spec) that it's up to the RP to choose the response type. Perhaps the Issuer should explicitly specify supported response type(s) in the claim of the Referenced Token? Ie there could be an additional attribute in the object under the claim specifying the supported formats. Such an attribute could prove beneficial in other regards as well. For example, I don't immediately see an use case where an Issuer/Status List Provider would be providing cbor/cwt Status Lists for JOSE Referenced Tokens.
Section mentions Status List Endpoint. The term is not mentioned elsewhere in the specification nor is it defined.
Thanks for the feedback. Discussion Editors Call: connected to the discussion whether Status List Provider is an entity that shall be described in the spec intend to clarify the term for next iteration
fixes URL
Thanks NAME I like it, I updated the PR
Because the UI and the backend APIs can be hosted from the same backend application, Anti-forgery tokens can also be used to protect against CSRF.
There are indeed various CSRF defenses that could be used in this architecture. The two options discussed in the current document explicitly focus on defenses that are part of the core web platform, and require minimal effort from the developer to implement. The use of anti-forgery cookies requires code on both the frontend and the backend to guarantee their effectiveness. Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?
I thought it would be good to add this as it is per default supported in some tech stacks and so easy to use. People reading the doc might read it as only the mentioned ways protect against CSRF. Adding this would make the recommendations more complete. “Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?” In my opinion, there are no benefits compared with the other two options, just another option. Samesite cookies/ anti-forgery cookies are also a viable option. If the used tech stack has this already supported per default, then there is less to do as a developer. This would make it an option.
NAME I am open to listing out this option as well for the scenario you mention. Do you have text you could suggest that captures this?
Hi NAME I'll write something Kind regards Damien
NAME NAME I created a PR with an initial draft. I don't think we should explain how it works because this is not the scope of this doc. kind regards Damien
Thanks for the suggestion NAME I believe it is important to explain why this addition is there, so I've taken a stab at rewording (see below). I have also removed some of the implementation details that are not necessarily relevant (e.g., the use of HTTPS). I also removed the note on encryption, since the value in the cookie is typically random, so there would be no need to encrypt the cookie. Let me know what you think.
A combined "field value" is a term that HTTP defines, but we didn't link to that. Also, the structure of this paragraph was a little more terse than it needed to be.
Security Considerations state: but the Header and Trailer Field Lines section states: The same field name can be repeated in multiple field lines; see Section 5.2 of HTTP for the semantics of repeated field names and rules for combining values. This leaves me confused, why would it be necessary to produce a combined value if repeated field names are allowed?