jiebi/CodeConvo huggingface dataset:
And add a new SUBSCRIBE_DONE status code. Fixes part of , but it's still unclear how one might refresh a subscription without interruption.
Subscriptions always end with either SUBSCRIBEFIN or SUBSCRIBERESET, except when they Expire and then no control message is sent. This complicates the state machine and adds another case to handle. The subscriber needs to start a timer or something similar to know when the subscription will end, and it doesn't get to know the final group or object ID.
I'd like to get rid of , but my thought was that it's a signal to SUBSCRIBE again before the timeout to avoid interruption. Otherwise, there would be a SUBSCRIBE_RESET with an "expired" error code containing the final group/object.
I agree that a subscriber can deal with this field, but I don't know what purpose it serves for the publisher/relay? It's different from an idle connection timeout, because assuming there is data flowing for the subscription, it would never go idle. Unlike QUIC, I don't see value in having a 'silent close' for subscriptions, because typically we expect subscriptions to have data flowing at a somewhat regular interval. Also, there's no guarantee that the subscription will last until the expiry time, it can always end early with SUBSCRIBEFIN or SUBSCRIBERESET.
Based on last week's conversation, the Expires field doesn't change the state of the subscription by itself, a publisher would still have to send a FIN or RESET to close it. It's still unclear as to what a subscriber should do with it. There was a fair amount of discussion around refreshing one's authorization. It's unclear if that would be done with a SUBSCRIBE_UPDATE or something similar or via UNSUBSCRIBE/SUBSCRIBE?
Would the solution to this be when the relay expires a subscription, it sends a control message ? This might all become clearer once we figure out re authentication but at a high level, I want some way that the relays can clean up state on a time line that is under relay control particularly when poorly implemented clients make subscriptions.
I think this was resolved by -
LGTM
The first and second sentence of this description seem contradictory to me. The first sentence seems to state that (all?) Status List Tokens should have a unique identifier included as their claim. The second sentence directly contradicts this uniqueness requirement. Perhaps I'm misunderstanding what is meant by 'uniqueness' in the first sentence, but in that case the language is quite ambiguous. As the claim seems to have been added solely for including the from the Referenced Token in the Status List Token (as described in ), perhaps the sentences should simply be reworded to not mention uniqueness. So something like: : REQUIRED. The (subject) claim MUST be equal to the claim contained in the claim of the Referenced Token.
The is basically the URI by which the Status List Token is retrieved. As Status List Tokens may be downloaded for offline use, further re-transmission or archiving, its important to also store the URI in the Token, such that it can be compared by others to the of the claim of the Referenced Token. I see that the text may be confusing, it should be clearer as "URI" may be better than "unique string identifier" and URI is unique anyway. How about: : REQUIRED. The (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the claim contained in the claim of the Referenced Token.
Yes thank you, this wording clears it up. If you wanted to be very precise instead of you could write . But perhaps my suggestion is too verbose, what you've written gets the idea across.
See issue
In section 2.2.1 the context that may be included in a transaction token includes "The external authorization token (e.g., the OAuth access token)". To ensure this is not interpreted to mean that an access token is included in a transaction token, I would suggest the following additions, in line with section 9.3 in Security Considerations: "A reference to the external authorization token (e.g., the OAuth access token), including scopes or claims included in the authorization token, but not the unmodified authorization token (see Security Considerations, Section 9.3)"
Pieter, in that section of the spec we are describing what needs to be sent to the Transaction token service, I think in that case the full access token should be passed. However, when generating the request context, we want to ensure that the full access token is not included. Did I get my spec sections wrong?
Maybe instead we shouldn't say "This context MAY include:" but rather ... "The information provided to the Txn-Token Service MAY include" to not confuse readers who might think this data should be included in the request context.
Agreed - I missed that this was for initial token creation. I did create a PR with your suggested text.
PR approved
Looks good.
LGTM
On the list, Rob Sayre asked: I agree it seems we can improve the text here a little. Maybe NAME or NAME can elaborate as to why a digest trailer is not suitable in this case?
The reason is that in order to produce a MICE hash, you need to process the content in reverse order. Therefore, there is no reason not to put the hash in the header. The advantage you get in return is that you can process the response in natural order.
Thanks martin. We should just say it that way, because it is clearer to the reader. I'll follow up with a PR.
Section 3.3 currently says: "3.3. Cancellation A QUIC stream MAY be canceled at any point with an error code. The producer does this via a RESETSTREAM frame while the consumer requests cancellation with a STOPSENDING frame. When using order, lower priority streams will be starved during congestion, perhaps indefinitely. These streams will consume resources and flow control until they are canceled. When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion. This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation. Is this section required, or can it be deleted, or added to a new "workflow" section." [BA] While the meaning of STOPSENDING is clear for frame/stream transport (e.g. stop sending the frame whose transmission is currently in progress), it is less clear when multiple frames are transported on the same QUIC stream. In the case where multiple frames are being transmitted on a stream, the problem is that STOPSENDING does not indicate which frame the receiver has given up on. So how is the sender to interpret it? For example, after resetting the stream, does the sender open a new stream? If so, what frame(s) are to be transmitted on that new stream? To address this ambiguity, an application-layer message(s) could be defined, indicating exactly what the receiver wants the sender to do: Stop (re-)transmission of a particular (named) frame. The existing stream is reset and a new stream is opened for transmission of subsequent frames. Stop transmission of layer(s). The receiver wishes to the sender to adjust the operating point, by stopping the transmission of one or more temporal or spatial layers. Only the layers that remain will be transmitted on new stream(s). Mailing list thread: URL
I think subscribe hints solves the problem of what to start on by saying which object to start the new subscription on. It seems like the solutions to layers would be to put different layers on differenent streams. I would expect different layers to have different priorities which will then mean different streams.
Attendees think there may be valid use cases of STOPSENDING and RESET and it should not be disallowed.
But typically UNSUBSCRIBE could be used to accomplish the desired behavior. STOPSENDING and RESET do not change the state of subscriptions.
Yeah the problem is when there's significant congestion, a player can fall behind on the active subscription. It needs a way of indicating that it is not waiting for group X any longer so the server should not send it, otherwise it's just a waste of bandwidth. My proposal is to use STOPSENDING to indicate you don't want something. This does mean that you can't put unrelated objects on the same stream, otherwise you might accidentally reset the wrong objects. ex. If I no longer want to receive group X, I STOPSENDING any QUIC streams containing group X. But that does prohibit sending group Y on the same QUIC stream, so it would prohibit sending the entire track on a single stream. But like you forfeited the ability to skip any content if you decided to do that. Alternatively, we could add a STOPGROUP message or UNSUBSCRIBERANGE. Possibly we could RESUBSCRIBE with a new start group.
Resubscription works fine here. Since a new subscription is supposed to override an existing subscription from the client, Relay can start sending from the new group. Also I don't think we need to forfeit track per stream use-case. If someone is using track per stream, they exactly know what properties they are signing up for. My proposal would be to Subscribe with new start_point
Resubscribe only works if the content we don't want is at the head/tail, unless SUBSCRIBE supports ranges instead of a single start/end. We don't need to forfeit the use-case; the receiver would have to know that it can't cancel streams in this mode. Franky the application has already made a huge mistake if you're encountering congestion while sending all groups over the same stream. A UNSUBSCRIBE/SUBSCRIBE message doesn't work because it will cause redelivery of any duplicates. We would have to add RESUBSCRIBE or allow augmenting an existing SUBSCRIBE.
NAME Agree that STOPSENDING and RESETSTREAM do not change the state of subscriptions. I'd say the same for CLOSE_STREAM (see: URL).
Not with Subscription hints though
Yes , its application decision to prefer such a mode. Yes in such cases cancel will cancel the entire stream.
But resubscription with a new start_point will help alleviate some.
The group spent time discussing ideas around RESUBSCRIBE/SUBSCRIBE_UPDATE and multiple subscriptions. NAME brought up the fact that a relay may have to issue overlapping subscribes because it doesn't know whether a relative or absolute subscription is earlier. This needs a new issue for multiple subscriptions and updating subscriptions.
Like the change. Section 3.3 currently says: "3.3. Cancellation A QUIC stream MAY be canceled at any point with an error code. The producer does this via a RESETSTREAM frame while the consumer requests cancellation with a STOPSENDING frame. When using order, lower priority streams will be starved during congestion, perhaps indefinitely. These streams will consume resources and flow control until they are canceled. When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion. This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation. Is this section required, or can it be deleted, or added to a new "workflow" section." [BA] While the meaning of STOPSENDING is clear for frame/stream transport (e.g. stop sending the frame whose transmission is currently in progress), it is less clear when multiple frames are transported on the same QUIC stream. In the case where multiple frames are being transmitted on a stream, the problem is that STOPSENDING does not indicate which frame the receiver has given up on. So how is the sender to interpret it? For example, after resetting the stream, does the sender open a new stream? If so, what frame(s) are to be transmitted on that new stream? To address this ambiguity, an application-layer message(s) could be defined, indicating exactly what the receiver wants the sender to do: Stop (re-)transmission of a particular (named) frame. The existing stream is reset and a new stream is opened for transmission of subsequent frames. Stop transmission of layer(s). The receiver wishes to the sender to adjust the operating point, by stopping the transmission of one or more temporal or spatial layers. Only the layers that remain will be transmitted on new stream(s).
Based on
Right now the document contains the (user ID) parameter. Thinking about it some more, this is more about describing the key than the user, see httpwg/http-extensions. In addition to that change, we should add text warning about the tracking risks or this and how to avoid these issues.
It seems to me that there's room for both user-ID type uses for the "u" (in the employee remote access model, e.g.) as well as the more indirect key-indicator type uses (in the Internet Freedom model of distributed communities). I'm especially interested in the latter - use cases where users can prove they are in possession of a valid secret without requiring a hard user identifier (one that attaches them to a permanent/billable/irrevocable external identifier). The draft does not currently provide an Authentication Scheme that directly offers this latter capability, however (though it's possible to overload on the "u"/"k" parameter if the server and client agree on the scheme for doing that). I'm unable to steelman the case for "u" (or "k") being a "super-cookie". The imagined use cases in my head have this scheme tied to a single service provider and employed on the first hop. I don't understand the language being used in the list commentary on this topic (e.g., "Each site (*) could get a different key pair and key identifier."). My assumption has been sites issue credentials as they see fit without reference to any other site. The commentary implies to me that there is some overriding entity distributing credentials to many sites (a la Privacy Pass). I did not think Unprompted Authentication addresses that space. Further, if indeed we need to address that space, it seems to me the "super-cookie" burden of proof is then with THAT scheme, not Unprompted Authentication. The "document it" point might be the salient one: "This is probably another case where documenting a little more detail about the usage context could help.". Here's a start: Sites offering Unprompted Authentication are able to link requests from individuals clients via the Authentication Schemes provided. However, requests as not linkable across other sites if the credentials used are private to individual sites.
says: 'deprecated' isn't the right word here; perhaps 'disabled by a peer'? Also, here and a few other places refer to 'the HTTP/2 priority signals' without enumerating them. To be precise, that should be done somewhere. I think that means: The PRIORITY flag in HEADERS and its associated Exclusive flag, Stream Dependency field, and Weight field The PRIORITY frame type
How about instead "once a client learns that the server supports this priority scheme, it SHOULD stop sending HTTP/2 priority signals" After all, this spec can only really have something to say about the stuff it defines and the h2 priority stuff. (Plus what Mark says about being very clear about what "HTTP/2 priority signals" means.
NAME I like the suggestion but that does not work as is. The draft defines two separate concepts: an HTTP/2 SETTINGS flag that allows an endpoint to deprecate the use of H2 priorities, and a different prioritization scheme. While the two are expected to be used together on HTTP/2, they aren't required to. defines the SETTINGSDEPRECATEHTTP2PRIORITIES flag as a way to opt out of using the HTTP/2 priority scheme, in favor of using an alternative such as the scheme defined in this specification_. That said, I tend to wonder what NAME and NAME are suggesting is that the current draft is a bit verbose. At the moment, it uses to define what "deprecation" means, then the term to define how the client acts when the peer "deprecates." Hence . I would appreciate your reviews. Makes sense.
That raises a different issue. The setting is phrased in the negative, where it could be positive. That is, I support priority mechanism X. That works equally well and doesn't have issues in the case that we have to design a third scheme.
Yes, I think I would prefer a model of advertising support for (potentially multiple) schemes and then saying that the client SHOULD NOT send more than one scheme on a given connection.
NAME NAME While I do not oppose strongly, I think there are number of things that we have to consider: Technically, we can create a mechanism that allows the two sides of a hop agree on one prioritization scheme.
However, that's going to be a bit complicated, because SETTINGS is a frame that is sent by the two endpoints before receiving one from the peer. Therefore, the minimal mechanism would be something like each endpoint sending a list of schemes that it supports, and then both endpoint choose a scheme from a intersection of the two lists using a predefined logic (e.g., client's list of schemes are ordered by its preference, and the most preferred one also supported by the server will be selected). But before designing a negotiation scheme, I think it's worth asking one question: do we want a negotiation scheme for HTTP/3? If the answer is no, I'm not sure if we need something more than a deprecation scheme for HTTP/2, when what we are trying to do is a back port from HTTP/3. Even with HTTP/2, there's isn't a necessity to negotiate the prioritization scheme. IIRC, the two reasons we introduced the deprecation flag (which IMO is an optimization) are: to reduce the burden of setting up the h2 prioritization tree on the server-side to conserve bandwidth All that said, I think my argument is that having deprecation flag is a good way to punt to the future the cost of designing a solution that we might not need. Because the deprecation flag makes h2 and h3 on par. If we find that we need to replace the new prioritization scheme in the future, then we could introduce a negotiation scheme that works for both H2 and H3. Note also that the new prioritization scheme is extensible.
Not needing to fully specify how they're selected right now is certainly a valid point. But the only difference between a deprecation flag and an indication of support is the orientation of the default value. In HTTP/2, the orientation is that the peer might support that feature, but many don't. So there's value in being explicit both directions; the honest choice for default is "don't know." Indicating support for each scheme gives us more leeway in the future, and we can recommend that implementations which don't support the old scheme explicitly disavow it.
Regarding default, I tend to believe that it should be "supportsh2priorities," because clients should continue sending h2 priorities to h2 servers that do not implement the new extension. That leaves us to the discussion of orientation.
I do not have a strong opinion, though IIRC, some argued that they prefer default value being 0 rather than 1. That's how we ended up with a "deprecate" flag than "preferred" flag.
I agree with all of Kazuho's points. We explored something different in the past (e.g. URL) but ended up with what we have today, and I don't think there has been significant new information that would change my opinion.
NAME PTAL at this PR that addresses your comment about describing the signals URL
That looks good, but I wonder if 2.1 should explicitly reference that for the definition of h2 priority signals.
No good nit goes unaccepted
In Section 4.1.1 Hash Function Claim it's stated that: I've seen this reference and similar phrasing in other recent specifications and it's never indicated whether these values are case-sensitive or not. Perhaps this is fault of RFC 6920 not being explicit on the matter, but being vague here creates interop issues; I've already witnessed one regarding this very claim. Should these values be considered case-sensitive or not?
I guess it doesn't say so explicitly but the intent is absolutely that the values be considered case-sensitive. We can maybe add a brief statement to that effect.
adds one sentence indicating case-sensitivity.
Excellent, thank you!
Just for clarification, are sha-256 and SHA-256 different claim?
yes, sha-256 and SHA-256 are different
Good Thank you :)
assuming my small nit gets accepted
Tweak the phrasing of the abstract to make it a bit more clear that the document is adapting the mechanism not defining a mechanism.
There's nothing wrong with them per-se but in the space of 2 paragraphs the doc says This document describes the mechanism for HTTP/3. Appendix A.3 of [HTTP3] describes the required updates for HTTP/2 settings to be used with HTTP/3. So is it a new mechanism, a setting update, a new setting, or what?
Good point! That is a bit awkward. Check out and let me know what you think?
Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm
is a bit odd; unlike its peer sections, it's not a field name, it's a general concept. Then 10.1.1.1 goes on to specify how date formats in HTTP work generally, while 10.1.1.2 is the Date header. Given that we now have a section for generic syntax, I think it makes sense to promote 10.1.1.2 up a level, moving 10.1.1.1 out to an item in 4.4.1 (Common Field Value Components).
Discussed; makes sense.
I'm a little uneasy that the majority of headers that are prefixed with are actually scoped to the selected representation. E.g., , , , . The only registered, current headers that actually about the content (using the current definition in Semantics) are and , AFAICT. Not sure about ; it's defined in terms of the selected representation, but could equally be defined in terms of content, I suspect. It might help to add a small note to the that explains that the prefix doesn't necessarily imply that the header is strictly about the content. Also might be worth mentioning in the .
Reading semantics I have some doubts on C-L wrt partial representation this seems to be the full representation data (eg. see C-L + HEAD). But then what happens with value in a range response? The complete representation-data or the actual content?
"A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length." So the case of a 206 response is special-cased.
It seems to me that C-L is more often used to convey "messaging" information, than the actual metadata (which happens only when HEAD is used).