HTTP Working Group - IETF 114

13:30-15:30 - Thursday Session II - Liberty D

Administrivia

3 min - Blue sheets / scribe selection / NOTE WELL
2 min - Agenda bashing

Active Drafts

Summary of Alt-Svc side meeting (Mike Bishop)

Slides

• Mike Bishop: Client can't tell when the info carried by Alt-Svc has
  changed. Instead, move to SVCB in DNS. Several ways to spell this.
  Design team? Interim?

• David Schinazi: Apologies for missing side meeting, conflicted with
  the sleep working group. Seems like this is say that the use of QUIC
  is dependent on the HTTPS resource record in the DNS.

• Mike: Yes, that would be the result.
• Tommy Pauly: Yes, if the only way you learn about it is dynamically.
• David: That's the only way on the web?
• Tommy: Yes
• David: Unfortunately, most OSes don't let you query HTTPS resource
  records. Apple does because they're on top of things, but others
  don't. Getaddrinfo doesn't. I can't do this in Chrome, we're trying
  to move everyone to Chrome's own DNS client. We can't use that on
  all OSes, especially ones that are complicated where there's a VPN,
  we fall back to getaddrinfo. We would lose QUIC if we did that. That
  would be a non-starter for us. I would love to be a part of this
  discussion, because that's an important feature for us. In the short
  term, that's not really the right plan.
• Mike: In the short term, sure. That seems like an argument for being
  able to shoehorn it into the existing Alt-Svc. Say I accept the
  problems if I use one of those, but if I'm on a platform where I
  can't query SVCB then that's what I need to do.
• Martin Thomson: Briefly, I understand the implications of having to
  implement this on a vast number of platforms where DNS is sketchy.
  Future is bigger than past. We want to move people in this
  direction, I'd be somewhat comfortable for doing this despite the
  fact that some people wouldn't be able to benefit.

ORIGIN H3 (Mike Bishop)

• Mike Bishop: Resolved the one open issue on the document, addressed
  an eratta from the RFC. Pretty simple document. Are we ready for
  Working Group Last Call (WGLC)?
• Tommy Pauly: Any comments? Objections? [Sees a thumbs up, no thumbs
  down]
• Mark Nottingham: Does this touch origin and should we hold onto it
  for a little while?
• Mike: Certainly possible to have a broader conversation about
  connection coalescing that'll touch origin. Could be some things
  that are nice to fix all-up, but we've previously agreed to not
  change the semantics of Origin to get the frame over.
• Tommy: We could adopt another document to do that.
• David: Another option could be to do the WGLC. I think that would
  get everyone to read it. Park after that, don't send to IESG.
• Mark: For a limited time, that makes sense. Maybe until the interim.

Cookies (Steven Bingler)

Slides

• Steven Bingler: Published -10 with some changes. Closed some issues
  since then, working towards 0 in-scope issues. 4 open issues

• #2185 Cookie Octet Reality Check

  • Proposed changes: To merge uint server syntax, allow servers to
    create cookies that conform to more permissive requirements.
    Alternatively, we could edit/rephrase the relevant sections to
    keep people from accidentally doing the wrong things.

  • If the former, defer since that's too big of a redesign. Latter,
    in-scope that's not too bad.

  • Ted Hardie: When you say that it would be a lot of work to allow
    more permissive things, is that something you've tried or just a
    gut feeling?

  • Steven: More that it has the potential for a lot of
    side-effects. Would feel better if the spec had time to let
    people implement the new syntax and that would delay WGLC.

  • Ted: Thanks for the clarification.

  • Mark: I'm a little confused, the proposal that I made was to
    (garbled) from HTTP-Core which does exactly what's being talked
    about here and talks about a particular range of characters.
    Wouldn't impact implementations, just editorial change.

  • Steven: Yeah, happy to talk about it offline. We've had evidence
    in the past that people just skim the spec, not sure that they'd
    understand what obsolete is and they'd see a grammar and
    implement it.
  • Mark: My experience is that, if we're trying to depend against
    people who don't read, there's very little we can do by writing
    things. Alginment with core specs would be helpful.
  • Steven: I like your idea, sorry I didn't list it in the
    alternate solutions, open to discussing.
  • Mark: Okay, let's chat.

