jiebi/CodeConvo huggingface dataset:
Code change:
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.

Related discussion:
text: I'm not convinced, but I'd note that we also have many headers that use to denote "all"; it seems to me that if we're going to do null, we should do that too (but again, I'm not convinced this is adding value).
On Mon, Apr 08, 2019 at 05:16:41PM -0700, Mark Nottingham wrote: It depends on the header field that was empty ;-) I've used the empty Host header field quite a bit (even in health check requests). My observation has been that while HTTP/1.1 without Host naturally causes a 400, HTTP/1.1 with empty Host is often processed similar to HTTP/1.0 without Host or as 1.1 with an unknown Host. I'd say "why not", but it's useful to consider lists and the iterative processing that can happen, removing one item at a time. Having to place a specific value to denote emptiness would require specific processing (i.e. check for emptiness after removing any item just for the sake of replacing it with the special value). By the way, speaking about lists makes me think we may complicate interop when a header field appears multiple times. For example if we have this in a request : List: a,b,c,d Foo: bar List: e,f,g,h It's not unreasonable to think that some simplified implementations may replace the first occurrence of List with "none" after processing it, leading to this : List: none Foo: bar List: e,f,g,h Or possibly this : List: none Foo: bar List: none Which may be processed as "List: none,e,f,g,h" or "List: none,none" respectively. Just my two cents, Willy
Willy, I think that would be clearly broken, and we should be able to catch it with tests. I think we're talking about all of the container types here (dict, list, list of lists, parameterised lists), correct? Julian, you gave as an example. Given that the behaviour recommended is exactly the same as if the header was missing, that's not very compelling. Besides the potential stripping issue (I have heard of implementations that strip empty headers, but don't have details on hand), some header libraries may not make a distinction between missing and empty headers.
Code change:
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.

Related discussion:
text: Overall, I don't see a lot of value in accommodating empty headers directly, and I don't think we should be promoting it as a practice.
Agree, I'm not convinced either. I see the potential, but Gettys rule applies: "The only thing worse than generalizing from one example is generalizing from no examples at all." (May actually be from Phil Karlton originally, sources differ.)
Hm, no. "A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings." vs. "An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response."
Yes, but in the real world, the outcome is always the same.
No. HTTP/1.1 introduced an IESG requirement that Host must always be sent and recipients must always reject with 400 if Host is not received. When I pointed out that not all URIs have a host, the response was that clients must send an empty Host field in that situation. It is a MUST requirement in Semantics section 5.4: This is ingrained in HTTP semantics and commonly used by non-browser HTTP implementations. There is only one example of an HTTP header field using "none" and that is Accept-Ranges. It isn't a good example for anything. To be clear, it would be a bug for an HTTP message processor to drop a received header field just because the value is empty. Nothing about SH will change that. What we are discussing is whether SH is capable of representing an empty list or an empty header field, both of which it is currently incapable of doing.
If that spec specifically says "empty field-value", a SH "empty" token will not be usable for Host: anyway, and we're back in the "generalizing from no example at all" again.
On Thu, Apr 11, 2019 at 03:53:15PM +0000, Poul-Henning Kamp wrote: After having thought a bit more about this, I now think that we don't need empty list elements in the end because lists are not strongly ordered, they're not arrays with a position so an empty element in a list brings no value.
Code change:
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.

Related discussion:
text: I'd further say that removing an element from a list must result in removing the list once the last one was removed as it is a set. So I think I'm fine with not dealing with empty lists. This then leaves us only with the empty header field alone, likely where a string or a token are expected. I don't see a reason not to support an empty string just like any other string. A header field is not just a value, it's a name+value combination. With a void value the name still serves as a boolean (present or not) and this is exactly how it's used when the field is made mandatory to distinguish between agents generations or as a signal to detect support for something. We've all filled administrative forms where the requested information was irrelevant but mandatory in the form and just left it void so that the person in charge deals with the particular case (on paper) or filled with whatever was accepted (on web forms) hoping it would just be ignored since irrelevant. For me the Accept and Host fields are exactly in this category. My concern is to be certain that a valid HTTP request can be transmitted over SH. And ironically, the only mandatory HTTP header ("Host") is also the one requiring the support for an empty value due to its mandatory nature. Willy
I have lost count of the number of packages I have received from USA where part of the address is "Denmark does not have states" :-)
Again, the purpose of SH is not to allow all possible HTTP header to be represented in the data model -- it's to solidify the 80% case and promote best (and interoperable) practice. Representing a boolean as an empty header field is not good practice.
See PR above.
I've put in the changes for the list-based header fields. It's less clear to me that it's desirable to default a missing or empty item to an empty string (strings and tokens) 0 (integers and floats), False (boolean) or a 0-length binary array (binary data); to me, those are all going to be application-specific defaults that are better specified explicitly. I'm happy to adjust the spec to make that more clear, if folks feel it already isn't.
Code change:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose <del> only a subset of the claims contained in the JWT, in the three-party- model as described above.  This is a common problem in the three- party model: An Issuer creates a Verifiable Credential for some End- User (Holder), who then can presents this credential to multiple Verifiers.  A Verifiable Credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer introduces additional privacy risks. </del> <ins> only a subset of the claims contained in the JWT, which is a requirement to implement the three-party-model efficiently. </ins> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For

Related discussion:
text: fix:
in the three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers. A Verifiable Credential might contain a large number of claims, but the Holder We should short this as suggested by NAME Originally posted by NAME in URL
Relates to
Code change:
received hints from the client.  When doing so, and if the resource is cacheable, the server MUST also emit a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis- <del> key), to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> key), to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Further, depending on the used hint, the server can emit additional response header fields to confirm the property of the response, such

