jiebi/CodeConvo huggingface dataset:
Code change:
its own resources needs to be able to parse and process those same references when received as a target URI. <ins> Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream.  For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value. </ins> 2.4. A recipient MUST interpret a received protocol element according to

Related discussion:
text: This MUST is very fuzzy, and obviously isn't testable. Should it just be prose?
Not convinced, but wouldn't object. Maybe "needs to"?
That's what makes the ABNF normative. I don't see a need to change it now.
Sorry, what does the ABNF have to do with this? The issue is the phrase "MUST be able to parse any value of reasonable length", where "reasonable length" is not defined.
It is defined as being reasonable. I have no problem testing that (subjectively). ;-)
I meant the second half.
How about
I like it
Code change:
WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is <del> established. </del> <ins> established.  There is no definition of the protocol over other transports, such as TCP, and applicaitons using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.

Related discussion:
text: Issue raised at interim on Feb 1, 2023: Does the protocol need to define a failover if QUIC is not available on a specific path. If so, is it the same failover in all cases?
Note that WebTransport does provide a failover to HTTP/2.
We need a answer for Raw QUIC too
We discussed this in chartering and came down on a hard no. It just makes things too complicated. Yep, the webtransport version of it might work fine on TCP and we are not out to break that but it is not a design goal. This is about media over QUIC and QUIC is over UDP. The CDNs may internally do whatever they do but that is a black box.
I agree that this is out of scope, based on my reading of the charter, which says "can be used over raw QUIC or WebTransport." I would like to either close with no action or we can add editorial text that notes that all paths may not support QUIC.
It was decided that a sentence or two about this, including a note that the appropriate fallback may be something entirely different from MoQ (ie: DASH/HLS/etc) depending upon the application and deployment.
Code change:
not contain a Holder Binding JWT as the outer container can be signed instead. <ins> Other specifications or profiles of this specification may define alternative formats for transporting the Combined Format for Presentation that envelopes multiple such objects into one object, and provides Holder Binding using means other than Holder Binding JWT. </ins> 8. Security considerations in this section help achieve the following

Related discussion:
text: Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.
Code change:
connection. Extensions are permitted to use new FrameHeader, SettingValues, <del> ErrorCodes, header fields that start with a colon (:), or any reserved flags or fields in frames.  Of these, registries are established for iana-frames, iana-settings and iana-errors. </del> <ins> ErrorCodes, or header fields that start with a colon (:).  Of these, registries are established for iana-frames, iana-settings and iana- errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames <del> that have unknown or unsupported types.  Note that only frames can be flow controlled, extensions cannot be flow controlled. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </del> <ins> that have unknown or unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </ins> However, extensions can negotiate any use that could change to the semantics of existing protocol components.  For example, an extension

Related discussion:
text: Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")
Code change:
4.3. <del> A header field in HTTP/2 is a name-value pair with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </del> <ins> A header field in HTTP/2 is a name with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </ins> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
represented on 6 bits followed by the header name (header.name.representation). <del> The index of the substituted (name, value) pair is inserted after the header name representation as a 0-bit prefix integer. The index of the substituted pair MUST correspond to a position in the header table containing a non-void entry.  An index for the substituted pair that corresponds to empty position in the header table MUST be treated as an error. This index is followed by the header value represented as a literal string as described in string.literal.representation. </del> <ins> Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. </ins> 5.

Related discussion:
text: We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.12. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.12.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.12. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.12.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.

Related discussion:
text: This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.
Code change:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <del> 7.4.2. </del> <ins> 7.5.2. </ins> To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token to be replaced as the value of the "subject_token" parameter. <del> 7.4.3. </del> <ins> 7.5.3. </ins> A successful response by the Transaction Token Server to a Replacement Txn-Token Request is a Txn-Token Response as described in <del> 7.5. </del> <ins> 7.6. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so:

Related discussion:
text: Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.
Code change:
A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and <del> imposes additional client-side latency by requiring JavaScript </del> <ins> often imposes additional client-side latency by requiring JavaScript </ins> execution to create and manage HTTP cookies. <del> This document defines a set of new request header fields that allow user agent to perform proactive content negotiation (Section 3.4.1 of RFC7231) by indicating device and agent specific preferences, through a mechanism similar to the Accept header field which is used to indicate preferred response formats. Client Hints does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising its capabilities within a request header field, Client Hints allows for cache friendly and proactive content negotiation. </del> <ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request headers to advertise their capabilities and characteristics, so that servers can select (or formulate) an appropriate response. However, proactive content negotiation requires clients to send these request headers prolifically.  This causes performance concerns (because it creates "bloat" in requests), as well as privacy issues (because these request headers can be used to "fingerprint" - i.e., uniquely identify - the user agent). This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and the privacy concerns by creating positive evicence of their use (the use of the response header). This document also defines an initial set of Client Hints. It does not supersede or replace the User-Agent header field. Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </ins> 1.1.

Related discussion:
text: Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.
Code change:
4.3.5. A response to the HEAD method is identical to what an equivalent <del> request made with a GET would have been, except it lacks payload data.  This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the payload data is not desired even if it has changed. </del> <ins> request made with a GET would have been, without sending the content. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the content is not desired even if it has changed. </ins> When a cache makes an inbound HEAD request for a target URI and receives a

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload body and message body.  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> the payload body (see Section 7.3.3 of SEMANTICS).  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the payload body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range <del> Requests or methods such as HEAD, while the message body is dependent on transfer codings and other transformations: resource- </del> <ins> Requests or methods such as HEAD, while the way the payload body is transferred "on the wire" is dependent on other transformations (eg. transfer codings for HTTP/1.1 see 6.1 of HTTP11): resource- </ins> representation contains several examples to help illustrate those effects.

Related discussion:
text: HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)
Code change:
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>

Related discussion:
text: The issue discussion also mentioned the ability for the server to indicate a GET-able URI for the returned results, presumably using Content-Location. It looks like the definition in -semantics is probably sufficient, but it's probably worth highlighting that there are caching implications to having that header present in one of these responses.
Content-Location doesn't have any effect on caching. It would be odd to add caching implications to it.
NAME I was recalling this: URL thinking that the response should be cached for the indicated resource. But I had missed this: And indeed, the Caching spec talks only about invalidating any existing entry for the indicated resource, rather than giving any permission to cache the response under that URI. The application is allowed to update its local copy based on Content-Location, but apparently caches aren't.
We should figure out/document: 1) Establishing the cache key - a cache needs to know how to compute a cache key for the request. The obvious (and very inefficient) way to do this is to use the entire request body as part of the key. 2) Request canonicalisation - we should allow caches with knowledge of canonicalisation algorithms for a given format to use them. 3) Indicating canonical form in requests - if a client (UA or intermediary) canonicalises, it would be nice if they could assert that in the request, so a downstream cache can assume it's there and just look for a byte-for-byte match, rather than re-canonicalising. This would allow a client to manufacture cache misses, but that's already possible in URLs... 4) Indicating cache key in requests - E.g., a hash of the request body. Needs security analysis, though. 5) Indicating cache key in responses - If the server can instruct caches as to what future requests would match it, that would be very advantageous. Necessarily requires knowledge of the request format, but we could define common ones for url encode, XML, JSON.
I don't think that (4) is generally feasible. There might be cases where a cache trusts other entities sufficiently that a hash (Digest field?) can be used, but it will need to work this out for itself. This is probably the big cost associated with caching this method.