• #2104 Same-Site Cookies and Redirects

  • Chrome and FireFox both attempted to implement, breakage for
    many sites, had to back out

• #1939 Parser for Domain Attributes

  • Never specifies how to tell if something is an IP address

  • Not worth blocking on

  • Martin Thomson: #1939. Put in chat a regex for distinguishing
    between names and IP addresses. Pretty simple to explain.
    Perhaps we pull in a description by reference or just write it
    out. It's basically one paragraph. Will drop in the GitHub
    issue.

• #1399 Set-Cookie parsing algorithm

• Once in-scope issues are resolved, hoping to move towards WGLC

Retrofit Structured Fields (Mark Nottingham)

• Mark Nottingham: One issue open. Do we want to have a representation
  that is also human readable, or do we want to convey and present as
  an integer. Most people have trouble reading that. I see both sides
  of this argument.
• Easier to make sure presented correctly in tools, etc.

• Integer is easier to parse, less overhead.

• Long term, binary representation of the structured types, where
  overhead isn't an issue. There, a human-readable representation is a
  nice thing to do.

• If we don't ever have binary structured types, no doc and no market
  adoption, then we're stuck with the textual representation then we
  do have additional overhead.

• Also discussion in HTTPAPI if they're minting new fields, would be
  good to get them including structured types properly.

• Martin Thomson: I tend to think that the machine readable thing is
  where I would put the integer, not just because I like the ease of
  processing. Even the dates aren't particularly helpful when there
  are timezone changes, etc. It takes me ten minutes to work it out,
  the tools are better at that sort of thing anyway. I do like the
  idea of having an explicit Date type. If we go for a "profile" of
  the profile of ISO dates then I'm not all bent out of shape about
  it. The whole date thing is complicated and we don't need to do the
  full spectrum of options here, it could be quite simple.

• Mark: You said that you want to go the integer way but you also want
  a date type?

• Martin: No, I want the integer, but if we have to do a date type we
  could profile it and it would be acceptible.

• Tommy: Agree with Martin that it's simpler, also when we're thinking
  forward to binary representation. I imagine we'll need to allow
  converting between textual and binary/H1 to H3. Will be less buggy
  to go from integer to integer than to try to handle leap seconds and
  make sure you don't mess up your numbers.

• Mark: Right now, the proposal is not to account for leap seconds,
  just to be clear.

• Tommy: Sure, but we can avoid the question.

• Mark: Happy to go with integer, just want to be aware that users
  like HTTPAPI will go back to using string headers not structured
  headers.

• Justin Richer: I don't have strong feelings about this, but I think
  more friendly to have it be human readable. It's easier to compare
  two values that are date strings vs. two very large integers. As a
  human and as a developer. This notion of having it be an integer in
  the underlying data model and having a string representation matches
  what the rest of the structured fields do. For example, boolean is 1
  or 0 but underlying that is a single bit for booleans. To me, it
  feels better to define it as an integer data model but with a string
  representation with a clear format.

• Mark: Great, that's what the PR does.

• Mike Bishop: Looking at the PR, what's actually sent in the header
  is the date string. Not the fully expanded one, but a string with
  year-month-day.

• Mark: In the textual representation, yes.
• Mike: Is there a midpoint where we represent it as an integer but
  give it a character to say this field is a date and should be
  rendered as such.

• Mark: We could do that, personally if we believe that binary
  structured headers is eventually a good thing, then that would give
  us a wire representation that is the integer that has those nice
  properties. When you convert it to something you show to humans, you
  get nice human-readable properties. What I'm getting from people who
  use HTTP, rather than implementing HTTP, that's a really nice
  property from them. If it's a really bad representation on the wire,
  or in tools, then they're not going to adopt.

• Eric Kinnear: Seems reasonable to assume that anyone making tools
  will look at a gross integer and turn it into something readable for
  humans. Fine to keep it as an integer on the wire and let tools
  convert.

• Mark: I need to make a decision. Take it to the list I guess.

