jiebi/CodeConvo huggingface dataset:
Code change:
The cleartext version of HTTP/2 has minimal protection against cross- protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is <del> offered for other protocols.  A server that is willing to ignore parts of an HTTP/1.1 request containing an Upgrade header field in addition to the client connection preface could be exposed to a cross-protocol attack. </del> <ins> offered for other protocols. </ins> 10.3.

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
Whilst QUIC and conversely TLS supports the ability for mutual authentication through client and server presenting certificates and performing validation, this is infeasible in many use cases where <del> provisioning of client TLS certificates is unsupported or infeasible. Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </del> <ins> provisioning of client TLS certificates is unsupported or impractical.  Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </ins> 4.9.2.

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
Whilst QUIC and conversely TLS supports the ability for mutual authentication through client and server presenting certificates and performing validation, this is infeasible in many use cases where <del> provisioning of client TLS certificates is unsupported or infeasible. Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </del> <ins> provisioning of client TLS certificates is unsupported or impractical.  Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </ins> 4.9.2.

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
Subscribers interact with the Relays by sending a SUBSCRIBE (message- subscribe-req) control message for the tracks of interest.  Relays MUST ensure subscribers are authorized to access the content <del> associated with the Full Track Name.  The authorization information can be part of subscription request itself or part of the encompassing session.  The specifics of how a relay authorizes a user are outside the scope of this specification. </del> <ins> associated with the track.  The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. </ins> The subscriber making the subscribe request is notified of the result of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the

Related discussion:
text: It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it
Code change:
ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final <del> Object fields will not be present. </del> <ins> Object fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session-termination). </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.
Code change:
that use different grammatical notations than this document (which uses ABNF from RFC5234). <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> The semantics of the cookie-value are not defined by this document. To maximize compatibility with user agents, servers that wish to

Related discussion:
text: Cookie attribute names are case insensitive, this PR adds a note saying as much.
The grammar implies that set-cookie attribute names are case insensitive (because ABNF strings are), and the parsing algorithms say that they're case-insensitive, but I suspect many people may not realise this, because they're so often seen in CamelCase. Could we add a small statement to the Set-Cookie syntax section pointing this out?
It's also worth having a variety of styles in the examples to illustrate this.
Code change:
Desc"; "Description" is too generic, and "Foo-Description" is needlessly long. <ins> While the field-name syntax is defined to allow any token character, in practice some implementations place limits on the characters they accept in field-names.  To be interoperable, new field names SHOULD constrain themselves to alphanumeric characters, "-", "_", "." and ".", and SHOULD begin with an alphanumeric character. </ins> Field names ought not be prefixed with "X-"; see BCP178 for further information.

Related discussion:
text: Header field-names are defined as tokens. This is an extremely permissive syntax, including characters that will cause confusion and likely break some senders/recipients. Most of the special characters allowed are not in the registry or seen "in the wild." Some research would be good to substantiate their use, but a starting point might be: There are a number of strategies we could take to the transition: Like / , mark some characters as "do not generate" but "should consume" Disallow registration of header fields with those characters, and discourage their use in unregistered headers If we have more confidence that they're not in use, just ignore headers containing those characters.
My opinion is that Apache httpd team would prefer to reduce the syntax to reduce the security issues.
Discussed in Montreal; interest in doing something, take to list.
I'm not sure why this is being considered. All browsers support headers such as . Changing that seems likely to break applications.
The restrictions exist to protect legacy server gateways (like CGI) that are far more restrictive than browsers need to be due to the terrible idea of passing names through env vars and command-lines.
in bkk: no real consensus, concern about compatibility. reconsider on impact of a case by cases
For the record, NGINX drops request header fields with names containing characters other than letters, digits, hyphens and optionally underscores (if configured using  directive). Unfortunately, virtually anything seems to be accepted and forwarded in the response headers.
Since I'm seeing the conversation moved from the WG to GH, I'm just pasting what I sent there for completeness. Right now haproxy only accepts : "-" / "" / "." / "+" / DIGIT / ALPHA / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "^" / "" / "|" / "~" i.e. everything matching a token. Quite honestly, seeing any character from this extra list in a field name would look extremely suspicious to me, and I'd rather get rid of them. As Roy mentioned, the restriction is to avoid trouble with CGIs doing : eval "hdrname=$value" Characters like backquote (), dollar ($), or pipe(|) have long been abused to attack servers...
Also I proposed that we could do something less extreme than blocking messages containing such header field names, we could recommend to simply drop these fields by default.
Code change:
Desc"; "Description" is too generic, and "Foo-Description" is needlessly long. <ins> While the field-name syntax is defined to allow any token character, in practice some implementations place limits on the characters they accept in field-names.  To be interoperable, new field names SHOULD constrain themselves to alphanumeric characters, "-", "_", "." and ".", and SHOULD begin with an alphanumeric character. </ins> Field names ought not be prefixed with "X-"; see BCP178 for further information.