Related discussion:
text: WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL
Code change:
7. <del> This specification registers a Well-known URI RFC5785: </del> <ins> This specification registers a Well-Known URI RFC5785: </ins> URI Suffix: http-opportunistic Change Controller: IETF <del> Specification Document(s): [this specification] </del> <ins> Specification Document(s): well-known of [this specification] </ins> Related Information:

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"

Related discussion:
text: adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!
Code change:
Specification Document(s): status-list-token-cwt of this specification <ins> Claim Name: "ttl" Claim Key: TBD (requested assignment 65534) Claim Description: Time to Live Change Controller: IETF Specification Document(s): status-list-token-cwt of this specification </ins> 13.4. This specification establishes the IANA "Status Mechanism Methods"

Related discussion:
text: Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.
Code change:
client impersonation, such as using attestation APIs available from the operating system. <del> 8.4. </del> <ins> 9.4. </ins> TODO: Describe how to add proof of possession into the various parts of this flow.  Describe why, because things like device session could

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:
account when creating a new HTTP field. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is <del> located at "https://www.iana.org/assignments/http-fields/". </del> <ins> located at <https://www.iana.org/assignments/http-fields/>. </ins> Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Fields with the status <del> 'permanent' are Specification Required (using terminology from RFC8126). </del> <ins> 'permanent' are Specification Required (RFC8126). </ins> Registration requests consist of at least the following information: <ins> And, optionally: </ins> The Expert(s) can define additional fields to be collected in the registry, in consultation with the community.

Related discussion:
text: this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.
Code change:
This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends use cases on live media ingest, syndication, and streaming as the <del> basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </del> <ins> basis for discussions that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: From NAME
NAME and NAME - I agree with Magnus in his email (cut and pasted in the description), where he said "what about RMTP and SRT?", but I'm thinking that since we already have a "Why QUIC?" section, we should probably have a "Why NOT other protocols" section, rather than trying to talk about that in (what was) Section 6.1. That could also conveniently map into saying why we're not looking at "Interactive Media" in this document (and, transitively, in the BOF), and why we're not looking at "On Demand" (Media) in this document (and in the BOF). Please let me know if this is a BAD idea soon (I'm typing PRs).
NAME for media ingest, Magnus has a good point about covering not just HLS and DASH, but also making (even brief) reference to non-segmented protocols like RTMP and SRT (but really, this can be expanded to RIST, ZiXi, etc etc etc). This can just be a sentence or two; I'm happy to write it.
NAME - I had a complicated day yesterday, which became less complicated last night, so I'm not coherent enough to type text. I'll see what I can do in the next couple of hours, and if I can include these NAME suggestions.
The current definition of latency targets in the draft is based on specific numeric ranges. Those do make sense (since they ultimately come from use case requirements), but I believe we should focus more on what consequences those have for the protocol design. Reflecting on our experience with QUIC used for live video vs QUIC used for video conferencing, my proposed definition of the latency target for live video would be "latency an order of magnitude higher than one RTT". Two major examples of why this is important: When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment. When the target latency is in the range of many, many RTTs, selectively retransmitting only lost packets is almost always better than FEC. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs.
Code change:
This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends use cases on live media ingest, syndication, and streaming as the <del> basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </del> <ins> basis for discussions that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: I think the first point illustrates nicely why protocols like RTP have low-level control over packetization, while the existing MoQ proposals defer it entirely to the QUIC stack.
NAME - that's super helpful. It helps us explain a few things - why we need to know this, in order to explain why we're shooting for One Protocol, and why we think the first three use cases in the draft are different (they're all RTPish), and why we're not looking at RTP in the BOF - right now, the draft just says AVTCORE is looking at RTP over QUIC, which really isn't much of a justification, engineering-wise.
Victor's points are well made, though I think picking the boundary of the number of round trips necessary to rely on standard QUIC loss detection is a challenge. 5 RTTs provides almost 5 opportunities to repair a loss, which in my experience is almost always enough. Similarly, I'd expect it's enough for BBR to complete various probing cycles. It's also important to understand what RTT we have in mind here. I think the RTT used to understand what domain you're in is approximately smoothed RTT (not min RTT), because the number of rounds for loss recovery or BBR gain cycling or Cubic packet conservation matter the most.
I agree that the numeric ranges are not useful when designing a protocol but they're useful enough as product requirements. However focusing on the RTT completely misses the point. Network latency involves fixed delays (min RTT) but most of it is caused by queuing (primarily congestion control). This includes any queues within the application, the network layer, intermediate routers, and even the receiver. You can think of latency as the "frame RTT" which is decoupled from the packet RTT. Of course the packet RTT is important, but it just doesn't factor in how much data has been queued. For example, it's just useless to talk about RTMP and HLS/DASH latency in terms of network RTTs. In my opinion, the problem with those protocols is that they impose unnecessary dependencies, making it slow to drop the bitrate to reduce queue sizes. Sending media over a single stream means that every frame depends on every previous frame regardless of the GoP structure (no frame dropping), and it also means that new GoPs are dependent on the previous GoPs (no skipping ahead).
Code change:
This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends use cases on live media ingest, syndication, and streaming as the <del> basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </del> <ins> basis for discussions that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
Code change:
authoritative for the protected resource, as described in Impersonation. <del> The means by which the client obtains the location of the protected resource is out of scope.  In some cases, the location may be manually configured into the client.  In other cases, it may be dynamically discovered, for instance, through the use of RFC7033, in a manner related to the description in Section 2 of OpenID.Discovery. </del> PRMetadata defines metadata values that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more.  These values may be

Related discussion:
text: for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!