• Tommy: No blocking opinions. Seems to be slight preferences for what
  is easier. People have different perspectives.
• Mark: I might talk to HTTPAPI and show them the PR. If they think
  they'd look at it for future fields, if they're not interested then
  maybe there's less of a point.
• Tommy: David Benjamin in the chat is strongly preferring the
  integer.

Signatures (Justin Richer)

Slides

• Justin Richer: Detached signature mechanism for HTTP messages. Works
  across HTTP versions and weird ways that HTTP exists in the wild.
  For applications that cannot rely on whole-message encapsulation
  like you get with OHAI.
• Take HTTP message, generate signature base using a set of rules for
  how you take content from the message and put it into the signature.
  Gives output which is the signature and the list of things that got
  signed. Send both of those in the headers fields.

• Needed to make new terminology:

  • Message Component: Dictionary formatted structured field.
    Comprised of:

    • Component Name: Name of field, lowercased
    • Component Identifier: Name including any parameters
    • Component Value: Can pull single value from dictionary and
      sign that, for example.

  • Can combine some of those from a Message Component and get a
    Signature Base

• Signature process involves generating signature, verification
  verifies signature base. Signature can be robust across
  transformations between HTTP versions, etc.

• Draft moved from -08 to -11

  • Better security/privacy considerations. Relationship to digests,
    set-cookie, etc.
  • Lots of editorial cleanup
  • Allow binding requests and responses, useful for repudiation

• We're seeing people building and actually using this.

  • GNAP working group is using this as the primary mechanism. I'm
    also the editor, so not a coincidence.
  • FAPI is an unaffiliated reference. Referenced for OpenID's
    "Financial Grade API" draft specification. Different use case,
    but cool.

• David Schinazi: by chat: Clarification question: are the normalized
  fields sent next to the signature, or the original ones
  pre-normalization?

  • Justin: You do not send the signature base at all.