Related discussion:
text: This will have no impact if they're here by accident. Then we can let the agents decide if they want to let them pass or not. Thus we could make the difference between "forbidden characters" (the historical ones) and "unusual characters" (those excluded by the new, more restrictive list).
Discussed in Bangkok, but no consensus on an approach.
ietf104: still seeking data for characters used in the wild. http archive mentioned as a possible source.
I'm sceptical about the "protect CGI servers" (and servers similar to those). We have 2020; shouldn't these all have their own protections by now?
Discussed in Basel; suggestion is to document "safe" characters in prose (for now), both below the ABNF and in the new header field recommendations.
Those CGI servers cannot protect themselves. The issue is that both hyphens and underscores are converted to underscores in CGI servers, so both and are converted to at the protocol level, and CGI servers cannot tell which HTTP header did it originate from, since that information is lost.
Hey Piotr, We chatted about that here and tend to agree -- will remove underscore and see how that goes down.
Well, to be clear, it is the HTTP server that invokes CGI that is creating the environment variables from the received header fields. That server is responsible for avoiding bad transformations, such as the underscore problem above. However, since we are just talking about the characters that are good practice, we can exclude underscores since they are not commonly used in field names.
Code change:
guarantee that a publisher will not have already sent Objects before the new start Object.  The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have <del> already sent Objects after the new end Object. </del> <ins> already sent Objects after the new end Object.  A publisher SHOULD close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies a Subscribe ID that does not exist within the Session. </ins> Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times.  Like SUBSCRIBE, EndGroup and

Related discussion:
text: This case seems easily avoidable by a subscriber, so the simplest option is to close the session.
Draft 04 currently doesn't mention about sending any response when the SUBSCRIBE_UPDATE is successful or when it fails even though the draft hints on possible failures The above suggests that an error should be sent to inform the client that it is making invalid subscription updates.
documents some other aspects of SUBSCRIBE_UPDATE that are underspecified.
Table 4 is missing SUBSCRIBEUPDATE, so there's no code for this message type. Section 6.5 doesn't say what to do when the update is malformed, in some way. SUBSCRIBEERROR? Is a bogus SUBSCRIBE_UPDATE ignored, or does it nuke the original subscribe?
One nit, but LGTMLGTM
Code change:
parameters with the response: The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by [RFC7159].  The </del> <ins> the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included

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:
Trust in the TS itself is supported both by protecting their implementation (using, for instance, replication, trusted hardware, <del> and system attestation) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </del> <ins> and remote attestation of systems) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </ins> organization accountable that operates it.  Unlike CT, where independent auditors are responsible for enforcing the consistency of multiple independent instances of the same global ledger, we require

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
a proposal targeting general Internet use can not assume this is always the case. <ins> circuit-breakers describes the impact of network transport circuit breaker algorithms.  RFC8083 also defines a minimal set of RTP circuit breakers that operate across a path.  This identifies conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. </ins> 4.2.3. The effect on short-lived and long-lived flows using other common

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "client_credentials".

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. <del> Table 2 provides values for the catalog "packaging" field with LOC packaging. </del> <ins> When LOC packaging is used for a track, the catalog packaging attribute (packaging) MUST be present and it MUST be populated with a value of "loc". </ins> 3.2.

Related discussion:
text: Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.