• [#2133] Signature Context

  • [PR #2222] makes optional the signature parameter. Would love
    feedback, leaning towards that PR as the resolution here.

  • Jonathan Hoyland: I think the optional is fine, because it is
    effectively equivalent to just having it mandatory but somebody
    can put NULL in. I would say, it's better to say mandatory but
    can be NULL, that way you can be sure that all libararies
    implement it. I'd prefer that, but I don't think it makes a huge
    difference.

  • Justin: None of the libraries that I've seen are that strict
    about the parameters. It's an extensible field set to begin
    with. Point taken, but what we've tried to do is instead say
    that if a specific application requires it, then it needs to be
    enumerated as part of the application's signatures.
  • Annabelle Backman: I'd be more worried about confusion on the
    part of developers using signatures if they have to supply
    parameters with a NULL value rather than just omitting it. If
    there are libraries that don't support optional things that are
    in the specification, then they're not compliant with the
    specification. I don't know how we can prevent them from doing
    that.

• [#2134] Cache

  • We're not exactly sure that to do here. Is a signature on a
    response from the cache meaningful? If you're responding to a
    signed request with a cached response, are there things you need
    to be aware of?
  • We're not the experts, please help us out, even if to confirm
    okay-ness of what's there now.

• [#2144] Server Push

  • We think this might need some text, but we just don't know.

  • Lucas Pardue: As author of the server push issue, I don't think
    we need to faceplant on it. In a prior life, I have a use case
    for this thing. Happy to contribute text if you'd like and I
    have time. If the server produces a response that doesn't
    validate the signature, what would the client do with it.

• Editors believe this is ready for WGLC.

• David Schinazi: Thanks for the clarification above, that was super
  helpful. This worries me because parsing HTTP fields is super hard.
  Doesn't look like it actually is, but the number of security
  vulnerabilities is astounding. Request smuggling, etc. We're signing
  a normalized version and sending a non-normalized version which
  sounds like it's asking for trouble in that area.

• Justin: For the most part, you sign exactly what is sent across the
  wire. There are cases where you can opt-in to transforming that in
  different ways. (list of cases). For most developers it will be
  "take the thing off the wire and use it". Normalizing how the stack
  did the siganture base, which is not anything that's sent.
• David: But that's still an issue if the unnormalized text triggers
  the vulnerability and the normalized one doesn't.

• Justin: Because you're not parsing the signature base to get values,
  it's not as scary as it seems. Lots of text about that.

• David Benjamin: I want to echo what David Schinazi said about the
  normalization thing. Basically everything cryptographic that uses
  signatures. If there's any property of the message which the
  normalization process drops, if that thing is ever read by someone
  downstream, that's an opening for the attacker to change the
  interpretation of the message. By definition, that's a thing with
  this type of normalization. That will result in a security
  vulnerability. I understand why you wanted to do this, since you
  want to sign something that gets exploded into the wire image for
  HTTP. Safer would be to have the thing you parse be exactly the
  thing you sign. Perhaps take the HTTP message and express it in the
  binary format and then sign that. The thing that you sign needs to
  be the thing that you parse, or else there's room for other unsigned
  input to get in. That's related to where attackers can inject stuff.
  I noticed that there were signature parameters that can change what
  is even signed. How is that carried? A header?

• Justin: No, it is very strictly defined as an ordered set of
  identifiers.
• David: I don't mean the format, just how you receive it.
• Justin: It's a header. Also the last line of the signature base
  every time.
• David: If included in the message, that limits that. Still an issue
  here though.
• Tommy: Overtime, can you and David S. do a review and send those
  comments to the list -- analyze what's in the text and point out if
  there are gaps.
• David: Sounds good, if you can point out where you see signification
  normalization of values. As a spec author, something we try to avoid
  is any normalization of values beyond what's already part of HTTP,
  etc.

QUERY (Julian Reschke)

• Julian Reschke: Not a lot of progress from last time, sorry. Looked
  at the issues, what's left to be done depends on what people expect
  from this specification. If they expect similar to POST, without
  side effects, then we're probably pretty close to done. If they are
  looking for something which introduces proper cacheability then more
  work needs to be done. Every time we look at these issues in a WG
  session, we get into the details and it's not simple to define these
  things properly. Could use a small design team to have a few
  sessions and make a concrete proposal for how to close the remaining
  issues.
• Mark Nottingham: I'd be happy to help.
• Julian: I'll try to summarize on the mailing list and invite people
  to volunteer. Will find a timeslot in the next few weeks.
• Tommy: Volunteers here and on the list.

Volunteers:

• Mark Nottingham
• (ideally, more from the list)

Other Topics

Resumable Uploads (Guoye Zhang)

Slides

• Guoye Zhang: We are bringing our draft to the working group in the
  hope of standardizing resumable uploads. Want to resume when
  interrupted -- today this works for downloads, but not for uploads.
  This means that things built on top of HTTP to offer this are not
  all compatible.
• tus is one of the most popular resumable upload mechanisms. (example
  of how it works, POST yields identifier, PATCH to resume)
• Using that as a starting point. Main difference is to use a
  client-generated token. This reduces by one round-trip (1-RTT) when
  creating an upload. Also backwards compatible, if you don't support
  resumable upload it's just a regular POST.
• Can send intermediate 104 if you support resumable upload. Can
  resume with HEAD and PATH aarequests.
• Feature detection mechanism to allow upgrading regular uploads. Lots
  of ways to spell this.
• Upload metadata. How do we specify filename? Would be nice to use a
  standard header. Also media type/Content-Type. Upload creation
  should set the upload itself, but mailing list discussion says that
  we should be using a generic mediatype for the appending procedure.

• Adoption? First, is this resumable a worthwhile problem to solve in
  this working group? Do you think this is a good approach as a
  starting point?

• Alessandro Ghedini: I have a question about the client generated
  token. It seems like it might be a problem for a server operator
  where the server needs to guarantee that the token is not reused
  across different clients. The server might also want to encode
  different information in the token to avoid maintaining certain
  state. It would be better if there was a way for the server to
  generate the token.

• Guoye: The token is generated 256 bit random by client, but if you
  own the client you can use your own token or encode stuff in it.
• Alessandro: So the problem arises where the server and client aren't
  from the same entity, this proposal is to create something
  interoperable. Can't assume that the server controls the client.
• Tommy: Overall impression? Interested in talking about it.

• Alessandro: Interesting problem. I think Lucas is involved in the
  design. We are interested in doing things that other people are
  interested in doing, not a lot of point if nobody is going to use
  it. There are potential use cases internally where we may want to
  tranfer big files, stuff like that.

• Mark Nottingham: There's a trick to play here where you want to
  design something that's interoperable and works out of the box, but
  you don't want to rule out other valid uses. For example, the
  initial POST to get the token, perhaps it's a PUT if the client
  knows where it's going to be.

• Mark (with chair hat): For proposals like this, it's important for
  proponents to understand that they're giving change control to the
  community and, while they can participate, they're not in control
  anymore. Encouraged to see "starting point" language. Nice to see
  other people have been working on this, like tus, for a long time.
  Seems interesting to work on and this is a good starting point.

• David Schinazi: Nice presentation, very clear and understandable. I
  have read the draft and I think it is a good starting point. I think
  there will be some tricky questions to answer, but I'd rather we do
  that in the working group so we build something that we can operate
  that everyone likes. We might have some uses for this. I'd say I
  strongly support adoption.

• Alan Frindell: Thank you for the presentation and the draft. We've
  had our own version of this technology running for many years. I
  think this came up in a workshop 3 years ago. Keeps coming up,
  should have made a standard a long time ago. Seems like a reasonable
  starting point. Let's adopt and have discussion in the working
  group.

• Tommy: Cloudflare and Microsoft in the chat also indicating they do
  something like this as well, doesn't interop. Sounds like everyone
  is happy with letting the working group have some design team to go
  figure out how this would work. Let's take this to the list, ask if
  we want to work on this, starting here and acknowledge that it will
  completely change, but let's start with this.

GeoIP (Tommy Pauly)

Slides

• Tommy Pauly (sitting): We have some updates on geo-location work.
  David and I took feedback and revised the approach.
• Clients sometimes, but not always, want content that's relevant to
  their location. Assuming that you didn't use javascript APIs to
  share precise location. Problem that I've been experiencing, and
  that others are sympathetic in conversations, is that databases are
  often out of date. Relying on aggregation databases that aren't
  authoritative. Often incorrect specificity.
• Problem for privacy proxies, but also for new IPs, anything that
  changes location frequently. Cellular networks often, or ISPs.
  Manual outreach process of users complaining and then someone has to
  manually refresh.
• Fraught with peril, anything you send that's derived from actual
  location, this is a dangerous privacy foot-gun.
• Safe to do this if location is derived from IP address that you were
  showing anyway, but really you could just share the "correct" GeoIP
  entry and maybe associated feed that owns it, instead of anything
  more specific.
• Client behavior: Expect that clients know what IP geo they have. Can
  learn from ISP or carrier. Client only shares if opt-in.

• Server behavior: Can always blindly trust, clients can only screw up
  their own search results, for example. Could prefer the feed if it's
  trusted. Could check mismatches and use it as a signal to refetch
  from the feed. Could flag it as a place where there's a new feed
  that's coming online.

• Alessandro Ghedini: Interested in working on the problem. Haven't
  thought too much about the solution, but this is probably a good
  starting point. Not sure if httpbis is the spot, but leave to others
  to decide.

• Matt Stock: I agree this is an interesting problem to work on. One
  piece of particular interest to me is how to think about this in
  terms of satellite services where IP in terresterial network doesn't
  algin to traditional location. Hard to keep databases up to date.
  Definitely interested in exploring more.

• Brad Lassey: Definitely interesting place, support working on it.

• Martin Thomson: I'm going to disagree. I don't think this is quite
  right. One of the reasons that GeoIPs aren't such a problem for
  privacy is because they're very bad. Trying to fix that problem puts
  you back in the same box with geohash. When you have good
  geolocation and you start moving around, it introduces the ability
  to track them. Depends on populations in that area. That has
  implications for privacy that I don't think are addressed in the
  document.

• Tommy: Since this in reflecting information that a well-updated
  server database would already have, this is no more information than
  what they already have. Removes out-of-date that hurts the user but
  doesn't help the people who want to track you the most.
• Martin: I'm not going to say this is impossible, but we spent almost
  10 years on this in the past and came to conclusions that it's very
  hard to give away any geolocation info without giving it all away.
  It might be less of an issue here, but the inherent problems in what
  you're doing might help keep people private. I don't think it's
  reasonable to say that you understand the privacy implications of
  this design.
• Tommy: My goal is to produce a document that reduces to the same
  privacy properties that you'd have by using that IP address in the
  first place.

• Martin: You are doing this in the context of a privacy proxy, giving
  people privacy and now you're taking this away.

• David Schinazi: MT understands this space better than I do. If we
  can't figure out a tight privacy box then we shouldn't publish this.
  One idea I have is deployment models. For Google, we're not planning
  to use this through our privacy proxy. Using it to the privacy
  proxy, instead. Using private access tokens, or other anonymous
  tokens, to avoid correlation between multiple requests over time.
  That defeats the correlation of information that you gave away. Not
  saying problem solved, just that it's possible to reason through it.

• Chris Lemmons: I don't think we can solve this problem, but I think
  we can make it better. Seems to be a good starting point.

• Erik Nygren: From past experience, not sure this is super useful.
  Trouble coming up with reasons/people that would use this on client
  and server side that aren't already in a position to take a
  different approach or use a different approach to get feed
  information in other ways.

• Brad Lassey: Good to get opinions of people here, can change
  accuracy based on population density. Think of it not as folks who
  have opted to use a privacy proxy, rather improve privacy overall by
  making it less painful to use a privacy proxy and thus improve
  privacy overall.

Transport Auth (David Schinazi)

slides

• David Schinazi: Motivation, want a MASQUE server that doesn't tell
  everyone it's a MASQUE server. Today, you use a nonce for asymmetric
  cryptography, which leaks the fact that you require authentication.

• Proposal, from Chris Wood back then, use a TLS Key Exporter. Not
  reinventing token binding. Insight is that TLS handshake has fresh
  random data from both endpoints and a key exporter creates
  pseudorandom numbers from both of those random bits. Use it to
  create a nonce, not a key, that the server had input to. You sign
  that nonce so you don't need to transmit it, server can decode it as
  well.

• Jonathan Hoyland: (Clarification question) Idea of nonce as only
  used once, what if I do one authentication that fails and then I try
  again, I'd use the same nonce. How do I get two nonces within one
  TLS session.

• David: Good point, will need to think about that, this is why we
  bring it to this room.
• Martin Thomson: Had the same thought, you don't have fresh entropy
  but you could. Client can provide fresh entropy each time it
  provides one of these assertions that it makes, then there's no key
  reuse problems.
• David: Sounds like it doesn't break the other properties that we
  want, so that's good.
• Jonathon: Do you actually need fresh entropy? Can't you use a
  counter, like this is attempt one and this is attempt two.

• David: Yeah, that's essentially what MT is saying (MT confirms,
  yes).

• Intermedaries, obviously tied to TLS handshake, doesn't work through
  intermedaries. Intermedaries check authentication prior to sending
  request upstream, this is commonly done today anyways, so not seen
  as a big problem.

• Independent implementation by the Guardian Project. Interest from
  the HTTPBIS WG? Even from discussion so far, have benefited greatly
  from input from the WG.

• Mark Nottingham (as individual): I think this is an interesting area
  of work. Possibly important, even. I would be more comfortable if
  the draft were positioned in terms of what properties it has instead
  of the solution. The word "transport" is not helping you right now.

• David: Need to rename it, totally with you.

• Tommy: Right, focus the solution on properties/problem you want to
  solve

• Alessandro Ghedini: This reminds me of the certificate frame.
  Thoughts?

• David: I haven't implemented the certificate frame myself, but this
  seemed way easier to get into an existing codebase.
• Alessandro: That's a frame, this is not a frame. There are different
  use cases for a frame, like post-request authentication if you want.
  Certificate frame uses X.509 certificates. There are probably ways
  to use raw public keys for that as well. Certificate-frame-type
  solution seems more broadly useful, even beyond client
  authentication.
• David: Concern with using a frame, even today HTTP/2 servers explode
  if they see a frame they don't recognize, even though you're
  supposed to be fine with that. Also prevents using HTTP/1. If I can
  stay far away from X.509, I'd be a happy person.

• Alessandro: Probably a way to spell that that doesn't require a
  certificate.

• Alex Chernyakhovsky: Doesn't work for intermediaries. Only generally
  applicable if we can fix that. Didn't read that section in the
  draft. I think this is a footgun waiting to happen in the current
  formulation. This authenticates the channel, not the session, so we
  have additional cryptography challenges when we go to H2 and H3.
  Designed something internally to Google that used TLS Exporters to
  bind X.509 to Google-internal certificate and there was a bunch to
  deal with there. We'd need to discuss a bit more.

• Tommy (chair hat): Sounds like we'd want another version of the
  draft that frames it a bit less as transport and more as a problem
  you want to solve.

METADATA (Bence Béky)

Slides

• Bence Béky: New frame for HTTP/2 and HTTP/3 called METADATA.
• Widely deployed at Google in HTTP/2, working on HTTP/3. Needed to do
  HTTP/3 internally between our proxies.
• Negotiated via a SETTING. Carry HPACK/QPACK encoded key-value pairs,
  no dynamic table, no HTTP semantics.

• Also, thanks for all the feedback on the mailing list.

• Tommy Pauly (as individual): Having yet-another opaque blob that you
  can transport through here is concerning and raises a few alarms. It
  seems to me that the mechanism that we have that allows you to do
  this, we already have frames. It's sort of a frame within a frame.
  Makes sense for a proprietary deployment. Are there specific frames
  that you'd want to define? You gave some examples, could we define
  those as first class frames rather than another registry with a
  different list of frames.

• Martin Thomson: Thanks for the presentation, it's always great to
  get an insight. All I heard was that Google has a bunch of
  proprietary extensions to HTTP/2 and HTTP/3. Not seeing any way that
  needs interoperability. If there are things that you are doing here
  that you think are useful for people to use in other settings, I'd
  agree with Tommy, consider defining a frame for the exchange of that
  information on either a control stream or a request stream, whatever
  makes the most sense. An entirely generic bucket, I don't think is
  especially interesting in terms of standardization.

• Bence: Appreciate the feedback. Unfortunately, nothing that we'd be
  comfortable talking about externally in terms of concrete use cases.
  Bringing to the WG to gauge interest and see if it sparks any
  similar use cases that other people are interested in. If nobody
  jumps up and says that they want this, then that's also an okay
  outcome.

• Lucas Pardue: Thanks for bringing this to the mailing list. I think
  it's a good time to chat. I'm aware of use cases where people are
  trying to carry sidecar data along with requests. Those people have
  struggled with how to do this, maybe doing weird CONNECT and hacking
  some chunking alongside. This could have been a neater solution.
  Capsule kind of goes towards that, not advocating we should use
  capsules. The most generic thing opens up a can of worms that
  developers that aren't us will think they can start sending headers
  and doing whatever and it'll work somehow.

• Alan Frindell: I'll offer a counterpoint. HTTP header fields and
  trailer fields are already generic, that's part of what makes HTTP
  so generic, you can just stick your own headers in there. This
  provides some value and we've had some use cases internally, for
  example timing data, stats in the middle during a long-running
  response. I told someone once to use push, which should tell you how
  it's going.

• Tommy (off mic): How about a timing frame?

• David Schinazi: I encouraged them to come and present this to the
  IETF. Google is using it widely. Probably going to put into envoy,
  which is used outside of Google. If nobody wants it in the IETF,
  that's fine too. Willing to hear feedback.

• Mark Nottingham: To respond to Alan, if we do want to add something
  like this, we need to look it as a change in the developer-visible
  signature of HTTP. Right now we have request/response, header, body.
  If we do that it needs to be very deliberate and well thought out.
  Even pipelining has been hard. We did this with server push. Not a
  hard no, but there be dragons.

• Mark (as chair): Next steps are more discussion and maybe some clear
  use cases.